音视频互动开发中降低直播延迟的那些门道
说真的，做音视频开发这些年，我被问最多的问题就是"怎么把延迟降下来"。尤其是做直播的朋友，常常对着几百毫秒的延迟干着急，用户投诉画面卡顿、互动不同步，商务那边又催着要更好的体验。这事儿确实让人头秃，但也不是没有办法。
作为一个在音视频行业摸爬滚打多年的开发者，我想把这些年踩过的坑、总结的经验掰开揉碎了讲给你听。延迟优化不是某一个环节的事情，而是一整套系统工程。从采集到编码，从传输到渲染，每个环节都在偷偷吃掉你的时间。下面我会用最实在的话，把这里面的门道都给你讲清楚。
先搞明白：延迟到底是怎么来的？
在聊优化技巧之前，咱们得先搞清楚延迟是哪来的。这就像修水管，你得先找到漏水的地方在哪，不然再怎么折腾也是白费功夫。
举个简单的例子，你站在山顶喊话，山下的人要过一会儿才能听到。这个"过一会儿"就是延迟。直播里的延迟也是这个道理，只不过这个"喊话"的过程被拆成了好几个环节。每一个环节都要花时间，加在一起就是你看到的最终延迟。
延迟的"罪魁祸首"们
我给大家列了个表，把主要的延迟来源和典型时间都标出来了。这样你心里就有数了，知道该在哪几个地方下功夫。
| 延迟环节 | 产生原因 | 典型耗时 |
| 采集与预处理 | 摄像头采集、麦克风录音、美颜滤镜处理 | 10-50ms |
| 编码 | 视频帧压缩、帧内帧间预测计算 | 16-200ms |
| 网络传输 | 数据打包、路由转发、CDN分发 | 50-300ms |
| 视频帧解压缩、渲染准备 | 10-50ms | |
| 缓冲抖动 | 网络波动导致的丢包重传 | 不确定 |
你看，上面这些环节随便挑一个出来优化，都能给你省下不少时间。但问题在于，很多开发者只盯着某一个环节使劲，比如一个劲儿地调编码参数，结果发现延迟还是降不下来。这就是因为没有系统地看待这个问题。
我见过太多团队一上来就问"用什么编码器延迟最低"，仿佛换个编码器就能解决所有问题。实际上，如果你网络传输这部分没做好，再好的编码器也白搭。反过来也一样，如果你网络做得很好，但编码效率太低，同样会被拖后腿。
编码环节：压缩率和延迟的相爱相杀
说到编码，这可能是最让人纠结的环节了。你想要高清画质，就得花更多时间压缩数据；你想要低延迟，就得压缩得快一点，但画质可能就上不去。这俩就像是跷跷板的两头，按下一边，另一边就翘起来。
选对编码标准是第一步
目前主流的视频编码标准有H.264、H.265和AV1。H.264是老前辈了，兼容性好，解码器到处都是，但压缩效率也就那样。H.265算是进阶版，同等画质下能省30%左右的码率，但编码速度也慢一些。AV1是新兴力量，压缩效率更高，还是开源的，但硬件支持还是个问题。
我的建议是，如果你的用户设备比较杂，H.264还是最稳妥的选择。如果你的用户群体比较新潮，设备性能也不错，可以考虑H.265。AV1目前适合在高端场景或者对带宽极度敏感的地方用。
这里我想说个题外话，很多开发者选编码标准的时候特别纠结，生怕选错了。实际上，你真正应该关心的是编码参数怎么调，而不是纠结用哪个标准。相同的编码标准，参数设置不同，延迟可能差出一倍都不止。
关键参数这么调
编码参数里面有几个对延迟影响特别大，我来一个个说。
首先是B帧这个家伙。B帧是双向参考帧，它需要看前面和后面两个方向的帧才能解码。听起来很高级是不是？但问题就在于解码器必须等后面的帧出来才能解码中间的B帧，这就会引入延迟。所以如果你在做实时直播，我建议把B帧关掉或者尽量少用。有人可能会说关掉B帧会增加码率，但这跟延迟带来的体验问题相比，真的是小巫见大巫。
然后是编码 Profile和Level。Profile决定了编码复杂度，Level决定了最大码率和分辨率。如果你追求低延迟，建议用Baseline Profile，虽然画质可能稍差一点，但编码速度快，延迟低。有些团队为了追求高清，用了High Profile，结果延迟飙升，用户体验反而更差，这就有点得不偿失了。
还有一个重要的是IDR帧间隔。IDR帧是关键帧，解码器必须从IDR帧开始才能正常解码。如果IDR帧间隔设置得太长，一旦发生丢包，用户就需要等很久才能恢复，这本质上也是一种延迟体验。我建议把IDR帧间隔设置在1-2秒之间，这样既不会增加太多码率，又能保证快速恢复。
硬件编码和软件编码怎么选
现在很多设备都有硬件编码器，比如手机上的GPU、电脑上的NVENC。硬件编码的速度比软件编码快很多，延迟也更低，这是它的优势。但硬件编码的灵活性不如软件编码，有些高级参数调不了，而且不同设备的编码质量差异很大。
我的经验是，如果你的用户主要是移动端，硬件编码是必选项。你想啊，手机CPU就那么点大，软件编码根本扛不住，延迟能给你飙到几百毫秒。但如果是PC端，软件编码的可配置性更好，可以在延迟和画质之间找到更好的平衡点。
网络传输：延迟的"重灾区"
如果说编码环节还能靠技术优化来搞定，那网络传输就是真的让人头疼了。网络这东西是看不见摸不着的，你不知道什么时候就会出问题。而且网络问题往往不是你能控制的，运营商的线路、用户的WiFi信号、基站的负载，这些都能影响延迟。
传输协议该怎么选
传输协议是网络传输的基础，选对了协议能帮你省很多事情。目前主流的直播传输协议有RTMP、HTTP-FLV、HLS和webrtc。
RTMP是实时消息传输协议，这个大家都很熟悉了，延迟大概在2-3秒左右。它的优点是成熟稳定，但延迟确实不适合那些对实时性要求高的场景。比如连麦pk这种，2秒的延迟就能让双方完全没法正常互动。
webrtc就不一样了，它原本是为视频会议设计的，天然就支持低延迟。端到端延迟可以做到500ms以内，有些优化得好的场景甚至能到200ms。这也是为什么现在做连麦直播的团队都在用WebRTC的原因。
不过WebRTC也不是万能的，它的实现比较复杂，需要考虑信令服务器、STUN/TURN服务器、ICE候选收集等等一堆事情。而且WebRTC对网络要求比较高，如果网络比较差，可能还会出现回声、卡顿这些问题。
UDP和TCP怎么取舍
这个问题我也被问过很多次。TCP可靠，UDP快，但具体该怎么选？
我的看法是，如果是那种对实时性要求极高的场景，比如连麦、PK、语音聊天，UDP是更好的选择。因为TCP的重传机制会在网络不好的时候拼命重试，结果就是延迟越来越大。UDP虽然不可靠，但它至少不会让延迟失控，大不了丢几帧，用户感觉也就是卡了一下。
当然，用UDP的话，你需要在应用层自己做一些可靠性保障，比如前向纠错、重传请求之类的。这会增加开发成本，但换来的低延迟是很值得的。
CDN和边缘节点的那些事
很多团队为了覆盖更多用户，都会用CDN来分发内容。但CDN如果用不好，反而会增加延迟。为什么呢？因为CDN的节点是有层级的，用户请求先到边缘节点，边缘节点如果没有缓存，就回源到中心节点，这一来一回延迟就上去了。
我的建议是，选择CDN的时候一定要看它的节点分布和回源策略。节点越多、覆盖越广，用户就近接入的可能性就越高。回源策略也要关注，最好是能支持动态内容的快速回源，不要让用户等待太久。
还有一个点是关于WebRTC的。WebRTC本身的P2P特性在某些场景下很好，但如果用户双方网络都很差，P2P就很难打通。这时候你就需要TURN服务器来中转。选择TURN服务器的时候，延迟和稳定性都是要重点考量的因素。
抖动缓冲：不是所有缓冲都是坏东西
说到抖动缓冲，可能有些同学不太熟悉。简单解释一下，网络传输不是匀速的，有时候数据会来得快，有时候会来得慢，这就是抖动。抖动缓冲的作用就是先攒一点数据，然后匀速送给解码器，这样就能消除抖动带来的影响。
但问题在于，抖动缓冲本身是需要时间的。缓冲得越多，延迟就越大；缓冲得少，网络一波动就会卡顿。这就是一个博弈。
现在比较流行的是自适应抖动缓冲策略。它会根据网络状况动态调整缓冲时间：网络好的时候，缓冲少一点，延迟就低；网络差的时候，缓冲多一点，保证流畅性。这里面的算法有很多，比如基于丢包率调整、基于延迟方差调整等等。
我在实践中发现，自适应抖动缓冲的效果确实不错，但需要仔细调参。参数设置不好的话，可能会出现缓冲时间频繁波动的问题，用户体验反而更差。我的建议是，先用保守的参数上线，然后再根据实际数据慢慢优化。
码率自适应：这个真的能救命
码率自适应听起来很高大上，说白了就是根据网络情况动态调整视频码率。网络好的时候，画质高一点；网络差的时候，画质低一点，保证流畅性为主。
这套机制为什么能降低延迟呢？你想啊，如果网络带宽不够，你还在发高码率视频，结果就是数据发不出去，延迟越来越大。但如果及时把码率降下来，数据就能发出去，虽然画质差了，但至少流畅，延迟也不会失控。
现在主流的码率自适应算法有BBR、Remb、SendSideBWE等等。每种算法都有自己的优缺点，有的激进有的保守。我的经验是，BBR在长肥网络环境下效果很好，但在普通网络环境下反而可能不如传统的丢包率算法。
另外，码率自适应和前面说的抖动缓冲是有关联的。码率变化的时候，抖动缓冲也需要相应调整，不然可能会出现解码器空转或者数据溢出的问题。
移动端的特殊优化
如果你做的直播主要用户是移动端，那有些移动端特有的优化点你一定要关注。
首先是硬件编解码器的选择。不同手机的硬件编码器差异很大，有的手机编码延迟很低，有的就很高。我在项目里一般会做个白名单，把编码延迟低的机型挑出来优先用硬件编码，其他的用软件编码兜底。
然后是省电策略。手机在省电模式下可能会限制CPU性能，进而影响编码速度。我的做法是在检测到省电模式时，主动降低分辨率或者帧率，保证延迟不超标。
还有网络切换的问题。手机会经常在WiFi和4G之间切换，这时候网络状况会剧烈变化。码率自适应算法要能快速响应这种变化，不要等到卡顿发生了才开始调整。
我的几点真心话
讲到这里，我想分享几点自己的体会。
第一，延迟优化没有银弹。不要指望调一个参数就能解决所有问题，你必须系统性地看问题。每个环节都优化一点，加起来效果就很可观了。
第二，要根据业务场景来。秀场直播和连麦PK的延迟要求就不一样，1v1社交和游戏语音的优化重点也不同。不要用一套方案应付所有场景。
第三，数据驱动决策。一定要做好监控，看看延迟到底来自哪个环节，是编码慢还是网络慢，是服务器延迟高还是客户端渲染慢。只有找准了问题，才能有效解决。
第四，留出缓冲余量。用户网络比我们想象的要差，你以为50ms能搞定的事情，实际可能要留100ms的余量。上线之前一定要在各种恶劣网络条件下测试一下。
最后我想说，延迟优化这件事，说难也难，说简单也简单。难的地方在于需要考虑的细节很多，简单的地方在于每个优化点都是可以量化的。你可以一点一点地改，逐步降低延迟。最怕的就是不动手，光在那儿发愁。
好了，关于延迟优化我就聊这么多。如果你正在为直播延迟发愁，不妨从上面说的几个方面入手，一点一点地优化。相信我，只要方法对了，延迟一定能降下来。祝你开发顺利！
