直播流链路介绍

1. 推流与分发原理

直播链路通常是从采集端通过推流协议将音视频送入服务器/CDN，再在CDN端转码并分发多协议流。一般主播端采用RTMP协议推流到直播服务器（或云直播服务），服务器可对流做多码率转码并打包成不同协议格式（如 FLV、HLS、HTTP-FLV、LLS 等）供观众拉流观看。

新兴协议（如 SRT、RIST、E‑RTMP）与标准协议（RTMP、HLS、HTTP‑FLV、RTC）各有侧重：有的追求极低延时，有的强调兼容与大规模分发。

• 采集与推流：主播端采集后常用 RTMP 推流，也可选用 SRT、RIST、E‑RTMP 等现代协议，网络上行情况会影响推流延迟和稳定性。

  • SRT（Secure Reliable Transport）：基于 UDP + ARQ 重传，支持 AES 加密和防火墙穿透，延迟可控 ≈120 ms，适合跨网段高可靠性传输。

  • RIST（Reliable Internet Stream Transport）：基于 RTP/UDP + NACK，开放规范，主打多厂商互通与低延时。

  • E‑RTMP（Enhanced RTMP）：在 RTMP 基础上新增对 AV1、HEVC、纳秒级时间戳、多音轨等现代特性的支持。

• 服务器/转码/CDN：负责分发和协议转换。不同协议处理方式不同：如 HLS 需要定期切片生成索引，产生批量延迟；RTMP 则逐帧分发，延迟较低。

  • 接收协议流 → 多码率转码（H.264、H.265、AV1 等）。

  • 按需输出协议：FLV/HTTP‑FLV（秒级延迟）、HLS/LL‑HLS（跨平台分发）、MPEG‑DASH/LL‑DASH、WebRTC（点对点交互）。

  • CDN 负责缓存切片 (.ts/.m4s)、分发索引 (.m3u8/.mpd) 及边缘协议转发。

• 消费端：播放器下载流并解码显示，缓冲区大小和解码延迟决定最终延时。播放器通常会缓存数帧或数秒流以应对网络波动，从而引入额外延迟。

2. 延迟组成与 GOP 缓存策略

直播总延迟由三部分构成：

1. 生产端：采集（10–30 ms）、编码（50–200 ms）、前处理

2. 网络/CDN：传输（≳网络RTT）、切片与分发（HLS 切片长度×列表长度）

3. 消费端：播放器缓冲（1–3 s）、解码渲染、后处理

GOP值（Group of Pictures）表示关键帧的间隔（即两个关键帧之间的帧数），也就是两个IDR帧之间的距离，一个帧组的最大帧数。

消费端一般会设置缓冲时间（如1-2s），以平滑抖动。为了平衡首帧启动速度和整体延迟，常用GOP缓存策略：

• 上限优先（低延迟）：不缓存过往I帧，需等待下一个I帧才开始解码播放（延时最小）。
• 下限优先（抗抖动）：缓存完整 GOP，拉流后立即使用缓存的I帧开始播放（秒开），但延迟增加 1 GOP 长度。

以 SRS 为例，其 gop_cache 配置可开关此策略：gop_cache off 实现“上限优先”低延迟播放，gop_cache on 则启用缓存快速启动。根据场景需求，可在极低延迟和快速首屏间切换。例如遇弱网不宜黑屏时可启用缓存，下行稳定时可关闭以压缩延迟。

3. 各直播协议原理与场景

• RTMP（Real-Time Messaging Protocol）：Adobe/Flash 制定，采用长连接 TCP 传输 FLV 数据包。优点是实时性好（典型延迟1–3秒），几乎所有采集设备和老旧播放器都支持，对防火墙穿透友好（常用80端口）。缺点是需插件或专用播放器（现代浏览器不原生支持 Flash）、TCP 特性可能在弱网时造成累积延迟。适用于互动直播、PC 端直播等对延迟要求较高、兼容性要求一般的场景。

• HTTP-FLV：即通过 HTTP 持续请求 FLV 流。原理与 RTMP 相似，将音视频打包为 FLV Tag，通过 HTTP 分包传输。优点包括可以使用标准 HTTP（避免防火墙限制）、支持 HTTPS 加密、良好的移动端兼容性；延迟较RTMP略高但通常也在1-3秒。缺点是仍基于 TCP 连接，观众端需要使用支持 HTTP-FLV 的播放器或 JS 引擎（浏览器不可原生播放）。

• HLS（HTTP Live Streaming）：苹果公司提出的基于 HTTP 的分段流媒体协议。服务端将视频切成多个 TS 或 CMAF 分片，并生成 M3U8 索引列表；播放器按列表顺序通过 HTTP 拉取并播放。HLS 优点是完全基于 HTTP，可穿透防火墙、方便通过 CDN 缓存分发、客户端实现简单；缺点是固有的“块传输”延迟，通常需要缓冲多个分片（标准播放时延一般在5–15秒以上），不适合对延迟非常敏感的场景。现有低延迟 HLS (LL-HLS) 通过更短分片和部分加载技术可将延迟降至3–5秒。

• LLS（Low-Latency Streaming）：通常指基于专用 CDN/协议的极低延迟方案，常采用精细分片（CMAF/FLV 结合）和推送技术来实现近乎无延迟。优点是延时几乎达到实时，支持大并发；缺点是厂商专有，需要使用对应 SDK/播放器，且部署成本较高。

• RTC（WebRTC）：基于 UDP 的实时通讯协议，采用 SRTP 等传输媒体，交互延时可低于500ms。优点是点对点通信实时性极高（适用于视频会议、互动直播连麦等场景）；缺点是需要复杂的信令和 NAT 穿透，原生不易做大规模广播（需SFU/MCU），兼容性依赖浏览器和硬件。RTC 适合1对1或少人数低延迟场景，不适用于标准CDN分发。

4. 转码档位策略

编码器选择：

• H.264：最广兼容，适合SD/HD。

• H.265：高压缩率（同等画质下码率约减半），适合4K/8K，需客户端支持。

对于网络不佳的用户，还常提供窄带高清档位，即在保证分辨率的同时进一步压低码率。

以下为常用转码档位关系，具体以厂商实际策略为准：