一、延迟基础：什么是推流延迟？延迟的构成
推流延迟，说白了就是——从摄像头拍到画面，到观众手机上看到同一帧画面，中间隔了多长时间。
我经常跟团队里的新人说：延迟不是单一环节的问题，而是一条链路上所有环节的累加。你优化了编码，网络不行，照样卡；你搞定了网络，解码跟不上，观众还是骂。
咱们先看一张整体图，把延迟的五个环节串起来：
1.1 采集延迟：源头的第一道坎
采集延迟，是摄像头或屏幕捕获一帧画面所需的时间。听起来简单，但坑不少。
我遇到过最典型的案例：某直播平台用 USB 摄像头做教学直播，采集延迟直接飙到 80ms。查了半天，发现是摄像头默认用了 15fps 的采集帧率——每帧间隔 66ms，再加上 USB 传输的缓冲，延迟自然就上去了。
| 采集方式 | 典型延迟 | 常见问题 |
|---|---|---|
| 摄像头（30fps） | 33~50ms | USB 带宽不足、驱动缓冲 |
| 屏幕采集（60fps） | 16~30ms | GPU 回读、D3D/OpenGL 同步 |
| 专业采集卡 | 1~10ms | 驱动兼容性、时钟同步 |
1.2 编码延迟：压缩的代价
编码延迟，说白了就是 CPU/GPU 把原始画面压缩成 H.264 或 H.265 码流的时间。这里有个关键概念——编码器预设。
你想想看，同样的 x264 编码器，preset 设为 ultrafast 和 placebo，延迟能差 10 倍以上。我早期做游戏直播时，为了画质用了 medium preset，结果编码延迟 80ms，观众弹幕都在刷「卡成 PPT」。
编码延迟的核心影响因素：
- 编码器类型：硬件编码（NVENC/AMF）通常 1~5ms，软件编码（x264）5~100ms
- 预设等级：ultrafast → superfast → veryfast → faster → fast → medium → slow → slower → veryslow → placebo
- GOP 结构：B 帧越多，编码延迟越大（B 帧需要参考未来帧）
- 分辨率/码率：4K 编码延迟是 1080p 的 2~4 倍
// 常见编码参数对比（以 x264 为例）
// ultrafast：延迟约 5ms，压缩率低，码率大
// veryfast：延迟约 15ms，平衡点
// medium：延迟约 40ms，画质好但延迟高
ffmpeg -i input.mp4 -c:v libx264 -preset ultrafast -tune zerolatency output.ts
// 注意：-tune zerolatency 会禁用 B 帧，进一步降低延迟1.3 网络传输延迟：最大的变量
网络延迟，是整个链路里最不可控的一环。它由三部分组成：
- 物理传播延迟：光速限制，北京到纽约约 40ms RTT
- 传输延迟：数据包大小 / 带宽，100KB 的包在 10Mbps 链路上约 80ms
- 排队延迟：路由器/交换机缓冲，高峰期可能增加 100~500ms
我做过一个跨国直播项目，推流端在上海，观众在洛杉矶。物理延迟 120ms 是硬伤，但真正要命的是 ISP 的丢包重传——高峰期排队延迟能到 800ms。后来我们切了 BBR 拥塞控制算法，才把网络延迟稳定在 200ms 以内。
| 网络场景 | 典型 RTT | 推流协议 | 端到端延迟 |
|---|---|---|---|
| 同城直播 | 5~20ms | RTMP | 200~500ms |
| 国内跨省 | 20~60ms | SRT | 300~800ms |
| 跨国直播 | 100~300ms | WebRTC | 500ms~2s |
1.4 解码延迟：终端设备的瓶颈
解码延迟，是播放端把压缩码流还原成原始画面的时间。这里有个容易被忽略的问题——解码器的初始化延迟。
我记得有一次做 HLS 直播优化，发现播放器每次切换码率时，都会卡顿 1~2 秒。查到最后，是解码器在切换时重新初始化了硬件上下文。后来我们用了「预热解码器」的方案，在后台保持两个解码实例，切换延迟从 1.5s 降到了 50ms。
解码延迟的关键因素：
- 硬件解码 vs 软件解码：硬件解码 1~5ms，软件解码 10~50ms（4K 场景差距更大）
- 解码缓冲：播放器为了抗抖动，通常会缓冲 500ms~3s 的数据
- 码率切换：自适应码率切换时，解码器需要重新初始化
1.5 渲染延迟：最后一公里的细节
渲染延迟，是解码后的画面显示到屏幕上的时间。听起来很短，但累积起来也不容忽视。
渲染延迟主要来自：
- 垂直同步（VSync）：60Hz 屏幕下，最多等待 16ms
- 渲染管线：OpenGL/DirectX 的交换链缓冲，通常 1~3 帧
- 窗口合成：Windows DWM 合成器会额外引入 1~2 帧延迟
我做过一个实验：同样的直播流，用 VLC 播放器延迟 800ms，用 mpv 播放器延迟 400ms。区别就在于 mpv 默认关闭了 VSync 和额外的渲染缓冲。嗯，播放器选型也很重要。
buffer 和 render queue 参数。
1.6 延迟的累加效应
咱们把五个环节的典型延迟加一下：
| 环节 | 低延迟配置 | 普通配置 | 高延迟配置 |
|---|---|---|---|
| 采集 | 10ms | 30ms | 80ms |
| 编码 | 5ms | 30ms | 100ms |
| 网络 | 50ms | 200ms | 500ms |
| 解码 | 5ms | 20ms | 50ms |
| 渲染 | 1ms | 16ms | 50ms |
| 总延迟 | 71ms | 296ms | 780ms |
看到没？低延迟配置下，端到端延迟可以控制在 100ms 以内；但任何一个环节没优化好，延迟就奔着 1 秒去了。
我个人习惯是：先定位瓶颈，再针对性优化。不要一上来就调编码参数，结果发现瓶颈在网络。后面几章，我会带你把每个环节的优化手段都过一遍。