关于视频:实时音频抗弱网技术揭秘

本文由百度智能云 - 视频云技术架构师——柯于刚 在百度开发者沙龙线上分享的演讲内容整顿而成。内容从抗弱网技术意义登程，梳理抗弱网的概念与办法，联合百度 RTC 抗弱网过程中遇到的问题，重点分享抗弱网技术优化的摸索与实际。心愿本次分享可能让开发者反抗弱网技术有一个全面的意识并把握肯定的 webRTC 优化办法

文 / 柯于刚
整顿 / 百度开发者核心
视频回放：https://developer.baidu.com/l…

本次分享的主题是：实时音频抗弱网技术揭秘，内容次要分为以下三个方面：

1. RTC 抗弱网技术的意义
2. RTC 抗弱网技术解析

3. 百度 RTC 抗弱网实际与摸索

   1. 抗弱网技术的意义

   
   在开发过程中，直播、点播 CDN 等云服务往往会通过从「能用」、「好用」到「大规模应用」等阶段。
   相似地，RTC 正处于从「能用」走向「好用」的过程中。咱们须要晋升用户的视频参观体验，实现标准化的服务，而抗弱网技术是一个关键性的步骤。
   另一方面，不同于 RTMP、RTSP 等「尽力而为」的网络协议，它们只解决网络问题；RTC 是一个面向视频交付的协定，联动传输和编解码，造成牢靠的视频交付。因而，抗弱网技术是实现全场景交付的撑持性技术。

   2.RTC 抗弱网技术解析

   2.1 抗弱网波及的环节和罕用伎俩

   2.1.1 抗弱网波及的环节

   
   最典型的 RTC 系统结构通常包含两个局部：平台侧和终端。
   而平台侧通常又分以下两局部：

4. 用户端接入，包含信令和媒体。

5. 服务间流的直达和管制，包含媒体散发、调度。

   2.1.2 RTC 抗弱网的技术手段

   
   抗弱网的技术手段能够演绎为 2 个层面，蕴含 4 个办法。
   「2 个层面」即网络层面和音视频层面。
   「4 个办法」包含：
   （1）自适应办法。自适应地对网络的带宽进行评估、正当应用带宽，并依据带宽自适应地调整码率。
   （2）纠错办法。针对丢包、丢帧等状况，通过前向纠错，在网络数据包、视频、音频层面上进行纠错。
   （3）缓存办法。针对网络抖动、设施不稳固、设施性能无限等问题，设置视频、音频的缓存区。
   （4）调度办法。尽可能地将用户调度到最好的接入点，或在服务器侧进行直达，实现最优的内容散发调度，从而解决低延时和稳定性问题。

2.2 WebRTC 抗弱网技术简介

WebRTC 提供了蕴含一系列组件的低延时框架，次要环节包含：编码、发送、接管和解码。
绝大部分自研零碎的架构也与此相似，但会在具体实现过程中对算法做相应的调整。
编码环节：就发送方而言，咱们须要依据其网络状况自适应地采纳适合的码率；就接管方而言，咱们会通过 Simulcast、SVC 等编码伎俩依据网络状况自适应地抉择接管办法。此外，咱们还能够通过动静 Gop 依据场景控制传输压力。
发送环节：首先进行带宽预计和调配。如果产生了数据谬误，咱们会进行 RTX 重传，或采取 FEC 等伎俩。此外，咱们还能够采纳 PACING 实现网络的平滑发送，并确定数据带宽应用和发送的优先级。
承受环节：须要与发送方就带宽的预计、重传等操作进行配合。咱们能够通过 NACK 申请发送方从新发送数据包，或者通过 RTCP 的反馈批示接管方理论的承受状况，也能够通过动静视频、音频缓存适应网络的抖动。
解码环节：须要解决谬误暗藏问题，在数据出错之后尽可能晋升用户体验。此外，咱们还须要针对不平衡、不稳固的网络实现稳固的继续输入。
之前的流媒体协定次要作用在网络层面，没有实现网络和编解码环节的联动，而 WebRTC 能够大大晋升对弱网的适应性。

2.3 抗弱网技术总览

进一步演绎，抗弱网技术次要须要解决丢包、延时、乱序抖动、限速、网络品质渐变等状况。咱们会在带宽评估、带宽调配、带宽应用、缓存、解码渲染等环节上解决上述问题。
在进行带宽预计时，咱们能够采纳基于丢包、基于时延、基于 ACK 带宽的办法，也能够通透与探测实现带宽预计；
在进行带宽调配时，咱们能够通过网络状况动静地调配视频、音频的编码码率，实现 FEC 前向纠错和互相纠错重传的带宽预调配。
在带宽应用方面，对于纠错后调配的带宽，咱们须要通过 Nack、Sack、FEC 等数据重传，或通过 Pacing 等技术确定数据的优先级，晋升发送的均衡性；
就缓存技术而言，WebRTC 中提供了面向视频的 JitterBuff 和面向音频的 NetEQ，从而适应网络的抖动、修补数据的完好、将网络数据包转换成音频帧或视频帧。

2.4 关键技术解析

2.4.1 带宽评估——TCC 根本了解

TCC 是一种带宽评估技术，其输出为接管情况的反馈，该数据会输出给带宽预计的三个控制点：丢包预计、延时预计、确认带宽预计。
丢包预计：依据丢包率的大小，在上次评估的带宽根底上，判断是减少带宽还是升高带宽。
延时预计：采纳 Aimd 调节实现「和」式的带宽减少，以及乘法级的带宽升高。具体实现形式：别离计算再发送端和接收端，间断两个包之间的差值之差，拟合线性回归函数，依据斜率断定网络是拥塞、轻载、稳固，再确定如何调节带宽，带宽基值依赖于接受方反馈带宽估值，调节形式按照和增乘减形式。
确认带宽预计：基于 FeedBack 接管统计丢包率，采纳贝叶斯评估接管方到码率，该值作为延时预计的带宽基值。
咱们对丢包预计得出的带宽值和由 Aimd 解决后的时延预计后果取最小值，从而失去最终的带宽评估后果。值得一提的是，确认带宽预计提供带宽须要调节的基准值，而丢包预计和时延预计则提供调节动向。

2.4.2 TCC 的优缺点

TCC 技术的设计长处包含：

1. 采纳「丢包 + 延时」网络拥塞检测办法，实现了边界性的爱护。
2. 面向视频利用，思考未充沛应用的带宽、利用已确认的带宽，并探测预计出的带宽是否无效。
   TCC 技术的不足之处在于：
3. 所有预计强烈依赖反馈，接收端会影响发送端。
4. 发送方的丢包、延时拥塞预计都基于统计实现，反映灵敏度低。

5. 未笼罩高抖动等场景。

   2.4.3 带宽调配

   
   带宽调配最典型的利用场景是对视频和音频的带宽调配。就音频而言，其带宽次要蕴含音频的原始码率以及为重传、纠错预留的带宽。大部分的带宽将调配给视频，视频的带宽分为三局部：
   （1）视频原始码率（2）前向纠错的 FEC 带宽（3）视频的 Nack 所须要的带宽。
   须要指出的是，Nack 的带宽不是预调配失去的，而是依据之前的网络状况统计得出。在具体实现中，咱们会采取一些保护措施，
   例如：要求视频 FEC 的码率加上理论重传的码率小于等于最终调配给视频的带宽的一半。在这种设置下，WebRTC 的抗丢包率约为 20-30%，咱们能够依据理论的丢包、延时状况扭转 nack+fec 的带宽分配比例，从而晋升抗丢包率。

2.4.4 带宽应用——NACK+ 重传

带宽应用次要波及重传和 FEC 两个场景。就重传而言，如上图所示，发送端的 host1 丢掉了 101、102 两个包。
接管方发现丢包的机会可能有两个：
（1）在接管 103 号包时，基于包序规定发现丢掉了前两个包，因而从新对发送方申请发送 101 和 102 号包。
（2）如果从新申请后通过了 RTT+ 退却期的工夫依然没有收到这两个包，则会通过基于超时的形式重传包，防止了
NACK 的风暴。
发送方收到 NACK 的申请之后，也会采取肯定的措施进行管制。如：同一个 RTP 包，在两次重传间会隔 1 倍的 RTT，通过这种形式能够爱护因屡次发送导致的带宽占用。

2.4.5 带宽应用——前向纠错 FEC

前向纠错 FEC 技术经验了从 UlpFEC 到 FlexFEC 的倒退。UlpFEC 是一种基于行式的生成形式，如果间断丢掉了两个包就很难复原。为此，FlexFEC 采取了行列交错的形式，即便间断丢包也有可能复原，然而会引入额定的计算开销，计算开销与复原率成正比。FEC 在稳固环境（例如，丢包率成正态分布）中较为容易复原，然而在事实网络中的成果会有肯定的升高。
在启用 FEC 时，咱们要进行发送端和接收端的 SDP 协商，并依据以后网络带宽情况抉择是否开启。就 FEC 的参数而言，咱们须要设定帧内的 FEC，确定每个 FEC 包由多少数据包生成、行列矩阵的组成，以及带宽的应用状况。目前，WebRTC 依据 FEC 通过异或计算生成 FEC 包，记录包的依赖关系，并依据它复原出失落的原始 RTP 包。

2.4.6 视频缓存与解码——JitterBuff 根本了解

JitterBuff 的输出为网络的 RTP 包，输入为一个视频帧，它实现了以下性能：
（1）一套动静缓存机制，解决丢包、超时、乱序、提早、帧完好等异常情况。
（2）一套将 RTP 包解码成帧的管制机制，确定还原帧的机会、参考关系，以及依据 RTP 包还原完好帧的办法。
（3）计算网络抖动延时，通过卡尔曼滤波，预测包达到的工夫，实现出帧的平滑性。

2.7 音视频缓存与解码——NetEQ 根本了解

NetEQ 被用于实现音频的动静缓存，通过计算网络抖动，实现 RTP 包的缓存、去重、排序、纠错等性能。
NetEQ 采纳直方图估算安稳抖动，通过峰值检测应答突发变动状况。当缓存中数据有余时，升高出帧的频率；当缓存中数据过多时，晋升出帧频率，从而实现平均出帧。对于空帧，NetEQ 会依据前帧和后帧拟合出弥补帧。日前，Opus 编码格局下开启 DTX 的帧内 FEC 后，抗弱网的能力会大大晋升。

3. 百度 RTC 抗弱网实际与摸索

3.1 百度 RTC 抗弱网总览

RTC 是一种低延时的通信技术，也能够被用于低延时直播等场景，更好的实现对弱网的适应性。
RTC 抗弱网技术次要被利用于 1 对 1、N对N，以及流场景下。咱们不仅须要思考如何应答媒体环境下的抗弱网问题，还须要从接入、调度、用户体验的角度思考如何抗弱网。

3.2 媒体抗弱网实际

就媒体抗弱网而言，
在带宽预计阶段，咱们首先要判断丢包的类型，确定对带宽的调整计划，晋升抗乱序抖动成果、晋升对网络变动感知的灵敏度。
在带宽调配阶段，咱们以清晰和晦涩为指标导向，依据对丢包率、延时、抖动的统计状况，预测复原成果，动静调整 ARQ、FEC，以及编码带宽比。
在带宽应用阶段，咱们须要精密地思考重传机制，优化接管方发动重传的机会和发送方发送数据包的机会，从而防止重传风暴，保障重传的有效性。在重传 Nack 申请失落时，咱们须要及早发现并尽可能疾速复原。此外，咱们还须要重点优化音频的间断丢包问题、采纳 Pacing Sender 优化，也会联合解码环节采纳多码流的 Simulcast 和 SVC 技术。
在缓存 \ 解码 \ 渲染阶段，咱们对视频、音频 Jitter 进行了优化，从而适应抖动、乱序等场景。值得注意的是，目前的 WebRTC
协定是端到端的，然而目前许多商业系统并不是端到端的零碎，它们只思考了服务器端的优化，而咱们还须要思考发送端的抖动状况。

3.3 其它技术实际

3.3.1 带宽预计 TCC 优化——加强丢包抗性

为了加强对丢包的抗性，咱们将丢包的状况分为拥塞丢包、非拥塞丢包和偶发丢包。
非拥塞丢包场景下，个体的避让对整体信号品质的影响无限，为了保障视频的晦涩，咱们不能升高带宽，须要发送更多的数据包，将带宽调配给纠错局部。目前，咱们还很难解决拥塞丢包问题。偶发丢包问题可能是非继续的网络信号抖动，无需通过升高带宽来优化。

3.3.2 带宽预计 TCC 优化——加强乱序抖动抗性

带宽预计对乱序抖动的适应性较差。为此，咱们须要防止将乱序误判为丢包。在存在肯定丢包的状况下，也应该思考对乱序和延时的预计，晋升对弱网的适应性。

3.3.3 带宽预计 TCC 优化——晋升拥塞灵敏度

在带宽预计过程中，默认的实现以预先统计数据为根底。为了晋升探测拥塞的灵敏度，咱们能够通过在发送端减少 TCP 拥塞窗口，动静地调配窗口，能够很灵活地感知到发送方上行带宽呈现的拥塞。

3.3.4 百度在媒体抗弱网的优化计划

弱网中可能会呈现丢包、延时、抖动、乱序以及一些突发状况，每个因素可能会影响到上行、上行信号，而不同的管制机制会波及推流和拉流方。因而，抗弱网场景十分复杂。
如上图所示，咱们会提取一些要害门路上的组合点，并且在每一步中对算法进行调整优化。接着，咱们会从新在上述场景下检测优化后的算法，并且在线上进行 A/B 验证，逐步失去现实的算法。

3.3.5 Wifi+4G 同传，抗弱网另辟蹊径的办法

现在，手机 / 电脑等终端往往能够同时应用 4G 和 WiFi 信号。咱们会继续检测 4G 和 WiFi 的网络品质，在 WiFi 信号较差时及时应用 4G 信号作为弥补，强化音频传输，保障音频数据的连续性。

3.3.6 散发与调度——虚构低提早散发网

在散发与调度环节中，咱们试图失去服务器之间的最优散发门路，一直检测部署的云节点、公网的边缘节点之间的连通性，挑选出较优的连贯，造成虚构的低延时直达网络。
在下次应用时，咱们优先应用当时挑选出的虚构直达网络。为了升高服务器网络稳定对实时通信后果的影响，咱们在散发时会建设多条冗余备路，随时主动切换，并采纳重传、纠错等伎俩防止散发不稳固的问题。

以上是老师的全副分享内容，有问题欢送在评论区提出。

点击进入取得更多技术信息~~