实时音视频技术中的延迟优化技巧分享
你有没有遇到过这种情况：和朋友视频通话时，你说了一句话，对方的回应却慢了半拍，这种错位感让人特别别扭。又或者在直播里，主播和观众互动时，画面和声音总是不在一个节奏上，看得人直着急。说实话，这些问题背后都有一个共同的"罪魁祸首"——延迟。
作为一个在音视频行业摸爬滚打多年的人，我深知延迟优化这个话题看似简单，实际上却是个复杂的技术活。它不像有些技术问题那样有标准答案，而是需要在各种因素之间反复权衡。今天我就想把这些年积累的一些经验和思考分享给大家，希望能给正在做相关工作的朋友一些启发。
延迟到底是怎么来的？
在聊优化技巧之前，我们先得搞清楚延迟是怎么产生的。这就像治病一样，你得先知道病因才能对症下药。
举个例子，当你在视频通话中说话时，声音首先被麦克风采集，这个过程需要时间。然后信号要经过编码处理，通过网络传输到对方那里，对方再解码、播放出来。这中间的每一个环节都会产生延迟，环环相扣，最后累积起来就变成了你能感知到的明显卡顿。
根据我的经验，整个传输链路中的延迟大致可以分为这几个部分：采集端的处理延迟、网络传输延迟、接收端的缓冲延迟以及解码播放延迟。其中网络传输延迟是最难控制的，因为它受到太多外部因素的影响。而其他几个环节，则是我们可以着重优化的对象。
影响延迟的关键因素
我整理了一个表格，把影响延迟的主要因素和它们的特性简单列了一下，这样看起来更直观：
| 因素类别 | 具体内容 | 可控程度 |
| 采集处理 | 麦克风/摄像头采集时间、信号预处理 | 较高 |
| 编码传输 | 编解码算法选择、码率控制、协议开销 | td>高|
| 网络传输 | 物理距离、路由跳数、拥塞程度、丢包率 | 低 |
| jitter buffer大小、动态调整策略 | 高 | |
| 渲染播放 | 音视频同步、渲染管线延迟 | 较高 |
从表格里你能看到，网络传输这部分虽然我们没法直接控制，但可以通过一些技术手段来"欺骗"用户，让他感觉延迟没那么高。而其他几个环节，则是我们真正可以大展身手的地方。
从采集到编码：源头优化的艺术
很多人一提到延迟优化，首先想到的就是网络传输层面的事情。但我觉得这个思路可能有点本末倒置了。如果你能在源头就把延迟控制好，后面的压力会小很多。
编解码器的选择是个技术活
编解码器这一块真的是我踩过很多坑的地方。早年间我们用过一些传统的编码器，压缩率确实高，但延迟也高得吓人。后来随着技术发展，情况好了很多，但选择依然很重要。
目前业界主流的做法是在延迟和压缩率之间找一个平衡点。对于实时通话场景，我们通常会选择延迟较低的编码器配置，比如把B帧数量控制在最少，甚至不用B帧。虽然这样会让码率稍微高一点，但换来的低延迟是完全值得的。
这里有个小技巧很多人可能不知道：编码器的"lookahead"参数对延迟影响很大。如果你把 lookahead 设得太长，编码器虽然能做出更优的决策，但代价就是延迟增加。在实时场景中，我建议把这个参数设得保守一些，或者干脆关掉。
分辨率和帧率的合理配置
我见过不少团队在配置参数时走入了一个误区：觉得分辨率越高、帧率越高，用户体验就越好。但实际上，如果你的网络条件撑不住这么高的配置，结果就是卡顿和延迟，反而适得其反。
我的做法是先了解清楚目标用户的网络环境大概是什么水平，然后在保证基本体验的前提下，设置一个动态调整的区间。比如在网络好的时候提升画质，网络差的时候主动降级。这种自适应策略虽然实现起来麻烦一点，但效果真的要好很多。
网络传输：与不确定性共舞
如果说编码优化是"内功"，那网络传输层面的优化就更像是"外功"了。这一块的不确定性太多，你永远不知道下一秒网络会变成什么样。
传输协议的选择
关于用UDP还是TCP这个问题，业界一直有争论。我的观点是，在实时音视频这个场景下，UDP通常是更好的选择。原因很简单：TCP的可靠传输机制虽然能保证数据不丢失，但在网络波动的时候，它会反复重传已经延迟的包，这些"迟到"的包对实时通信来说已经没用了，反而会拖累整体延迟。
当然，用UDP也不是说就完全不管了。你需要在应用层实现自己的丢包处理和重传机制，同时加上拥塞控制。这部分工作做得好不好，直接决定了你的系统在弱网环境下的表现。
拥塞控制：避免网络雪崩
拥塞控制是我觉得最容易出问题的地方，也是最能体现技术功底的地方。想象一下，当网络开始拥塞的时候，如果你还一个劲地往里塞数据，最后的结果就是大量丢包，然后触发更多的重传，形成恶性循环。
比较好的做法是实时监测网络的带宽状况，一旦发现拥塞迹象，立即降低发送码率。这里面关键是响应速度要快，不能等到已经丢包了才反应过来。同时，调整的幅度也要合适，一次性降得太厉害会让用户体验断崖式下降，逐步调整是更明智的选择。
说到拥塞控制，我想起来一个教训特别深的故事。早年我们做过一个项目，在实验室环境下测试一切都很好，结果一到真实网络就各种问题。后来排查了很久才发现，是我们用的拥塞控制算法太激进了，在网络稍微有点波动的时候就大幅降码率，导致体验反而变差。所以我说，这一块的调优真的需要在真实环境中反复打磨。
接收端：缓冲与抖动的艺术
如果说前面的工作都是在"生产"端，那接收端的工作重点就是"消费"。这里最大的挑战是如何处理网络带来的抖动——也就是数据包到达时间的不确定性。
jitter buffer：延迟与流畅的博弈
jitter buffer这个名字听起来挺专业，其实原理不难理解。简单说就是接收端会设置一个缓冲区，把先到的数据包暂时存起来，等后面的数据到了再一起处理。这个缓冲区存在的意义是平滑网络抖动，但代价就是增加了延迟。
这里面的权衡真的很难。缓冲区设得太小，稍微有点抖动就会导致音频断续或视频卡顿；设得太大，延迟又会高得让人受不了。我自己的经验是，最好能让这个缓冲区的大小动态调整——网络稳定的时候就缩小它，网络抖动的时候就放大它。
实现动态调整的关键是准确判断当前的抖动状态。常用的方法有计算数据包到达时间间隔的方差，或者监测连续丢包的情况。判断准确了，调整策略才能跟上。
音视频同步：容易被忽视的细节
音视频同步这个问题说大不大，说小不小。一旦出问题，用户会立即感觉到"嘴型对不上"或者"声音和画面不同步"，体验特别糟糕。
实现同步的核心方法是给每个数据包打上时间戳，接收端根据时间戳来安排播放时间。但实际操作中麻烦的地方在于，音频和视频的播放时钟可能不一样快，久了就会产生 drift，需要定期校准。
我常用的做法是让音频作为主时钟，因为人对音频的敏感度更高，视频稍微有一点延迟或提前通常不太容易被察觉。当检测到 drift 的时候，不是突然跳帧，而是通过调整播放速度让两者慢慢对齐，这个过程用户基本感知不到。
实际场景中的策略调整
理论说得差不多了，我想聊几个实际场景中的应用策略。不同场景对延迟的要求和容忍度其实差别很大，不能一刀切。
一对一视频通话
这种场景对延迟是最敏感的。试想一下，两个人面对面聊天，如果延迟超过几百毫秒，对话就会变得特别别扭，经常出现两个人同时说话或者抢话的情况。
在一对一场景中，我通常会把端到端延迟目标定在200毫秒以内。为了达到这个目标，需要在各个环节都精打细算：编码器要选低延迟的，网络传输要用UDP，jitter buffer 要尽可能小。同时，因为只有两个人，拥塞控制的压力也小一些，可以采用更激进一些的策略。
说到这个，我想起我们服务的一对一视频社交客户，他们对延迟要求特别高。后来我们一起做优化，把平均接通时间控制在了600毫秒以内，用户反馈明显好了很多。这种场景下，延迟每降低一点，用户体验都是能实实在在感受到的。
多人会议和直播连麦
多人场景的复杂度就上去了。当参与人数变多时，你需要考虑的事情也多了：谁的声音要混音，谁的视频要合成，网关的压力怎么分担。
一个常见的优化思路是分级处理。对于主要发言者，用高码率、低延迟的路线；对于旁听者，可以适当降低质量要求，用更经济的传输方式。这样既能保证关键体验，又能控制整体带宽压力。
另外值得一提的是，在多人场景中，音频的混音策略也很重要。如果不加控制地把所有人的声音都混进去，不仅听着乱，还会增加延迟。好的做法是只混当前正在说话的人的声音，其他人保持静音或低音量。
写在最后
啰嗦了这么多，我想强调的是，延迟优化不是一蹴而就的事情，它需要你在理解各个环节原理的基础上，根据实际场景反复调优。没有什么银弹，只有在实践中不断积累和迭代。
而且，随着网络技术的发展和硬件能力的提升，我们优化延迟的手段也在不断丰富。像声网这样的专业服务商一直在持续投入研发，把很多复杂的优化工作封装成标准化的服务，让开发者能更专注于业务本身。
如果你正在做相关的技术选型，我的建议是先想清楚自己的场景对延迟的容忍度是多少，然后针对性地去做优化。不要盲目追求极致的低延迟，有时候为了整体体验稍微牺牲一点，反而是更明智的选择。
好了，今天就聊到这里。如果你有什么想法或者问题，欢迎一起探讨。
