RTC 系统音频弱网对抗技术发展与实践

RTC(Real Time Communication)系统广泛应用在视频会议、在线医疗、泛娱乐、在线教育等实时互动场景,为用户提供低延时、高清晰度和流畅度、高保真音质的实时互动体验。音频弱网对抗技术旨在提升 RTC 系统在弱网(高丢包、大抖动、高延迟)条件下的用户体验。本文从 RTC 系统的音频弱网效果、弱网对抗的诸多技术以及 RTC 系统层面进行较为详尽的分析,希望可以帮助大家对 RTC 系统的音频弱网对抗技术有所了解。

作者:崔承宗 网易云信音视频引擎开发专家

一、常见音频弱网卡顿现象

实际场景中常见的音频弱网卡顿现象有如下表所示几种情况:

序号

现象

排查路径

问题归类

1

音乐声音不饱满、发闷,飘忽、卡顿

确认 CODEC 采样率、码率,编码器类型

CODEC 类型选型CODEC 参数设置

2

声音快进、慢放

网络 RTT,网络数据突发数据量,设备信号强度等

网络抖动、去抖动处理逻辑、网络连接信号差等

3

声音卡顿、卡死、断续

网络丢包率和 RTT、网络带宽预测、码率分配、网络拥塞控制等

网络拥塞、网络连接差等

二、RTC 系统音频的抗性

针对上述音频卡顿现象,我们该如何应对呢?下表列举了业界常用的音频抗丢包算法和相互对比。

对比

带外 FEC

Opus/SILK 带内FEC

RED

ARQ

PLC

延迟

理论最大延迟:分组延时+单向传输的时间,不受RTT 大小的影响

理论最大延迟:1或者2倍帧长+单向传输的时间,不受RTT 大小的影响

理论最大延迟:RED 最大层数 N 倍的帧长+单向传输的时间,不受 RTT 大小影响

N 倍 RTT 的传输延时,受到RTT 大小的影响,N 是最大重传次数

无延迟,通过接收端已经恢复数据生成未恢复数据

使用方式

前向纠错,发送端增加冗余数据,冗余度根据丢包率、网络 RTT 的反馈信息决定

编码器特性,设置编码器的带内 FEC开关和丢包率参数

前向纠错,发送端增加冗余数据,冗余度根据丢包率、网络 RTT 的反馈信息决定

后验纠错,针对性地重传丢失的数据包

后验纠错,针对性的生成未恢复数据

适用情况

随机丢包、网络 RTT 较大、包长度较大的场景

小丢包或者非连续丢包、编码器编码码率较高的场景

随机丢包、网络 RTT 较大、包长度较小的场景

突发丢包和持续丢包、网络RTT 较小的场景

小丢包或者非连续丢包根据上下文或者临近波形生成相似波形

实现难度

复杂,涉及到发端、收端FEC 编解码逻辑,动态冗余、反馈及时性等

简单,涉及编码器码率和网络丢包模型

复杂度低于带外 FEC,涉及到动态冗余、反馈及时性等

看似简单,实际上有些场景下的挑战较大(大网络RTT、抖动、限速)

复杂,通过波形相关性或者噪声填充,提升抗丢包能力。涉及传统信号处理和深度学习技术

不适用情况

短时间内的突发丢包解决方案:1. 常态FEC 策略。2. FEC 缓降策略

连续丢包、编码器码率较低场景,降低核心码率,影响音质

音频包长度较大。

短时间内的突发丢包解决方案:1. 常态RED 策略。2. RED 缓降策略

拥塞丢包,RTT 较大,大抖动场景解决方案:1.自适应开关 ARQ策略2.抖动场景识别策略3.HARQ 策略

4.ARQ 策略精准控制

连续丢包的场景

下面,我们详细介绍一下音频抗性的这几种算法。

(一)抗丢包 FEC

前向纠错也叫前向纠错码(Forward Error Correction,简称 FEC),是增加数据通信可信度的方法。FEC 利用数据进行冗余信息的传输,当传输中出现数据丢失时,将允许接收端根据已经接收的数据恢复丢失数据。

如下图所示,我们可以看到,发送端将数据包根据冗余度参数进行分组 (block),对分组数据增加冗余。接收端在收齐分组后,即可恢复丢失数据(条件是丢失不超过冗余包数)。因为接收端要等待 FEC 分组到齐,所以存在 FEC 恢复算法上的延时,FecDelay= Block 个数 * 帧长。

IMG_256

Figure 1:发送端和接收端的 FEC 处理示意图

那么,常用的 FEC 冗余算法包括哪些呢?

RTC 系统中常用的 FEC 冗余算法包括:XOR、Reed Solomon、喷泉码等。其中,以 XOR 和 Reed Solomon 算法的应用较为广泛。

下面简单介绍一下 Reed Solomon 算法的数学背景。

Reed Solomon 算法的核心思想包括三个部分:

  • 利用范德蒙德(Vandermonde)矩阵 F,通过数据块计算编码块(即算冗余矩阵),如图 2 所示:
IMG_257

Figure 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 所示。

IMG_258

Figure 3:基于 RFC 2198 的 RED 组包示意图

 (三)抗丢包 ARQ 

介绍了 FEC 和 RED 这两种前向纠错方法之后,下面我们再看一下音频 ARQ。

音频 ARQ(自动重传请求)重传使用的是 NACK 方式,如下图。

IMG_259

Figure 4:发送端和接收端的 ARQ 处理示意图

假设是随机均匀丢包场景,重传失败率概率为:Pn=P(n-1)*lossrate。对于音频来说,假设当重传失败概率 Pn<1% 时,认为重传成功,那么 n 就是重传成功所需的次数(截断二进制指数退避算法)。

各种丢包率条件下需要的理论重传次数如下表所示。

丢包率

需要重传的理论次数

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 次:25*50% = 12.5%,4 次: 3.125%,6 次:0.78%。
  • 音频快速重传 ARQ 就是以“选择重传”算法作为基本的请求策略,其算法的关键特色在于重传请求与 Jitterbuffer 的紧密配合。
  • 请求重传模块记录并缓存所有重传数据包的重传成功所消耗的时间,并将重传延时 Arq Delay 告知 Jitterbuffer 模块,提高了数据的缓冲等待时长的高可控性,参见 (6)。
  • 接收端通过 ARQ 请求,在数据缓冲队列的数据帧被播放之前,当还未重传成功的数据帧在已经达到播放时间时,接收端通过 ACK 通知取消请求重传,减少无用请求,参见(5)。
IMG_260

Figure 5:发送端和接收端的 NACK 请求和重传示意图

ARQ 策略受 RTT 影响较大,由于 ARQ 的原理是针对丢包进行选择性请求和重传,所以它对于突发丢包有较好的对抗能力,冗余码率的利用率远高于 FEC 和 RED。

ARQ 策略在使用中的难点是合理把握 NACK 请求的时机和间隔以及重传包的码率控制,防止误请求、多请求和多重传,尤其在抖动场景下需要格外关注。

(四)抗抖动 

弱网环境除了丢包以外,在 4G 和 Wifi 等移动接入场景中抖动和乱序较为常见,主要原因是移动链路的多径干扰、信号衰减、临频干扰等。为了处理抖动和乱序,保证接收端数据包的有序接收,在 RTC 系统的接收端引入抗抖动模块,原理如图6所示。

IMG_261

Figure 6:RTC 系统的抗抖动模块原理示意图

抗抖动模块重要的组成部分之一是网络抖动的预测。抗抖动模块根据网络抖动的预测结果自适应调节 Jitterbuffer 长度,以达到抗抖动的目的,并能够在网络无抖动的时候保证低延时。抗抖动模块的抖动预测模块原理如图 7 和 8 所示。

Jitterbuffer 模块的网络延时估计是以 IAT(inter arrival time)为基础的。IAT 的含义是相邻包到达时间间隔。通话时间越长,包间隔 IAT 的概率分布越稳定。观察周期内 IAT 的整体概率分布之和近似为1。一般采用 95% 作为满足统计概率的阈值,计算出 Jitterbuffer 的目标值大小。

图7

Figure 7:抗抖动模块的抖动预测原理 1

图8

Figure 8:抗抖动模块的抖动预测原理 2

抖动预测之后,需要对 buffer 中音频数据进行调节,常用的做法是进行加减速播放。在需要拉伸 Jitterbuffer 的时候进行慢放操作,在需要压缩 Jitterbuffer 的时候进行快放操作。

语音时长修正(Time Scale Modification, TSM)是一种通过扩展或者压缩语音长度,从而改变语音速度的技术。在进行时域压缩或者扩展的同时,还应尽量保证语音信号的基音频率及音色—即变长不变调。

Wsola(波形形似同步叠加法)是一种基于语音信号准周期特性,进而插入基因周期整数倍的信号来实现波形长度变化的算法。

三、RTC 系统音频的编解码

在介绍了 RED、ARQ 和抗抖动等弱网对抗技术之后,我们再介绍一下基于音频编解码器实现的弱网对抗技术。

如下图,说明了各种编解码器的质量与码率的关系:

IMG_266

Figure 9:音频编码器码率和质量对比图

图中绿色线条代表的是无专利要求且开源的编解码器,其中 G.711 和 G.722 是 ITU 早期应用于电信网络的语音编码标准,相应只支持窄带和宽带频率范围,码率相对固定,压缩率较低。蓝色线条代表的是无专利要求但是闭源的编解码器,相比 G.711 和 G.722,它们支持的频带更广。最后,红色线条代表的是有专利要求并且闭源的编解码器,其中 AAC 和 MP3 是 Fraunhofer 主导制定的音乐编解码器标准,广泛应用在数字音乐领域。

图 10 则说明了各种编码器的编码延迟与码率的关系:

IMG_267

Figure 10:音频编码器码率和编码延时对比图

从图中也可以看出,除了 Opus 以外,其他编解码器的码率变化范围相对较小,这与编解码器所覆盖的频带范围相关。另外,不同编解码器的编码延时也有明显差异,MP3 和 AAC 等音乐编解码器的编码延时较大。

由此,我们可以得出结论,Opus(RFC 6716) 是少数一个覆盖全频带的音频编码器,并且它有如下的特性:

  • 支持动态码率
  • 在同等码率水平(高于 8kbps),其质量高于其他音频编码器
  • 其编码延迟低于其他音频编码器

 (一)带内 FEC 

Opus 编解码器内部支持的原生带内 FEC 在 Speech 场景下,可以处理大约 20% 以内的丢包,其原理是通过当前帧携带前一帧的缩小版压缩包信息来恢复丢失的信源。如图 11 所示。

IMG_268

Figure 11:官方 Opus inband FEC 抗丢包能力

具体到 Opus 编码器内部实现,inband FEC 是通过 LBRR(Low Bitrate Redundant)帧实现的。LBRR 帧包含了前一个音频帧的信息,和当前帧一起打包编码。图 12 是 LBRR 帧的编码代码。

IMG_269

Figure 12:Opus 带内 low bitrate redundant(LBRR)

 (二)PLC

以上介绍了多种带外抗丢包策略,下面简单介绍一下丢包补偿策略 PLC。

PLC(Packet Loss Concealment)丢包补偿是 Opus 编解码器中的一个可选项,在弱网传输场景下应该开启这个特征。

PLC 代码的实现根据收到的数据包模式的不同而有所不同:在 CELT 模式(audio)和 SILK 模式 (speech),PLC 分别采用不同的方式进行丢包补偿。

IMG_270

Figure 13:Opus PLC 官方介绍

四、总结

最后,我们总结一下音频 RTC 系统整体的结构,从系统角度分析一下,如图 14 所示。

IMG_272

Figure 14:音频 RTC 系统

今天分享了音频 RTC 系统的弱网对抗技术与实践,总结值得我们思考的几个方面:

  • 表面上的音频卡顿,背后往往隐藏着各种各样的问题,需要对各个问题逐一进行分析;
  • RTC 系统的任意一个环节出问题,最终呈现给用户的就是不足的音频体验;
  • RTC 系统中各个模块组成一个有机整体,如何有效适应复杂多变的网络环境,将各个模块弱网对抗的能力有机结合,从而发挥最大的作用,是一个颇具挑战的课题,值得我们不断探索。

作者介绍

崔承宗,网易云信资深音视频引擎开发专家,10 余年音视频引擎开发经验,对 WebRTC 引擎、音视频会议系统、视频编解码技术有一定研究和实践经验。

关于网易云信

网易云信:网易智企旗下融合通信云服务专家、通信与视频 PaaS 平台。集网易 24 年 IM 以及音视频技术打造的融合通信云服务专家,稳定易用的通信与视频 PaaS 平台。提供融合通信与视频的核心能力与组件,包含 IM 即时通讯、5G 消息平台、一键登录、信令、短信与号码隐私保护等通信服务,音视频通话、直播、点播、互动直播与互动白板等音视频服务,视频会议等组件服务,并联合网易易盾推出一站式安全通信方案「安全通」。目前,网易云信已经成功发送 1.6 万亿条消息,覆盖智能终端 SDK 数累计超过 186 亿,我们期待每个智能终端都有云信的融合通信能力。

文章标题:RTC 系统音频弱网对抗技术发展与实践,发布者:网易智企,转载请注明出处:https://worktile.com/kb/p/5899

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
网易智企的头像网易智企认证作者
上一篇 2022年3月16日 下午11:28
下一篇 2022年3月16日 下午11:51

相关推荐

  • 国际项目如何管理好

    国际项目管理需要一套独特而细致的策略和技能,这是因为它涉及跨文化、地理和语言的复杂性。高效的沟通、深入的文化理解、精确的风险管理、灵活的项目计划、以及有效的团队建设是国际项目管理成功的关键。在这其中,高效的沟通尤其重要,因为在环球业务中,沟通不仅是交换信息,更是连接不同背景下团队成员的桥梁,确保项目…

    2024年4月10日
    5300
  • IT审计要干什么

    IT审计就是信息系统审计,主要介绍审计的历史和发展,对象、范围和意义对象、范围和意义计划。IT审计是独立于信息系统本身、信息系统相关开发、使用人员的第三方-IT审计师采用客观的标准对信息系统的策划、开发、使用维护等相关活动和产物进行完整地、有效地检查和评估。 一、IT审计要干什么 IT审计就是信息系…

    2023年7月27日
    60100
  • 绩效管理的难点是什么

    绩效管理的难点:1、需要整个公司的制度流程配合;2、执行过程艰难;3、获得真实、正确的数据困难;4、成为员工的一种负担;5、同一指标数据不同的部门反映的数据不同;6、无法与员工的日常办公结合起来;7、评价的主观因素多;8、无法做到实时监控。 1、需要整个公司的制度流程配合 目标绩效需要整个公司的制度…

    2023年1月1日
    1.8K00
  • 教学管理测试项目如何介绍

    教学管理测试项目介绍的关键在于明确目的、设计合理、评估体系完善、技术支持充分、持续改进。每个部分都起着至关重要的作用,共同构成了高效、有效的教学管理测试项目。尤其值得注意的是,设计合理部分对整个测试项目的成功起着决定性作用。设计合理不仅意味着测试内容与教学目标紧密相关,确保测试的针对性和实用性,而且…

    2024年4月10日
    5200
  • project.to在线浏览工具怎么打开mmp文件

    在使用project.to在线浏览工具打开mmp文件时,主要有以下步骤:1、访问网站;2、上传文件;3、浏览文件;4、调整设置;5、保存与分享;其中,访问网站是开始新的在线浏览任务,上传文件是打开mmp文件的关键。文件上传完毕后,你可以在网页上查看mmp文件的内容。project.to工具会将mmp…

    2023年7月11日
    3.6K10
  • vscode为什么不出iPad版

    Visual Studio Code (VSCode) 没有发布iPad版的主要原因包括:技术限制、市场考量、用户体验。集中探讨技术限制,是因为iPad上的操作系统(iOS/iPadOS)与传统的桌面操作系统有着本质的不同。iOS/iPadOS更加封闭、对应用程序的后台运行有着严格的限制,这对于需要…

    2024年4月3日
    9600
  • 什么是ARXML

    ARXML是一种用于描述汽车电子系统的XML格式。它是AUTOSAR(汽车开放系统架构)标准的一部分,被广泛用于汽车电子控制单元(ECU)的开发。ARXML主要描述了汽车电子系统的各种元素,包括硬件、软件、通信、系统配置等。 一、定义 ARXML是一种用于描述汽车电子系统的XML格式。它是AUTOS…

    2023年7月29日
    1.4K00
  • 为什么Jira中的项目延期

    Jira中的项目延期可能由于1、资源分配不当、2、估算不准确、3、任务依赖管理不当、4、沟通协作不畅以及5、变更管理不当原因导致。这其中,资源分配不当尤其值得关注,因为资源是项目成功的关键,不恰当的分配人力和物力资源会影响整个项目的进度。例如,优秀的开发人员可能被分配到不需要他们专长的任务上,或者某…

    2024年1月3日
    27200
  • iOS masonry为什么没有导致循环引用

    block循环引用的前提条件是调用对象直接或者间接对block持有强引用。而masonry的block方法实现中并不涉及。查看masonry源码可以看到究竟:masonry中设置布局的方法中的block对象并没有被View所引用,而是直接在方法内部同步执行,执行完以后block将释放。 block循…

    2023年5月28日
    47700
  • Saas应该如何立足中国的企业服务

    Saas应该如何立足中国的企业服务:1、SaaS服务可以降低企业的成本;2、SaaS软件推动企业信息化管理进程;3、SaaS产品无需企业维护和管理;4、使用SaaS软件无需额外付费;5、SaaS定价灵活,符合企业的发展模式。使用SaaS服务可以为企业节省大量成本。 一、SaaS服务可以降低企业的成本…

    2023年4月30日
    26500

发表回复

登录后才能评论
注册PingCode 在线客服
站长微信
站长微信
电话联系

400-800-1024

工作日9:30-21:00在线

分享本页
返回顶部