上线前按播放场景验收

这条处理通常不会重新编码画面，速度较快，但前提是原视频编码和封装结构🎵能够被目标播放器接受。如果播放器兼容性仍然不好，应重新编码为更通用的H.264视频和AAC音频，并✨根据目标设备制作适当分辨率与码率。

HLS或DASH只能解决“根据网络选择码率”的问题，不能修复源文件损坏、服务器带宽不足或播放器逻辑错误。Nginx在这里主要负责稳定地发送播放列表和分片，真正的转码、切片和码率规划应在发布流程中完成。

跨域播放时还要检查响应头。若播放器和视频不在同一来源，需要允许播放器所在的可信来源访问媒体资源；使用Cookie或授权信息时，不应简单地对所有来源开放通配跨域。公开免费视频与带权限的视频，缓存规则也必须分开，私有视频不能使用面向所有用户的public缓存。

先判断卡顿发生在哪一层

直播HLS的m3u8播放列表会持续变化，不能使▶️用与固定视频分片相同的长缓存策略。一个常见的静态分发🤔思路如下：

HLS、反向代理与缓存要分开设置

如果视频文件直接存放在服务器上，最好让Nginx直接读取，而不是每次经过PHP、Java或其他业务程序转发。下面是一份偏保守的静态视频配置示例，适合公开访问且文件内容不会频繁变化的MP4、M4V和WebM文件。

视频文件已经经过编码压缩，通常不应再对MP4或WebM启用gzip。对视频做gzip往往只会增加CPU消耗，却很难获得明显的体积收益。对于特别大的文件，可以在确认操作系统和Nginx版本支持后测试异步I/O或线程池，但不要把aio、directio等参数直接复制到所有服务器上；磁盘类型、文件大小和内核配置不同，结果可能相反。

缓存和带宽决定多人播放上限

worker_processes auto和worker🔑_connections主要影响Nginx能够管理的进程与连接数量，并不会凭空增加网络出口能力。调整前还要同步检查文件描述符、内核连接限制和实际带宽。不要随👍意使用limit_rate限制视频速率，否则可能把原本正常的连接人为变成卡顿连接。