白话解读 WebRTC 音频 NetEQ 及优化实践

白话解读 WebRTC 音频 NetEQ 及优化实践

NetEQ 是 WebRTC 音视频核心技术之一，对于提高 VoIP 质量有明显的效果，本文将从更为宏观的视角，用通俗白话介绍 WebRTC 中音频 NetEQ 的相关概念背景和框架原理，以及相关的优化实践。

作者｜ 良逸 审校｜ 泰一

为什么要 “白话” NetEQ?

随便搜索一下，我们就能在网上找到很多关于 WebRTC 中音频 NetEQ 的文章，比如下面的几篇文章都是非常不错的学习资料和参考。特别是西安电子科技大学 2013 年吴江锐的硕士论文《WebRTC 语音引擎中 NetEQ 技术的研究》，非常详尽地介绍了 NetEQ 实现细节，也被引用到了很多很多的文章中。

《WebRTC 语音引擎中 NetEQ 技术的研究》 NetEQ 算法 WebRTC 中音频相关的 NetEQ

这些文章大部分从比较 “学术” 的或 “算法” 的角度，对 NetEQ 的细节做了非常透彻的分析，所以这里我想从更宏观一些的角度，说一下我个人的理解。白话更容易被大家接受，争取一个数学公式都不用，一行代码都不上就把思路说清楚，有理解不对的地方，还请大家不吝赐教。

丢包、抖动和优化的理解

在音视频实时通信领域，特别是移动办公（4G），疫情下的居家办公和在线课堂 （WIFI），网络环境成了影响音视频质量最关键的因素，在差的网络质量面前，再好的音视频算法都显得有些杯水车薪。网络质量差的表现主要有延时、乱序、丢包、抖动，谁能处理和平衡好这几类问题，谁就能获得更好的音视频体验。由于网络的基础延时是链路的选择决定的，需优化链路调度层来解决；而乱序在大部分网络条件下并不是很多，而且乱序的程度也不是很严重，所以接下来我们主要会讨论丢包和抖动。

抖动是数据在网络上的传输忽快忽慢，丢包是数据包经过网络传输，因为各种原因被丢掉了，经过几次重传后被成功收到是恢复包，重传也失败的或者恢复包过时的，都会形成真正的丢包，需要丢包恢复 PLC 算法来无中生有的产生一些假数据来补偿。丢包和抖动从时间维度上又是统一的，等一会来了的是抖动，迟到很久才来的是重传包，等一辈子也不来的就是 “真丢包”，我们的目标就是要尽量降低数据包变成 “真丢包” 的概率。

优化，直观来讲就是某个数据指标，经过一顿猛如虎的操作之后，从 xxx 提升到了 xxx。但我觉得，评判优化好坏不能仅仅停留在这个维度，优化是要 “知己知彼”，己是自己的产品需求，彼是现有算法的能力，己彼合一才是最好的优化，不管算法是简单还是复杂，只要能完美的匹配自己的产品需求，就是最好的算法，“能捉到老鼠的就是好猫”。

NetEQ 及相关模块

NetEQ 的出处

NetEQ 在音视频通讯 QoS 流程中的位置

音视频通讯对于普通用户来说，只要网络是通的，WIFI 和 4G 都可以，一个呼叫过去，看到人且听到声音，就 OK 了，很简单的事情，但对于底层的实现却没有看起来那么简单。单 WebRTC 开源引擎的相关代码文件数量就有 20 万个左右，代码行数不知道有没有人具体算过，应该也是千万数量级的了。不知道多少码农为此掉光了头发 :)。

NetEQ 原理及相关模块的关系

1. 首先是 NetEQ 的输入部分：

底层 Socket 收到一个 UDP 包后，触发从 UDP 包到 RTP 包的解析，经过对 SSRC 和 PayloadType 的匹配，找到对应的音频流接收的 Channel，然后从 InsertPacketInternal 输入到 NetEQ 的接收模块中。

收到的音频 RTP 包很可能会带有 RED 冗余包（redundance），按照 RFC2198 的标准或者一些私有的封装格式，对其进行解包，还原出原始包，重复的原始包将会被忽略掉。解出来的原始 RTP 数据包会被按一定的算法插入到 packet buffer 缓存里面去。之后会将收到的每一个原始包的序列号，通过 UpdateLastReceivedPacket 函数更新到 Nack 重传请求模块，Nack 模块会通过 RTP 收包或定时器触发两种模式，调用 GetNackList 函数来生成重传请求，以 NACK RTCP 包的格式发送给推流侧。

同时，解完的每一个原始包，得到了时间轴上唯一的一个接收时刻，包和包之间的接收时间差也能算出来了，这个接收时间差除以每个包的打包时长就是 NetEQ 内部用来做抖动估计的 IAT（interarrival time），比如，两个包时间差是 120ms，而打包时长是 20ms，则当前包的 IAT 值就是 120/20=6。之后每个包的 IAT 值经过核心的网络抖动估计模块（DelayManager）处理之后，得到最终的目标水位（TargetLevel），到此 NetEQ 的输入处理部分就结束了。

2. 其次是 NetEQ 的输出部分：

输出是由音频硬件播放设备的播放线程定时触发的，播放设备会每 10ms 通过 GetAudioInternal 接口从 NetEQ 里面取 10ms 长度的数据来播放。

进入 GetAudioInternal 的函数之后，第一步要决策如何应对当前数据请求，这个任务交给操作决策模块来完成，决策模块根据之前的和当前的数据和操作的状态，给出最终的操作类型判断。NetEQ 里面定义了几种操作类型：正常、加速、减速、融合、拉伸（丢包补偿）、静音，这几种操作的意义，后面再详细的说。有了决策的操作类型，再从输入部分的包缓存（packet buffer）里面取出一个 RTP 包，送给抽象的解码器，抽象的解码器通过 DecodeLoop 函数层层调用到真正的解码器进行解码，并把解码后的 PCM 音频数据放到 DecodedBuffer 里面去。然后就是开始执行不同的操作了，NetEQ 里面为每一种操作都实现了不同的音频数字信号处理算法（DSP），除了 “正常” 操作会直接使用 DecodedBuffer 里的解码数据，其它操作都会结合解码的数据进行二次 DSP 处理，处理结果会先被放到算法缓存（Algorithm Buffer）里面去，然后再插入到 Sync Buffer 里面。Sync Buffer 是一个循环 buffer，设计的比较巧妙，存放了已经播放过的数据、解码后未播放的数据，刚刚从算法缓存里插入的数据放在 Sync Buffer 的末尾，如上图所示。最后就是从 Sync Buffer 取出最早解码后的数据，送出去给外部的混音模块，混音之后再送到音频硬件来播放。

另外，从图上可以看出决策模块（BufferLevelFilter）会结合当前包缓存 packet buffer 里缓存的时长，和 Sync Buffer 里缓存的数据时长，经过算法过滤后得到音频当前的缓存水位。音视频同步模块会使用当前音频缓存水位，和视频当前缓存水位，结合最新 RTP 包的时间戳和音视频的 SR 包获得的时间戳，计算出音视频的不同步程度，再通过 SetMinimumPlayoutDelay 最终设置到 NetEQ 里面的最小目标水位，来控制 TargetLevel，实现音视频同步。

NetEQ 内部模块

NetEQ 抖动估计模块（DelayManager）

1. 平稳抖动估计部分：

将每个包的 IAT 值，按照一定的比例（取多少比例是由下面的遗忘因子部分的计算决定的），累加到下面的 IAT 统计的直方图里面，最后计算从左往右累加值的 0.95 位置，此位置的 IAT 值作为最后的抖动 IAT 估计值。例如下图，假定目标水位 TargetLevel 是 9，意味着目标缓存数据时长将会是 180ms（假定打包时长 20ms）。

2. 平稳抖动遗忘因子计算：

3. 峰值抖动估计：

NetEQ 操作决策模块（DecisionLogic）

决策模块的简化后的基本判定逻辑，如下图所示，比较简洁不用解释。这里解释一下下面这几个操作类型的意义：

作者最后的话：需求不停歇，优化无止境！

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。