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 的出处
《GIPS NetEQ 原始文档》，这是由 GIPS 公司提供的最原始的 NetEQ 的阐明文档（中文翻译），外面介绍了什么是 NetEQ 以及对其性能的简略阐明。NetEQ 实质上就是一个音频的 JitterBuffer（抖动缓冲器），名字起的十分贴切，Network Equalizer（网络均衡器）。大家都晓得 Audio Equalizer 是用来平衡声音的效果器，而这里的 NetEQ 是用来平衡网络抖动的效果器。而且 GIPS 还给这个名字注册了商标，所以很多中央看到的是 NetEQ (TM)。
下面的官网文档中，有一条很重要信息，“最小化抖动缓冲带来的延时影响”，这阐明 NetEQ 的设计指标之一就是：“谋求极低延时”。这个信息很要害，为咱们后续的优化提供了重要线索。
NetEQ 在音视频通信 QoS 流程中的地位
音视频通信对于普通用户来说，只有网络是通的，WIFI 和 4G 都能够，一个呼叫过来，看到人且听到声音，就 OK 了，很简略的事件，但对于底层的实现却没有看起来那么简略。单 WebRTC 开源引擎的相干代码文件数量就有 20 万个左右，代码行数不晓得有没有人具体算过，应该也是千万数量级的了。不晓得多少码农为此掉光了头发 :)。
上面这张图，是对实际上更简单的音视频通信流程的形象和简化。右边是发送 (推流) 侧：通过采集、编码、封装、发送；两头通过网络传输；左边是接管 (拉流) 侧：接管、解包、解码、播放；这里重点体现了 QoS（Quality of Service，服务质量）的几个大的性能，以及跟推拉流数据次要流程的关系。能够看到 QoS 性能扩散在音视频通信流程中的各个地位，导致要理解整个流程之后能力对 QoS 有比拟全面的了解。图上看起来右边发送侧的 QoS 性能要多一些，这是因为 QoS 的目标就是要解决通信过程中的用户体验问题，要解决问题，最好就是找到问题的源头，能从源头解决的，都是比拟好的解决形式。但总有一部分问题是不能从源头来解决的，比方在多人会议的场景，一个人的收流侧网络坏了，不能影响其它人的散会体验，不能呈现“一颗老鼠屎坏掉一锅粥”的状况，不能污染源头。所以收流也要做 QoS 的性能，目前收流侧的必备性能就是 JitterBuffer，包含视频的和音频的，本文重点剖析音频的 JitterBuffer — NetEQ。
NetEQ 原理及相干模块的关系
下面这张图是对 NetEQ 及其相干模块工作流程的形象，次要蕴含 4 个局部，NetEQ 的输出、NetEQ 的输入、音频重传 Nack 申请模块、音视频同步模块。为什么要把 Nack 申请模块和音视频同步模块也放进 NetEQ 的剖析中？因为这两个模块都间接跟 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. 安稳抖动忘记因子计算：
忘记因子是用来管制以后包的 IAT 值取多少比例累加到下面的直方图外面去的系数，计算过程用了一个看起来比较复杂的公式，通过剖析，其本质就是上面的黄色曲线，意思是开始的时候忘记因子小，会取更多的以后包的 IAT 值来累加，随着时间推移，忘记因子逐步变大，会取更少的以后包 IAT 值来累加。这个过程搞的有点简单，从工程角度看齐全能够简化成直线之类的，因为测试下来 5s 左右的工夫，根本就收敛到目标值 0.9993 了，其实这个 0.9993 才是影响抖动预计的最次要的因素，很多优化也是间接批改这个系数来调节预计的灵敏度。
3. 峰值抖动预计：
DelayManager 中有一个峰值检测器 PeakDetector 用来辨认峰值，如果频繁检测到峰值，会进入峰值抖动的预计状态，取最大的峰值作为最终预计后果，而且一旦进入这个状态会始终维持 20s 工夫，不论以后抖动是否曾经恢复正常了。上面是一个示意图。
NetEQ 操作决策模块（DecisionLogic）
决策模块的简化后的根本断定逻辑，如下图所示，比拟简洁不必解释。这里解释一下上面这几个操作类型的意义：
- ComfortNoise：是用来产生舒服噪声的，比单纯的静音包听起来会更难受的静音状态；
- Expand（PLC）：丢包弥补，最重要的无中生有算法模块，解决“真丢包”时没数据的问题，造假专业户；
- Merge：如果上一次是 Expand 造假进去的数据，那为了听起来更难受一些，会跟失常数据包做一次交融算法；
- Accelerate：变声不变调的减速播放算法；
- PreemptiveExpand：变声不变调的加速播放算法；
- Normal：失常的解码播放，不额定引入假数据；
NetEQ 相干模块优化点
NetEQ 抗抖动优化
- 因为 NetEQ 的设计指标是“极低延时”，不能很好的匹配，视频会议，在线课堂，直播连麦等非极低延时场景，须要对其敏感度进行调整，次要调整抖动预计模块相干的灵敏度；
- 直播场景，因为对于延时敏感度能够到秒级以上，所以须要启用 StreamMode 的性能（新版本中如同去掉了），而且也须要对其中参数进行适配；
- 服务于极低延时指标，原始的包缓存 packetbuffer 太小，容易造成 flush，须要按业务须要调大一些；
- 还有一些业务会依据本人的业务场景被动辨认网络情况，而后间接设置最小 TargetLevel，简略粗犷的管制 NetEQ 的水位。
NetEQ 抗丢包优化：
- 原始的 WebRTC 的 Nack 丢包申请的触发机制是用包触发的，在弱网下会好转重传成果，能够改为定时触发来解决；
- 丢包场景会有重传，但如果 buffer 太小，重传也会被抛弃，所以为了进步重传效率，减少 ARQ 延时预留性能，可明显降低拉伸率；
- 比拟算法级的优化是对丢包弥补 PLC 算法的优化，调整现有 NetEQ 的拉伸机制，优化听感成果；
- 开启 Opus 的 Dtx 性能之后，在丢包场景会导致音频 Buffer 变大，须要独自优化 Dtx 相干解决逻辑。
上面是 ARQ 延时预留性能开启后的成果比照，均匀拉伸率升高 50%，延时也会相应减少：
音视频同步优化：
- 原始的 WebRTC 的 P2P 音视频同步算法是没有问题的，然而目前架构下面个别都有媒体转发服务器（SFU），而服务器的 SR 包生成算法可能会因为某些限度或者谬误会不完全正确，导致无奈失常同步，为躲避 SR 包生成谬误，须要优化音视频同步模块的计算形式，应用水位为次要参考来同步，即在接收端保障音视频的缓存工夫是差不多大小的。上面是优化成果的比照：
- 还有一种音视频同步的问题，其实不是音视频同步机制导致的，而是设施性能有问题，不能及时处理视频的解码和渲染，导致视频数据累积，从而造成的音视频不同步。这种问题能够通过比照不同步时长的趋势，跟视频解码和渲染时长的趋势，两者匹配度会很高，如下图所示：
总结
NetEQ 作为音频接管侧的外围性能 ，基本上蕴含了各个方面，所以很多很多音视频通信的技术实现里都会有它的形迹，乘着 WebRTC 开源快 10 年的东风，NetEQ 也变的十分遍及，心愿这篇文言文章能帮大家更好的了解 NetEQ。
作者最初的话：需要不停歇，优化无止境！
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。