本文整顿自线上直播【MCtalk Live#2：RTC 零碎音频弱网反抗技术倒退与实际】网易云信资深音视频引擎开发专家崔承宗分享内容，文末也可查看直播回顾视频。
1、背景介绍
RTC（Real Time Communication）零碎广泛应用在视频会议、在线医疗、泛娱乐、在线教育等实时互动场景，为用户提供低延时、高清晰度和晦涩度、高保真音质的实时互动体验。音频弱网反抗技术旨在晋升 RTC 零碎在弱网（高丢包、大抖动、高提早）条件下的用户体验。
本文从 RTC 零碎的音频弱网成果、弱网反抗的诸多技术以及 RTC 零碎层面进行较为详尽的剖析，心愿能够帮忙读者对 RTC 零碎的音频弱网反抗技术有所理解。
2、常见音频弱网卡顿景象
理论场景中常见的音频弱网卡顿景象有如下表所示几次状况：
| 表 1 常见 RTC 利用音频弱网卡顿景象 | |||
|---|---|---|---|
| 序号 | 景象 | 排查门路 | 问题归类 |
| 1 | 音乐声音不丰满、发闷，飘忽、卡顿 | 确认 CODEC 采样率、码率，编码器类型 | CODEC 类 型选型，CODEC 参数设置 |
| 2 | 声音快进、慢放 | 网络 RTT，网络数据突发数据量，设施信号强度等 | 网络抖动、去抖动解决逻辑、网络连接信号差等 |
| 3 | 声音卡顿、卡死、断续 | 网络丢包率和 RTT、网络带宽预测、码率调配、网络拥塞管制等 | 网络拥塞、网络连接差等 |
3、RTC 零碎音频的抗性
针对上述音频卡顿景象，咱们该如何应答呢？表 2 列举了业界罕用的音频抗丢包算法和互相比照。
| 表 2 业界罕用的音频抗丢包算法比照 | |||||
|---|---|---|---|---|---|
| 比照 | 带外 FEC | Opus/SILK 带内 FEC | RED | ARQ | PLC |
| 提早 | 分组延时 + 单向传输的工夫 | 1 或者 2 倍帧长 + 单向传输的工夫 | RED 最大层数 N 倍的帧长 + 单向传输的工夫 | N 倍 RTT 的传输延时，N 是最大重传次数 | 无提早 |
| 应用形式 | 前向纠错 | 编码器个性 | 前向纠错 | 后验纠错 | 后验纠错 |
| 实用状况 | 随机丢包、网络 RTT 较大、包长度较大的场景 | 小丢包或者非间断丢包、编码器编码码率较高的场景 | 随机丢包、网络 RTT 较大、包长度较小的场景 | 突发丢包和继续丢包、网络 RTT 较小的场景 | 小丢包或者非间断丢包依据上下文或者邻近波形生成类似波形 |
| 实现难度 | 绝对简单，波及到发端、收端 FEC 编解码逻辑，动静冗余、反馈及时性等 | 绝对简略，波及编码器码率和网络丢包模型 | 复杂度低于带外 FEC，波及到动静冗余、反馈及时性等 | 看似简略，实际上网络简单场景下的挑战较大 | 绝对简单，通过波形相关性或者噪声填充，晋升抗丢包能力 |
上面，咱们具体介绍一下音频抗性的这几种算法。
抗丢包 FEC
前向纠错也叫前向纠错码（Forward Error Correction，简称 FEC），是减少数据通信可信度的办法。FEC 利用数据进行冗余信息的传输，当传输中呈现数据失落时，将容许接收端依据曾经接管的数据恢复失落数据。
如下图所示，咱们能够看到，发送端将数据包依据冗余度参数进行分组 (block)，对分组数据减少冗余。接收端在收齐分组后，即可复原失落数据（条件是失落不超过冗余包数）。因为接收端要期待 FEC 分组到齐，所以存在 FEC 复原算法上的延时，FecDelay = Block 个数 * 帧长。
图 1 发送端和接收端的 FEC 解决示意图
那么，罕用的 FEC 冗余算法包含哪些呢？
RTC 零碎中罕用的 FEC 冗余算法包含：XOR、Reed Solomon、喷泉码等。其中，以 XOR 和 Reed Solomon 算法的利用较为宽泛。
上面简略介绍一下 Reed Solomon 算法的数学背景。
Reed Solomon 算法的核心思想包含三个局部：
- 利用范德蒙德 (Vandermonde) 矩阵 F，通过数据块计算编码块（即算冗余矩阵），如图 2 所示
图 2 利用范德蒙德 (Vandermonde) 矩阵计算冗余矩阵示意图
- 利用高斯消元法(Gaussian elimination)，复原损坏的数据块（即算冗余矩阵的逆矩阵）
- 为了不便计算机解决，所有的运算是在伽罗华域 Galios, GF(2^w) 的根底上进行
抗丢包 RED
如前所述，RS FEC 算法因为波及矩阵运算，在发送端和接收端都会减少额定的性能开销。思考到音频包长度较小，采纳 RED（Redundant Audio Data）形式进行冗余是一种更有劣势的策略，能够进步数据包 payload 的利用率，并升高性能开销。
咱们举一个理论的例子：一个 RTP 音频数据包，包含一个 DVI4(8KHz) 主编码块和一个独自的 8KHz LPC 编码的冗余块，两者长度均为 20ms。参照 RFC 2198 规范所定义，示例格局如图 3 所示。
图 3 基于 RFC 2198 的 RED 组包示意图
抗丢包 ARQ
介绍了 FEC 和 RED 这两种前向纠错办法之后，上面咱们再看一下音频 ARQ。
音频 ARQ（主动重传申请）重传应用的是 NACK 形式，如下图。
图 4 发送端和接收端的 ARQ 解决示意图
假如是随机平均丢包场景，重传失败率概率为：Pn = P(n-1)*lossrate。对于音频来说，假如当重传失败概率 Pn<1% 时，认为重传胜利，那么 n 就是重传胜利所需的次数(截断二进制指数退却算法)。
各种丢包率条件下须要的实践重传次数如表 3 所示。
| 表 3 各种丢包率条件下须要的实践重传次数 | |
|---|---|
| 丢包率 | 须要重传的实践次数 |
| 10% | 1 |
| 20% | 2 |
| 30% | 3 |
| 40% | 5 |
| 50% | 6 |
| 60% | 8 |
| 70% | 10 |
| 80% | 21 |
咱们能够看一下两种状况：
- 假如 10% 丢包：重传一次失败的概率 10% * 10% = 1%。
- 假如 50% 丢包：重传一次失败 50%50%=25%，2 次：2550% = 12.5%，4 次: 3.125%，6 次：0.78%。
音频疾速重传 ARQ 就是以“抉择重传”算法作为根本的申请策略，其算法的要害特色在于重传申请与 JitterBuffer 的紧密配合。
- 申请重传模块记录并缓存所有重传数据包的重传胜利所耗费的工夫，并将重传延时 Arq Delay 告知 JitterBuffer 模块，进步了数据的缓冲期待时长的高可控性，参见(6)。
- 接收端通过 ARQ 申请，在数据缓冲队列的数据帧被播放之前，当还未重传胜利的数据帧在曾经达到播放工夫时，接收端通过 ACK 告诉勾销申请重传，缩小无用申请，参见(5)。
图 5 发送端和接收端的 NACK 申请和重传示意图
ARQ 策略受 RTT 影响较大，因为 ARQ 的原理是针对丢包进行选择性申请和重传，所以它对于突发丢包有较好的反抗能力，冗余码率的利用率远高于 FEC 和 RED。
ARQ 策略在应用中的难点是正当把握 NACK 申请的机会和距离以及重传包的码率管制，避免误申请、多申请和多重传，尤其在抖动场景下须要分外关注。
抗抖动
弱网环境除了丢包以外，在 4G 和 Wifi 等挪动接入场景中抖动和乱序较为常见，次要起因是挪动链路的多径烦扰、信号衰减、临频烦扰等。为了解决抖动和乱序，保障接收端数据包的有序接管，在 RTC 零碎的接收端引入抗抖动模块，原理如图 6 所示。
图 6 RTC 零碎的抗抖动模块原理示意图
抗抖动模块重要的组成部分之一是网络抖动的预测。抗抖动模块依据网络抖动的预测后果自适应调节 Jitterbuffer 长度，以达到抗抖动的目标，并可能在网络无抖动的时候保障低延时。抗抖动模块的抖动预测模块原理如图 7 和 8 所示。
Jitterbuffer 模块的网络延时预计是以 IAT（inter arrival time）为根底的。IAT 的含意是相邻包达到工夫距离。通话时间越长，包距离 IAT 的概率分布越稳固。察看周期内 IAT 的整体概率分布之和近似为 1。个别采纳 95% 作为满足统计概率的阈值，计算出 Jitterbuffer 的目标值大小。
图 7 抗抖动模块的抖动预测原理 1
图 8 抗抖动模块的抖动预测原理 2
抖动预测之后，须要对 buffer 中音频数据进行调节，罕用的做法是进行加加速播放。在须要拉伸 jitterbuffer 的时候进行慢放操作，在须要压缩 jitterbuffer 的时候进行快放操作。
- 语音时长修改（Time Scale Modification, TSM）是一种通过扩大或者压缩语音长度，从而扭转语音速度的技术。在进行时域压缩或者扩大的同时，还应尽量保障语音信号的基音频率及音色—即变长不变调。
- Wsola（波形形似同步叠加法）是一种基于语音信号准周期个性，进而插入基因周期整数倍的信号来实现波形长度变动的算法。
4、RTC 零碎音频的编解码
在介绍了 RED、ARQ 和抗抖动等弱网反抗技术之后，咱们再介绍一下基于音频编解码器实现的弱网反抗技术。
如下图，阐明了各种编解码器的品质与码率的关系：
图 9 音频编码器码率和品质比照图
图中绿色线条代表的是无专利要求且开源的编解码器，其中 G.711 和 G.722 是 ITU 晚期利用于电信网络的语音编码标准，相应只反对窄带和宽带频率范畴，码率绝对固定，压缩率较低。蓝色线条代表的是无专利要求然而闭源的编解码器，相比 G.711 和 G.722，它们反对的频带更广。最初，红色线条代表的是有专利要求并且闭源的编解码器，其中 AAC 和 MP3 是 Fraunhofer 主导制订的音乐编解码器规范，广泛应用在数字音乐畛域。
图 10 则阐明了各种编码器的编码提早与码率的关系：
图 10 音频编码器码率和编码延时比照图
从图中也能够看出，除了 Opus 以外，其余编解码器的码率变动范畴绝对较小，这与编解码器所笼罩的频带范畴相干。另外，不同编解码器的编码延时也有显著差别，MP3 和 AAC 等音乐编解码器的编码延时较大。
由此，咱们能够得出结论，Opus(RFC 6716) 是惟一一个笼罩全频带的音频编码器，并且它有如下的个性：
- 反对动态码率
- 在等同码率程度（高于 8kbps），其品质高于其余音频编码器
- 其编码提早低于其余音频编码器
带内 FEC
Opus 编解码器外部反对的原生带内 FEC 在 Speech 场景下，能够解决大概 20% 以内的丢包，其原理是通过以后帧携带前一帧的放大版压缩包信息来复原失落的信源。如图 11 所示。
图 11 官网 Opus inband FEC 抗丢包能力
具体到 Opus 编码器外部实现，inband FEC 是通过 LBRR（Low Bitrate Redundant）帧实现的。LBRR 帧蕴含了前一个音频帧的信息，和以后帧一起打包编码。图 12 是 LBRR 帧的编码代码。
图 12 Opus 带内 low bitrate redundant(LBRR)
PLC
以上介绍了多种带外抗丢包策略，上面简略介绍一下丢包弥补策略 PLC。
PLC（Packet Loss Concealment）丢包弥补是 Opus 编解码器中的一个可选项，在弱网传输场景下应该开启这个特色。
PLC 代码的实现依据收到的数据包模式的不同而有所不同：在 CELT 模式（audio）和 SILK 模式(speech)，PLC 别离采纳不同的形式进行丢包弥补。
图 13 Opus PLC 官网介绍
5、总结
最初，咱们总结一下音频 RTC 零碎整体的构造，从零碎角度剖析一下，如图 15 所示。
图 15 音频 RTC 零碎
明天分享了音频 RTC 零碎的弱网反抗技术与实际，总结值得咱们思考的几个方面：
- 外表上的音频卡顿，背地往往暗藏着各种各样的问题，须要对各个问题逐个进行剖析；
- RTC 零碎的任意一个环节出问题，最终出现给用户的就是有余的音频体验；
- RTC 零碎中各个模块组成一个有机整体，如何无效适应复杂多变的网络环境，将各个模块弱网反抗的能力有机联合，从而施展最大的作用，是一个颇具挑战的课题，值得咱们一直摸索。
以上，就是本次分享的全部内容，本次分享的视频内容，能够点击“这里”进行观看。
当初举荐好友应用网易云信，最低拿 3000 元京东卡处分，立刻举荐 >>
作者介绍
崔承宗，网易云信音视频引擎专家，10 余年音视频引擎开发教训，对 WebRTC 引擎、音视频会议零碎、视频编解码技术有肯定钻研和实践经验。
更多技术干货，欢送关注【网易智企技术 +】微信公众号