22、低延迟推流方案：RTMP低延迟配置、GOP优化、编码延迟优化、网络延迟优化

做直播推流，最怕什么？

不是画质差，不是卡顿，而是——延迟。

你想想看，观众在评论区喊了半天，主播这边还浑然不知。或者连麦的时候，两个人各说各的，完全对不上节奏。这种体验，基本等于劝退用户。

我这些年调过不少推流项目，从早期的秀场直播到后来的互动连麦，低延迟始终是个绕不开的硬骨头。今天咱们就把这块啃下来。

RTMP的低延迟配置

先说RTMP本身。很多人以为RTMP协议天生延迟就高，其实不然。RTMP的延迟，很大程度上取决于你怎么配置它。

我个人习惯，在推流端做这几件事：

• 关闭缓冲：RTMP默认会做缓冲，目的是平滑网络抖动。但低延迟场景下，缓冲就是敌人。把缓冲调到最小，甚至直接关掉。
• 调整Chunk Size：RTMP数据是按chunk传输的。chunk size设得太大，一包数据要等很久才能发出去。我一般设到128字节或256字节。
• 减少握手开销：RTMP握手默认是三次。有些场景下可以简化，但要注意兼容性。

举个例子，我在项目中遇到过这样一个坑：推流端一切正常，但播放端延迟越来越高。查了半天，发现是RTMP的接收端缓冲设了3秒。说白了，数据早就到了，但播放器非要攒够3秒才播。这种配置，推流端再怎么优化都没用。

GOP优化：关键帧的博弈

GOP，也就是关键帧间隔。这个参数直接影响延迟和画质的平衡。

GOP设得太大，比如10秒一个关键帧，那播放端要等10秒才能开始解码。设得太小，比如0.5秒一个关键帧，码率会飙升，画质也会下降。

我建议的做法：

• 常规直播：GOP设为2-3秒。这个区间既能保证快速开播，又不会太浪费码率。
• 互动场景：GOP设为1秒。连麦、在线教育这类场景，延迟敏感度极高，1秒的GOP是底线。
• 极端低延迟：GOP设为0.5秒。但要注意，这需要配合更高的码率，否则画质会崩。

编码延迟优化

编码延迟，是低延迟方案里最容易被忽视的一环。很多人只盯着网络，却忘了编码器本身就在“拖后腿”。

编码延迟主要来自几个方面：

• 编码器类型：软件编码器（如x264）延迟高，硬件编码器（如MediaCodec、VideoToolbox）延迟低。能上硬件就上硬件。
• 编码预设：x264的预设从ultrafast到placebo，延迟和画质成反比。低延迟场景，直接用ultrafast或superfast。
• B帧：B帧需要参考后面的帧，会引入额外延迟。低延迟场景，关掉B帧。
• Lookahead：有些编码器会提前分析几帧，以优化码率分配。这个功能会引入延迟，建议关掉。

我整理了一个编码参数对照表，供你参考：

参数	低延迟配置	常规配置	说明
编码器	硬件编码器	软件编码器	硬件编码器延迟更低
预设	ultrafast	medium	预设越快，延迟越低
B帧	0	2-3	关掉B帧减少延迟
Lookahead	0	40	关掉预分析
GOP	1-2秒	3-5秒	短GOP降低开播延迟

网络延迟优化

网络延迟，说白了就是数据从推流端到播放端，在路上花了多少时间。这部分优化，往往是最复杂的。

我总结了几条实战经验：

• 选择就近节点：推流节点离用户越近，延迟越低。CDN厂商一般都有多个节点，选最近的。
• 使用UDP协议：RTMP基于TCP，TCP的拥塞控制会引入延迟。如果条件允许，可以改用基于UDP的协议（如SRT、QUIC）。
• 调整发送缓冲区：发送缓冲区太大，数据会积压。我一般设到100-200毫秒。
• 启用NACK：丢包重传是必要的，但重传次数要控制。重传超过3次还没收到，直接丢帧，别等了。

为什么会这样？因为网络是不可控的。你永远不知道下一秒的带宽是100Mbps还是100Kbps。所以，低延迟推流的核心不是“不丢包”，而是“丢包后快速恢复”。

嗯，这里要注意：网络优化不是推流端单方面的事。播放端也要配合。比如播放器的缓冲策略、解码策略，都会影响最终的用户体验。

整体架构图

下面这张图，展示了低延迟推流的整体流程和关键优化点：

总结

低延迟推流，不是靠某一个参数就能搞定的。它是一个系统工程，需要从编码、传输、播放三个环节同时发力。

我个人习惯，每次调优都先定一个目标延迟值，比如1秒。然后从推流端开始，逐层排查，看每一层贡献了多少延迟。哪一层超了，就优化哪一层。这样调下来，效果往往立竿见影。

嗯，最后说一句：低延迟和稳定性，有时候是矛盾的。追求极致低延迟，可能会牺牲一些稳定性。具体怎么取舍，要看你的业务场景。直播带货和视频会议，对延迟的要求就不一样。这个度，得你自己把握。

---

公众号:蓝海资料掘金营，微信deep3321