实时音视频技术中的网络抖动的补偿

如果你曾经打过视频会议，或者用过直播连麦，可能会遇到这样一种情况：画面突然卡住，声音断断续续，过几秒钟又恢复正常。明明网络图标显示信号还不错，为什么会出现这种让人烦躁的体验？这背后的”罪魁祸首”之一，就是我们今天要聊的网络抖动。

网络抖动这个词，听起来有点专业，其实理解起来并不难。简单说，就是数据包在传输过程中”走路不稳”，有的快有的慢，到达时间不一致。在实时音视频通话中，这种不一致会导致接收端收到的数据像一列忽快忽慢的火车，严重影响播放的流畅性。今天我想用比较直白的方式，聊聊实时音视频技术中是怎么对付这个问题的。

网络抖动到底是什么

在说怎么补偿之前，咱们先搞清楚网络抖动是怎么产生的。你可以想象一下寄快递的场景：从北京发一批货到上海，正常情况下应该差不多同时到达。但实际上，因为交通状况、路线选择、天气原因等因素影响，有的包裹可能早上出发中午到，有的可能下午出发晚上到，还有的可能在中转站多停了一会儿。这种”到货时间不一致”的情况，在网络世界里就叫抖动。

在互联网传输中，数据包要经过多个路由器和节点，每个节点的处理能力、队列长度、当时的网络负载都不一样。举个具体的例子，当你和朋友视频通话时，你这边采集的音视频数据被打包成一个个小数据包，通过网络传输到对方那里。理想状态下，这些包应该以均匀的时间间隔到达。但现实中，因为网络拥堵、路由变化、无线信号干扰等原因，可能第1个包花了100毫秒到，第2个包因为走了不同的路由花了180毫秒，第3个包又因为网络暂时拥堵花了250毫秒。这种到达时间的波动，就是抖动。

抖动的单位是毫秒，一般来说，50毫秒以内的抖动大多数用户感知不明显，超过100毫秒就开始影响体验，到200毫秒以上时就比较明显了。需要说明的是，抖动和延迟不是一回事。延迟是数据包从发送到接收的总时间，而抖动是这总时间的变化程度。一条网络延迟可能只有50毫秒，但如果忽快忽慢，波动范围达到30毫秒，那抖动感就会很强。

抖动对实时音视频的影响有多大

很多人可能会问，既然延迟不高，为什么抖动能造成那么大的影响？这就要从音视频数据的播放机制说起了。

不管是声音还是视频，本质上都是一系列按时间顺序排列的数据帧。播放的时候，需要按照原来的时间顺序来呈现，否则就会出现错乱。比如视频里一个人说话，画面和声音必须对上；如果画面先到声音后到，或者反过来，就会出现”声画不同步”的诡异感。再比如视频会议中，你看到对方嘴巴在动，但声音却慢半拍，这种体验是非常别扭的。

正常播放时，接收端会有一个缓冲区，会按照固定的时间间隔从缓冲区里取数据来播放。假设每秒播30帧，那每帧之间的间隔大约是33毫秒。如果数据包都能按时到达，播放就很流畅。但如果数据包来得不均匀，播放就会出问题——该到的没到，只能等待或者用空白填充；该播放的没到，就只能卡住。

我整理了一个表格，展示不同抖动程度对应的实际影响：

<td具体表现

从这个表格可以看出，抖动对体验的影响是非线性的。一旦超过某个阈值，体验就会急剧下降。这也是为什么实时音视频领域对抖动问题如此重视的原因。

抖动缓冲：最基础的应对策略

既然知道了问题所在，那怎么解决呢？最直接的想法就是在接收端放一个”蓄水池”，让数据先到这个蓄水池里待一会儿，匀一匀再播放。这个蓄水池就是抖动缓冲（Jitter Buffer）。

抖动缓冲的工作原理其实挺朴素的。接收端收到数据包后，不立即播放，而是先存在一个缓冲区里。同时，缓冲区会根据网络状况动态调整延迟时间——网络比较稳的时候就少等一会儿，网络波动大的时候就多等一会儿。这样一来，从缓冲区里取出来的数据就相对均匀了，播放也就流畅了。

这就像做饭时洗米，米里会有一些小石子。简单粗暴的做法是直接下锅，但这样会吃到”咯牙”的；更好的做法是让米在水里泡一会儿，小石子沉到下面，倒水的时候把小石子倒掉。抖动缓冲起的就是这个”让杂质沉淀”的作用。

当然，这个方案有个天然的矛盾：缓冲区延迟越久，抵抗抖动的能力越强，但端到端的延迟也越高。打视频电话时，如果延迟超过三四百毫秒，对话就会变得很别扭——你说完了对方要过一会儿才回应，两个人很容易出现抢话或者冷场的尴尬场面。所以抖动缓冲需要在”抗抖动能力”和”通话延迟”之间找一个平衡点。

好的抖动缓冲算法会根据实时的网络状况自动调整这个平衡点。网络状况好的时候减少缓冲时间，降低延迟；察觉到网络开始波动就适当增加缓冲，提高稳定性。这种”看菜下饭”的策略听起来简单，实现起来其实要考虑很多因素，比如网络状态的预测、历史数据的分析、突发情况的处理等等。

前向纠错：用冗余换可靠性

除了抖动缓冲，还有一种思路是从数据本身入手，那就是前向纠错（Forward Error Correction，简称FEC）。

FEC的核心思想是”主动备份”。在发送数据的时候，除了发送当前的数据包，还会额外发送一些冗余信息。这些冗余信息按照一定的算法生成，接收端即使丢了一些数据包，也能通过冗余信息把丢失的内容恢复出来。

举个生活中的例子帮助理解。比如你要传一句话”今天天气很好”，为了防止传输中丢字，你可以多传一遍：”今天今天天天天气气很好好”。这句话看起来很冗余，但即便丢了一半的字，接收方依然能推断出原句的意思——”今天天气很好”。当然实际算法比这个聪明得多，冗余度也可以灵活控制。

FEC对抖动的帮助在于，它能够降低丢包带来的影响。因为抖动往往伴随着丢包——当一个数据包来得太晚，可能已经被判定为丢失，需要重传。而重传需要额外的时间，这又会加剧抖动的影响。如果有了FEC，某些丢包可以通过冗余直接恢复，不需要等待重传，整个体验就会流畅很多。

当然FEC也有代价，主要是带宽消耗和计算资源。发的冗余数据越多，抗丢包能力越强，但消耗的资源也越多。所以在实践中需要在冗余度和资源消耗之间权衡，也会根据网络状况动态调整——网络好的时候少发冗余，网络差的时候多发。

带宽自适应：让传输量随网而变

还有一类方法是从源头控制，那就是带宽自适应算法。这类算法的思路是：与其在网络不好的时候被动应付，不如主动调整数据传输量，让网络始终处于”吃得消”的状态。

具体来说，发送端会实时监测当前网络的带宽状况，包括延迟、丢包率、抖动等指标。如果发现网络开始变差，就主动降低码率——也就是减少每个数据包携带的信息量，或者减少单位时间内发送的数据包数量。这样一来，网络承载的压力就小了，传输也会更稳定。

这有点像开车时遇到拥堵的处理方式。如果你一直按原来的速度往前挤，最后很可能是进退两难、动弹不得；更好的做法是放慢速度，和前车保持安全距离，虽然整体速度慢了，但至少能稳步前进。带宽自适应就是给数据传输”踩一脚刹车”，目的是避免更严重的拥堵。

在实现带宽自适应的时候，有一个关键问题需要解决：如何准确评估当前网络的带宽容量？测得太保守，会浪费网络资源；测得太激进，会导致拥塞。业界有多种算法来回答这个问题，比如基于丢包的判断、基于延迟变化的判断，或者两者结合。不同的算法各有优劣，实际产品中往往会组合使用。

声网的实践：综合应对网络抖动

说到这里，我想结合声网在实时音视频领域的一些实践来谈谈。毕竟前面说的都是通用原理，真正落地的时候要考虑很多工程细节。

声网的全球网络覆盖了很多地区，网络环境千差万别。从网络类型来看，有有线宽带、4G、5G、WiFi，还有各种复杂的网络场景；从地理位置来看，不同国家、不同运营商的网络质量也参差不齐。在这样的背景下应对抖动挑战，需要一个综合性的方案。

首先是精准的实时网络评估。声网在传输层做了大量的监控和探测工作，能够快速感知网络的延迟变化、丢包情况和抖动程度。这个评估不是简单地看一下指标，而是要考虑很多因素——比如当前的网络类型是什么，是移动通信还是固定网络？用的什么协议？有没有NAT穿透的问题？这些背景信息都会影响判断的准确性。

有了准确的网络评估，下一步是智能的传输策略选择。声网的传输引擎会根据评估结果，自动选择最合适的抗抖动方案组合。比如在网络比较稳定的时候，可以适当降低缓冲延迟，提升响应速度；在网络波动较大的时候，就增强FEC冗余度和抖动缓冲的深度，保证通话的稳定性。

还有一个值得关注的是端到端的延迟控制。很多时候，抖动的根源在于网络路径的选择。如果数据包走的路径本身就不稳定，再好的缓冲算法也难以根治问题。所以声网在全球部署了大量边缘节点，通过智能路由选择，尽量让数据包走更稳定的路径。这就像出差时选择航班，直飞通常比中转更准时，也更省心。

一些思考

回顾一下今天聊的内容，我们从网络抖动的定义出发，分析了它对实时音视频的影响，然后介绍了几种主要的应对策略：抖动缓冲、前向纠错、带宽自适应，以及声网在实践中的综合运用。

说真的，网络抖动这个问题，说大不大，说小不小。在网络条件好的时候，它可能根本不是问题；但一旦网络条件恶化，它就会成为影响体验的关键因素。实时音视频发展了这么多年，各种抗抖动技术也在不断进化，但从根本上说，这是一个和网络本身特性做斗争的过程。只要互联网还是”尽力而为”的传输模式，抖动就不会完全消失。

技术进步的方向，一方面是算法和策略的优化，让系统在面对抖动时更加从容；另一方面是基础设施的建设，让网络本身更加稳定可靠。这两方面是相辅相成的。作为从业者，我能感受到这个领域还有很多可以探索的空间，也期待看到更多好的解决方案出现。

如果你在实际使用中遇到了音视频卡顿的问题，不妨想想今天聊的这些内容。也许问题就出在抖动上，而理解这些原理，有助于你更好地判断问题所在，或者在产品选择时做出更明智的决定。