白话解读 WebRTC 音频 NetEQ 及优化实践_rtc里的 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 的出处

《GIPS NetEQ 原始文档》，这是由 GIPS 公司提供的最原始的 NetEQ 的说明文档（中文翻译），里面介绍了什么是 NetEQ 以及对其性能的简单说明。NetEQ 本质上就是一个音频的 JitterBuffer（抖动缓冲器），名字起的非常贴切，Network Equalizer（网络均衡器）。大家都知道 Audio Equalizer 是用来均衡声音的效果器，而这里的 NetEQ 是用来均衡网络抖动的效果器。而且 GIPS 还给这个名字注册了商标，所以很多地方看到的是 NetEQ ™ 。
上面的官方文档中，有一条很重要信息，“最小化抖动缓冲带来的延时影响”，这说明 NetEQ 的设计目标之一就是：“追求极低延时”。这个信息很关键，为我们后续的优化提供了重要线索。

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

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