背景介绍

实时音视频通话在以后的生存中是无时不刻存在的，包含社交、安防、交通等等各个方面都须要。用户场景复杂多变、要求严苛、网络环境不统一等给实时音视频通话带来很大条件。咱们在这方向略微做了一些工作，尽管和其余大厂的优化工作相比，咱们还处于劣势，还有很多能够优化和改良的，然而目前的一些停顿和工作内容和大家分享一下。

0.1 网络传输：

咱们晓得网络传输目前有 TCP 和 UDP 两种，相干优缺点如下脑图；而影响网络传输品质也有很多起因：包含网络拥塞、网络丢包等等。这些因素间接决定以后实时视频通话的品质，也会给用户带来很大的体验影响。这也是咱们为什么要进行优化的根本起因了。

0.2 弱网定义：

对于实时音视频通话来说：网络的复杂性、异构性、协定局部不规范性、网络异样，网络谬误等各种网络环境被毁坏的个性都称之为弱网。弱网环境无奈提供高质量的网络传输，对于接收端就是无奈收到间断的媒体包，造成声音异样、视频马赛克、花屏、黑屏等景象，对于音视频实时通话来说是十分致命的，间接影响到用户的体验，造成产品质量问题或者客诉问题。

0.3 实时音视频特点

对于实时音视频通话来说要求最高的条件低提早和高质量，这一对个性的存在就是天生的矛盾结合体。高质量就要求发送端尽可能发送高分辨率，高质量的音视频流，对于带宽和网络环境要求比拟高，不容许有各种丢包、高抖动的景象存在；而低提早则对于网络环境没有那么严苛，是容许存在肯定丢包量、容许肯定范畴内的接管抖动的，否则只能用空间换工夫，导致音视频实时性时效，无奈达到低提早的要求。所以这是一对矛与盾的故事。只能在矛上寻求冲破，在盾上给予爱护，能力满足这样刻薄的条件。

一 FEC

webrtc FEC 的实现形式有三种：RED（rfc2198）、ULPFEC（rfc5109）、FLEXFEC(还未通过)。然而 Ulpfec 是套用了 RED 的壳进行传输的，所以咱们采纳的是 ULPFEC 进行 FEC 爱护。

其基本原理是：在发送端，针对媒体包减少肯定冗余 FEC 包，FEC 包是通过异或 XOR 失去的。如果在网络传输过程中丢掉了一部分媒体包，则在接收端通过接管到的媒体包和 FEC 包进行异或 XOR 失去失落的媒体包，这样就不必发送 NACK 重发包占用网络资源了。

因为这部分在 WebRTC 中曾经实现的比拟好，只须要进行兼容性测试即可，这部分没有作为重点优化对象，沿用 WebRTC 中内容即可。

二 NACK

2.1 NACK 介绍：

NACK 代表否定确认。它是 WebRTC 中的谬误复原机制之一。NACK 是接收端表明它没有收到特定数据包的一种形式。

NACK 音讯通过 RTCP 发送给媒体的发送方，后者须要依据其在缓存中的可用性以及对重传有用性的预计（是否能够应用）来决定是否重传失落的数据包 它已经收到。发送端保护一个缓冲队列，如果重发包在缓冲队列中则从缓冲队列中取出再次发送；如果没有在缓冲队列中，则不再发送，这样解码端就无奈收到重发包了。

2.2 优化和改良：

因为以后零碎中采纳的依然是旧版本中的 NACK 流程，具体流程如下：

• RTP 模块解封包后，将数据包依照达到程序顺次传送到 JitterBuffer 模块中；
• 每个数据包在插入 JitterBuffer 模块时都须要进行序列号的比拟和排序，如果序列号比拟新的数据包，则进行 NACK 构建，以上次保留的序列号 +1 为起始值，以新收到的序列号为完结，将之间的序列号先缓存到 missing_sequence_numbers 中；
• WebRTC 在 JitterBuffer 中采纳线程查问的形式，每个肯定工夫进行一次遍历，确认以后 nack List 中是否存在以后工夫节点没有依照程序收到的数据包，如果存在就会组装并发送 NACK RTCP 包到发送端，申请发送对应的为接管到的数据包。

NACK 是一个未达到数据包的确认过程，原先流程中有很多嵌套性能，或者流程简单的中央，因而咱们再了解的根底上做了两次优化，其两轮优化的大略流程图如下：

还有一个 NACK 无奈回避的问题时：如果网络丢包率比拟高，或者网络抖动，网络异构导致网络各种乱序达到状况比较严重，比方抖动超过 200ms 时，某些失落的数据包迟迟不达到，则该包会反复发送屡次，这样会导致网络拥塞的景象，特地是分辨率比拟高时，极容易造成视频帧无奈残缺解码，呈现马赛克或者黑屏景象。

因而咱们再次根底上减少和批改了一些判断条件，进行缓存队列和清空队列判断条件优化，以及获取残缺视频帧流程局部调整和优化，尽量减缓以上状况的影响，晋升用户体验。

三 带宽自适应

3.1 带宽自适应：

咱们在进行视频实时通话时，在设施端依照不同的帧率采集数据设置的参数，这样发送端就保护一个最大帧率参数集。之后采集的图像进行编码，分包发送到网络中。然而如果网络产生了变动，依然依照以后的码率逐帧发送到上行网络时，亦或者采集端编码性能不稳固无奈耗费采集的图像帧序列，发送端将采取降帧率或者丢帧的形式缓解发送端的发送压力。

在 WebRTC 中当编码后的传输码率过载或负载不均时，通过调用 MediaOptimization 类相干接口升高或升高帧率进而减小或者升高码率，从而无效利用以后带宽，防止网络更差，或者网络带宽负载不够，影响用户体验。

3.2 框架图

发送端：基于丢包率估算以后可用带宽

承受端：基于包达到工夫计算可用带宽

综合：接收端发送 REMB 反馈给发送端，而后基于发送端的带宽估算和接收端的带宽估算决定最终的发送速率。

3.3 发送端

发送端的带宽预计算法基本原理：是读取 RTCP 中的丢包率信息，进而通过算法来动静计算以后网络中根本状况，并判断是否减少或缩小带宽资源。如果判断须要缩小带宽时，则采纳 TFRC 算法来平滑解决，削弱忽然减少或者缩小的危险。

3.4 接收端

接收端的带宽预计算法基本原理：读取收到 RTP 数据统计进而估算以后网络带宽；WebRTC 中采纳卡尔曼滤波帧对以后帧的接管工夫戳和发送工夫戳实现根本统计和计算，从而估算以后网络带宽拥塞状况和利用率，评估和修改带宽大小，进而影响网络带宽。

四 优化和改良：

4.1 优化和改良

咱们做的工作次要的优化点如下：

NACK 两轮优化 ：包含之前版本算法的整体晋升（重构原来 R4X 相干代码，采纳和 iOS 雷同的 NACK 获取算法，并在此基础上进行缓存队列和清空判断条件调整优化、获取残缺解码帧相干流程优化、长时间缓存帧抛弃策略调整等计划）、Jitterbuffer 参数的优化调整；

FEC、动静分辨率、NACK 整体策略优化 ：针对不同的网络条件，根据丢包率、RTT 等相干参数，以及 5s 内的抖动平均值等，设计一套动静调整以后组合的整体计划，既减少肯定冗余避免 FEC 高丢包时时效景象，也能够在高丢包时逐渐升高分辨率达到晦涩播放的体验。

网络风暴克制优化 ：WebRTC 中有重发包的网络克制策略，重发包占比为 35% 时候不再发送 NACK 重发包和 FEC 冗余包，然而这个占比对于 720P、30% 以上丢包时十分不敌对，因而大量理论验证测试，重发包和 FEC 冗余包占比为 30% 时，可能正当躲避网络风暴景象，同时满足 NACK 申请重发的策略，达到 720P、30% 丢包依然能够获取 15~25 帧率，实现晦涩播放。

4.2 优化后果

整体计划进行了局部实验室场景的测试和验收：包含 IP 和 SIP 通话，720P 和 VGA 分辨率验证，相比之前的版本，在肯定水平上进步的用户体验。特地是有线网络条件下 IP 直播时晋升显著，总体主观的分有了显著晋升。同时反抗提早也从无到有，可能笼罩 300ms 一下环境。该计划失去用到理论环境中，失去用户认可，并在和竞争对手 PK 过程中，全面当先。

五 问题和措施：

5.1 拥塞检测：

须要更加疾速精确定位到以后网络状态，一旦呈现拥塞能够疾速调整以后发送策略。曾经有视频专项开始预研。

5.2 最新 WebRTC 中弱网管制

WebRTC 中 NACK 模块作为独立的 module 集成到 VIE 模块中，和 Jitterbuffer 模块解耦，实现实时监控网络丢包，并独立发送。

长处：能够实时获取到 NACK 列表；和 JitterBuffer 解耦，获取更便捷、更迅速。曾经有视频专项开始预研。

5.3 弱网前沿

2020-10-24 加入声网 RTE2020 互联网实时互联网大会，声网曾经实现 720P 2.0M 带宽下 65% 的丢包，晦涩播放了。

1. 深度强化算法那在拥塞管制中的利用；

2. 实时 H264 视频编码器算法的深度优化。

这些是咱们之后要去调研学习的中央，也期待有相干教训的童鞋能够一起探讨学习。