前端音视频学习（五）- 视频流协议视频流协议决定了音视频数据如何在网络上“跑”。前端主要关注的是拉流（观看）协议。一

视频流协议决定了音视频数据如何在网络上“跑”。前端主要关注的是拉流（观看） 协议。

协议	基础	延迟	浏览器支持	典型应用
HLS	HTTP (ts)	5s - 30s	原生/hls.js	移动端、长视频、点播
HTTP-FLV	HTTP (flv)	1s - 3s	flv.js	直播、低延迟监控
MPEG-DASH	HTTP (fMP4)	5s - 30s	dash.js	YouTube、Netflix、国际标准
WebRTC	UDP	< 500ms	原生	视频会议、互动直播、带货
RTMP	TCP	1s - 3s	已废弃(Flash)	推流首选（主播端）

原理：HLS 并不是真正的“流式”传输，而是将视频流切成一小块一小块的 静态文件（通常为 .ts 或 .m4s）。
- 索引层：服务器生成一个 .m3u8 文本文件，记录了所有视频切片的 URL。
- 传输层：客户端通过普通的 HTTP GET 请求下载 .m3u8，解析后依次下载视频切片。
特点：
- 高延迟原因：为了播放流畅，播放器通常会缓存至少 3 个切片。如果一个切片 5s，那起步就是 15s 延迟。
- 自适应码率 (ABR) ：.m3u8 可以嵌套。主索引文件指向不同带宽的子索引文件，播放器根据网速自动切换。

原理：利用 HTTP 的 Chunked 传输编码 或 长连接。
- 数据流：客户端发送请求，服务器响应 video/x-flv。
  - 直播场景：在响应体（Body）中不发结束标志，只要流不结束，HTTP 连接就一直 Loading，源源不断地吐出数据。
  - 点播场景：如果播放的是固定长度的文件，服务器发完最后一个字节后会正常结束请求。
- 播放端：前端通过 fetch 或 XHR 监听下载进度，拿到二进制流后由 flv.js 喂给 MSE。
特点：
- 低延迟：省去了 HLS 这种切片打包的时间。
- 稳定性：基于 TCP，不丢包，但网络差时会造成缓冲区堆积（需前端倍速处理）。
- ts视频文件可以一直保留不删除，不需要花费额外的性能保存录像
- 直播转点播，录播都是更简单的，只需要修改m3u8索引文件即可
  
  HLS在点播的场景下优势是更明显的，由于HLS的相关文件是无状态的静态文件，且每个文件的大小是有限的，所以负载均衡、CDN加速的效果更加明显。HLS协议的点播视频会比MP4、flv更快地播放出来，且在加载中跳转视频也会更加顺滑。 hls的m3u8索引文件支持二级索引，高清、标清、流畅等多个观看地址可以合并到一个索引文件，播放器可以根据当前带宽自动切换不同的观看地址，大部分网页播放器的自动也是因为这个

原理：原理与 HLS 极其相似，但更标准、更灵活。
- 索引层：使用 XML 格式的 .mpd (Media Presentation Description) 文件。
- 切片层：支持多种容器（如 fMP4、WebM），兼容性更强。
特点：它是 YouTube 和 Netflix 的核心协议，支持更精细的码率切换算法。

原理：基于 UDP 协议，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还低。在一些交互性比较高的直播场景，如直播带货等场景，会使用WebRTC作为推流和观看协议。WebRTC的延迟理论上可以达到1秒内。
- 信令协商：客户端 A 和 B（或服务器）通过 SDP 交换媒体能力，通过 ICE 交换网络地址。
- 数据流：建立连接后，数据不再是文件流，而是 RTP 数据包。
- 抗性机制：通过 NACK (丢包重传)、FEC (前向绘错) 和 Jitter Buffer (抖动缓冲) 来在不稳定的 UDP 网络上维持基本播放。
特点：毫秒级延迟，但实现复杂度最高，且不适合超大规模直播（CDN 分发成本高）。

原理：由 Adobe 开发，基于 TCP 上的自定义协议。
- 握手与消息：有一套复杂的握手流程，数据切成固定大小的 Chunk（块）。
- 现状：目前 Web 端已不再直接作为拉流协议，但它是 OBS 推流 的标准协议。

原理：类似于 HTTP，但它是专门为控制流媒体服务器设计的控制协议。
- 控制命令：定义了 PLAY, PAUSE, SETUP, RECORD 等指令。
- 数据传输：它本身不传视频数据，数据通常由 RTP (基于 UDP 或 TCP 隧道) 传输。
特点：浏览器原生完全不支持。通常需要后端转码为 HTTP-FLV 或 WebRTC 才能在网页播放。

协议和封装格式通常是“强绑定”或“松耦合”的关系。理解这一点对于处理前端播放报错至关重要。

这类协议要求数据必须包裹在特定的“容器”里，浏览器才能解析。

WebRTC 是一个例外，它不使用任何传统的视频封装格式（如 MP4/FLV）。

传输内容：RTP 包 (Real-time Transport Protocol) 。
工作逻辑：它将编码后的压缩原始数据（如 H.264 的 NAL 单元、Opus 音频帧）直接切碎，塞进一个个 RTP 数据包中发送。
为什么不封装？
1. 极低延迟：构造 MP4/FLV 头部需要时间缓存，而 RTP 可以“给一帧发一包”，实现毫秒级响应。
2. 抗丢包性：传统容器文件一旦文件头损坏就无法播放，而 RTP 包是独立的，丢一个包只会导致局部花屏，不会导致整个流中断。

直播延迟 = 采集延迟 + 编码延迟 + 推流传输延迟 + 服务器转码延迟 + CDN 分发延迟 + 拉流播放延迟。

前端音视频学习（五）- 视频流协议