【腾讯】一文读懂腾讯会议在复杂网络下如何保证高清音频( 五 ) |腾讯QQ|运营商|技术|

本文插图
另外如果仅仅是重传数据包，没有记录或者管理数据包从第一次到最后重传了多少次，这个包重传成功总共消耗了多少时间，这个环节是非常有价值的，包括许多开源算法包括 WebRtc 这一块的逻辑也是没有做的。通过对重传数据包所消耗的时间管理，可以精细化的去控制接下来我们会讲的 Jitter Buffer 之前的配合，比如我们有了这个重传消耗时长，我们就可以知道让 Jitter Buffer 未来的一段时间等待多久，另外对于已经解码成功的数据随着时间轴实时的在播放，如果时间轴播放到了某些缺失的数据包应该出现的地方，某些数据包再重传回来也不要了，这时候也要及时去更新重传列表，这也是重传效率的问题。

本文插图
怎么样去精细化升级算法，做了两方面的工作。一般重传两个关键因素，一个是重传次数，再一个是重传间隔。重传间隔首先不能小于 RTT ，一般都是 1 点几倍率的 RTT 时间间隔要一次包，在一个 RTT 时间去等它，如果不来再去要。然后还会考虑一个基于：“截断二进制指数退避“的算法概念。比如说 20% ，理论上重传几次就够了， 30%、40%、50% 甚至 80% 重传几次，如果超过这个次数的上限，再结合比如说带宽预测状态或者 RTT 值的情况，及时中止这种行为，这种行为可以避免系统本身因为算法本身不合理造成的流量雪崩。
音频的抗抖动处理接下来就是抗抖动。抖动怎么理解呢？有些网络情况下不太容易发生，在网络拥塞 Congestion Control 那块，我们在介绍 GCC1 和 GCC 算法的时候解释了 Jitter 的计算方法，以及它出现的一些原因。在使用 Wifi 网络的情况下经常有五六百毫秒抖动非常正常，所以如果对抗网络抖动也是一个非常关键的功能。从 GIPS 开源之前， NetEQ（Net equalizer）就被作为引擎内部的王牌特性，被用来对抗各种情况网络抗延时控制，以及抗击抖动的最佳算法实践。它开源以后，大家基于此的技术进行追踪、优化都是受益匪浅的。

本文插图
看左上角这个网络真实来包的情况，右下角则是期望通过抗抖处理送给解码器均匀的数据包，理想的包是这样顺序且均匀间隔的数据包，但现实总是不美好的，来的包总是非常不均匀，甚至几百毫秒没有数据，然后接下来突发几秒数据一起到来。这个 Jitter Buffer 的作用就是，尽量去维持合适的数据包水位，这个水位也最终会影响到整个系统的端到端延时，水位太低或者太高都是不行的，太高的话我们及时把这个降下来，太低我们要及时把它调整到认为合理的一个位置。合理的水位可以对抗网络突发，播放端则因为 Jitter Buffer 能够保持合理水位，拥有稳定持续的数据源用来播放，这对于用户最终听到完整和高质量的声音都是非常有帮助的。

本文插图
Jitter Buffer 通过监测什么变量去看抖动行为呢？刚才我们在网络拥塞控制那张讲的 Jitter 的计算，需要发送端时间戳和接收端时间戳去计算。而这里它只是通过相邻两个包到达时间的间隔，最终这个 IAT（Inter Arrival Time）的概念去表征这个时间间隔，他表示端到端前后两个数据包到达的时间间隔，这个 IAT 时间间隔归一化为包个数，对一定时间区间内的 IAT 数据做一个概率分布，它是满足正态分布的趋势，我们取它是满足 95% 的概率分布作为置信区间，选取其中的最大 IAT 来估算当前网络的大延时。