关于音视频:网易云信-RTC-音频-QoS-综述

6次阅读

共计 3264 个字符，预计需要花费 9 分钟才能阅读完成。

RTC 实时通信，泛指各种数据的实时传输技术，包含音频，视频，文本，图片等媒体和非媒体数据的实时传输。

QoS 服务质量，指一个网络可能利用各种根底技术，为指定的网络通信提供更好的服务能力，是网络的一种平安机制，是用来解决网络提早和阻塞等问题的一种技术。

RTC 技术的呈现满足了用户通过互联网进行实时音视频通话的需要，在 QoS 技术的加持下，RTC 技术在简单的网络条件下能达到更高的弱网抗性、更低的提早，极大地晋升用户的实时通话体验。

WebRTC 是一个由 Google 发动的实时通信解决方案，其中蕴含视频音频采集、编解码、传输、QoS、音视频渲染等性能。其名为 WebRTC，然而实际上它不光反对 Web 之间的音视频通信，还反对 Android 以及 IOS 端。因为该我的项目是开源的，各即时通讯厂商都基于 WebRTC 进行钻研、开发，研制本身的全平台的 RTC 解决方案。

WebRTC 中有很多优良的算法、设计值得钻研，音频 QoS 技术就是其中之一。

音频 QoS 技术次要包含了：带宽预计及编码码控、DTX、FEC、RED、RTX/NACK、减速 / 加速 /PLC 等。

音频数据尽管没有视频数据那么大的量，但在 QoS 方面同样要面对：带宽、提早、品质之间的三维均衡。把音频 QoS 技术的各项能力归纳到这三维均衡问题中时，咱们能够晓得：

带宽预计及编码码控：在既定的网络带宽状况下，预计的带宽越高、编码码率越高，音频品质越好；

DTX（输出编码器的音量低时编码器编出静音批示数据，后续不出编码数据或出静音批示数据，直到输出音量不再低）：无效节俭静音状况下的编码码率；

FEC（通过前向纠错编解码算法，实现丢包复原）：冗余度越高，复原率越高，但带宽耗费越大；分组越大，复原率越高，复原提早越大；在低丢包率、非间断丢包状况下，具备码率劣势；

RED（原始音频包同时携带冗余的音频包）：冗余层数越多，带宽耗费越大；在低丢包率、非间断丢包、高提早状况下，具备复原提早劣势；对于冗余包拓展头的反对水平因实现而异；

RTX/NACK（丢包重传 / 丢包申请）：丢包重传属于按需重传，丢包越高，重传需要越高，带宽耗费越大，须要防止重传风暴；在高丢包、间断丢包状况下，具备复原率劣势，但有较大的复原提早劣势；

减速：接收端缓冲过多时，通过减速升高缓冲量，升高提早，会带来肯定的减速感；

加速：接收端缓冲有余时，通过加速晋升缓冲量，减少提早，会带来肯定的加速感；

PLC（丢包弥补）：接收端缓存缺失时，通过收到的前序包模仿失落包，会带来肯定的音质伤害。

从整体角度看，RTC 实时音视频零碎至多会波及 3 个端：发送端、服务端、接收端。云信 RTC 以 SFU 架构实现客户端媒体流的接入和转发。以此为根底造成了发送端到服务、服务到接收端（服务级联由网易云信 WE-CAN 大网提供）的分段 QoS 策略。

分段 QoS 的劣势在于，上下行独立进行 QoS 策略有利于隔离上行段、上行段不同网络状况，对每条链路实用更佳的应答办法。但其劣势在于，策略的设计、开发、调优会更加简单，问题排查难度减少，服务端性能可能成为瓶颈。

带宽预计次要用来对发送端（或服务器的上行转发端）进行码率管制。

上行端侧通过 GCC（Google Congestion Contrl）算法基于接收端的数据反馈对其发送带宽进行预计。预计出的带宽会调配到编码码率、RED 码率、FEC 码率、RTX 码率、PADDING（填充）码率。尽管带宽预计算法在各公司是大同小异，然而带宽调配策略却是形形色色。因为如何分派编码码率和抗性码率（包含 RED、FEC、RTX）决定了一款 RTC 产品在媒体品质、会话提早、带宽消耗上的竞争力高下。

服务器上行转发侧同样也有带宽预计算法。服务端对上行链路的带宽预计后果是基于会话的，但服务端同时接通一个会议中的多个上行会话，因而服务端能够汇总多个上行会话的带宽预计后果，联合场景，利用如 topN 带宽回传上行做码率束缚、VIP 用户 QoS 优先保障等策略，晋升服务端的带宽利用率。

在带宽预计畛域还有许多能够优化的方向，比方：反馈的码率纳入带宽预计、基于机器学习进行带宽预计和调配。

OPUS 音频编码器的 DTX 个性，可能无效升高发声静音时的码率，它利用静音时发送端每 400ms 编码发送一个 DTX 包告诉接收端静音状态仍在继续，接收端在接管到首个 DTX 包后，进入 DTX 状态，每次音频设备获取数据时编码器输入一个静音帧。服务端对 DTX 进行透传。

WebRTC 利用 OPUS 的 DTX 个性引入了一些断流误判、收包反馈的问题。云信对此进行了优化，利用了静音状态码率低的个性，同时保障了数据流的连续性。

端侧 FEC 分带内和带外两种，WebRTC 中视频是通过带外 FEC（ULPFEC、FLEXFEC）来产生冗余包，音频则能够通过 OPUS 带内 FEC、带外 FEC 来生成冗余包。服务端 FEC 是用带外 FEC。

带内 FEC 因为会占用一部分编码码率，所以对音频的音质会有所升高。带外 FEC 不会影响音质，但会额定占用网络带宽，各有优缺点。

FEC 典型的编码方式有 XOR 和 Reed Solomon。WebRTC 的带外 FEC 应用的是 XOR 编码方式，其特点是计算量绝对少，但其抗丢包能力无限。

在 WebRTC 中，带外 FEC，不论是 ULPFEC，还是 FLEXFEC 都是依据 MASK 掩码来确定 FEC 包和被爱护的源 RTP 包的映射关系，其中定义了两种类型的掩码：RandMask 和 BurstMask，前者在随机丢包中爱护成果要好些；后者则是对突发导致间断丢包成果会好些，然而不管哪种，都有其毛病。

FEC 冗余度和原始包分组长度计算准则是：依据丢包和 rtt 预置分组长度，在该分组长度下，依据贝叶斯定律，在以后丢包率下，确定至多须要多少冗余包可能保障承受到足够的原始包和冗余包来通过 FEC 解码复原丢包。值得注意的是，分组长度对 FEC 的复原提早有决定作用。

RED 是在一个包中额定携带前序若干包的抗性策略。其冗余层数以最大包长度为限度，同时也受到消耗带宽的束缚。其劣势在于 RED 包携带的冗余数据与原始包序号越靠近，RED 复原时延越低；原始包与冗余包的最大序号差，决定了最大复原提早。

端侧 RED 打包常采纳间断相邻序号作为冗余数据，跳跃序号的打包形式未证实存在显著复原劣势，但会引入更大的均匀复原提早。

服务端上行侧 RED 打包受到上行弱网、抗性恢复能力、复原工夫影响。若采纳间断相邻序号作为打包形式，则须要期待上行丢包的复原包；若采纳跳跃序号的打包形式，则会引入更大的上行侧 RED 复原提早。提早取决于上行丢包复原的耗时。因而分段 RED 策略下，若上行存在弱网，那么服务端上行侧 RED 的复原工夫劣势就不再显著。此时优化上行链路弱网的复原工夫更为无效。

RTX 是弱网抗性算法中引入提早最重大的。一个包的重传申请到该重传包被胜利复原，至多要经验一个 rtt 耗时，在丢包重大、rtt 较大时，重传包也可能失落进而造成多次重传，这个耗时将变得不可承受。

重传耗时的次要决定因素是：rtt、丢包率、重传申请机会、重传申请响应策略。其中 rtt、丢包率可能因为链路带宽拥塞、弱网测试引起的，重传申请机会取决于申请距离束缚、以后数据缓存量、丢包检测机制等；重传申请响应策略取决于发送端缓存、发送端拦挡机制、预计带宽、是否有冗余重传机制等。综合思考以上因素，能够极大地优化重传成果（包含复原成果、复原耗时、重传码率）。

在网络飞速发展的明天，音频 QoS 的优化显得比视频更加容易，因为带宽的顾虑会越来越少。然而从企业经营角度思考，当 RTC 业务中的音频业务占据主导时，管制音频带宽的老本时十分有价值的。这是音频 QoS 优化中，间接和利润相干的局部。因而上述策略中，有许多都提到了带宽耗用，这意味着咱们不能一味谋求抗性和实时性，而疏忽了带宽老本的减少。

QoS 的终极课题就是在无限的带宽资源下，晋升弱网抗性，升高复原时延。在这条路上，还有十分多的空间等着 QoS 从业人员去摸索。

正文完