WebRTC Qos策略

1.WebRTC 用于提升 QoS 的方法：

---

NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）

https://blog.csdn.net/CrystalShaw/article/details/80432267

丢包重传

NACK：一种通知技术，和ACK相反，通知未达

FMT=1, PT=RTPFB

a=rtcp-fb:96 nack

RTX：参考rfc4588，使用额外的 ssrc 传输，在sdp中标识

a=rtpmap:97rtx/90000

a=ssrc-group:FID2736695910239189782

RPSI：无

NACK 可以节省带宽，但会带来延迟*

谈谈网络通信中的ACK,NACK 和 REX](https://link.zhihu.com/?target=https%3A//blog.51cto.com/ticktick/2468581)

丢包恢复（冗余编码 前向纠错 FEC）**通过 FEC 协议实现：RED：RFC2198， 封装FEC冗余报文UlpFEC： RFC5109，报文异或，生成冗余打包；带宽占用大，连续丢包，随机丢包FLEXFEC： 草案， 更灵活，引入交织算法，增加纵向OXR运算，增加网络抗丢包能力。

a=rtpmap:116 red/90000a=rtpmap:117 ulpfec/90000

FEC由于通过冗余纠错，所以延迟比较低，但浪费带宽*

https://blog.csdn.net/CrystalShaw/article/details/83413772

根据丢包率动态调整冗余度。

关键帧请求（IDR）**严重丢包时可以通过发送关键帧请求进行画面恢复。关键帧请求方式包括三种：RTCP FIR：使用 RTCP Feedback 消息请求关键帧（完整帧）RTCP PLI：关键帧丢包重传SIP Info：

a=rtcp-fb:100 ccm fira=rtcp-fb:96 nack pli

Jitter Buffer 抖动缓冲区将收到的RTP报文缓存起来，按照时间戳或者序号重排，消除报文乱序和抖动问题。

分为静态和动态，动态 Jitter Buffer 根据网络环路延时情况，动态调整缓存大小。

Jitter buffer 核心思想是用时间换空间，以增大端到端延时为代价，换取视频通话的流畅性。 当网络抖动发生时，增加Buffer长度，以应对可能发生的抖动；当网络稳定时，减少buffer长度，降低视频端到端延迟，提高实时性。（尽量保证视频不卡的前提下，降低端到端延迟，在延迟和卡顿率之间平衡）

流程**：组帧--帧排序--检查帧参考关系--计算抖动（时间戳）--根据抖动计算buffer长度--根据抖动自适应调整buffer长度

Pacer 网络报文平滑策略**视频帧可能分别封装在多个RTP报文，若这个视频帧RTP报文同时发送到网络，必然会导致网络瞬间拥塞。PACER 就是实现把RTP同一时刻产生的若干包，周期性的发送，防止上行流量激增导致拥塞。让视频数据按照评估码率均匀的分布在各个时间片里发送。

削峰填谷； 将报文平滑地发送给接收端。在弱网环境尤其重要。

根据 estimator 计算的码率，来计算发包频率

WebRTC中pacer的流程比较清晰，分为三步：1）如果一帧图像被编码和RTP切分打包后，先会将RTP报文存在待发送的队列中，并将报文元数据(packet id, size, timestamp, 重传标示)送到pacer queue进行排队等待发送，插入队列的元数据会进行优先级排序。2）pacer timer会触发一个定时任务事件来计算budget，budget会算出当前时间片网络可以发送多少数据，然后从pacer queue当中取出报文元数据进行网络发送。3）如果pacer queue没有更多待发送的报文，但budget却还可以发送更多的数据，这个时候pacer会进行padding报文补充。

设置发送速率 PacedSender::SetEstimatedBitrate(bitrate_bps)*

包缓存队列；发包线程按一定间隔发包。

带宽评估和拥塞控制

https://mp.weixin.qq.com/s/Ej63-FTe5-2pkxyXoXBUTw

https://blog.csdn.net/CrystalShaw/article/details/82981183

https://blog.mozilla.org/webrtc/what-is-rmcat-congestion-control/

WebRTC 的拥塞控制和码率估计采用 GCC 算法。该算法充分考虑了网络丢包和网络延迟对码率估计的不同影响，分别基于丢包率和网络延迟进行码率估计，最后综合得出最优值。

算法实现上，基于丢包率的码率估计在发送端进行，基于网络延迟的码率估计在接收端进行。最后，在发送端计算出最优值，作用于Codec和PacedSender模块。GCC算法能够较好地基于网络实时状况估计网络带宽，为网络实时通信打下坚实基础。

GCC算法弊端：不能适应所有网络模型、应对网络峰值能力差。比如实时在线编辑场景。

M55 版本引进 Sendside-BWE 拥塞控制算法，把所有码率计算都移到发送端进行，并采用全新的 Trendline 滤波器取代之前的 Kalman 滤波器。能够更好更快的进行码率估计和网络过载恢复。

a=rtcp-fb:100 goog-remba=rtcp-fb:100 transport-cc

GCC 算法（Google Congestion Control）

https://www.jianshu.com/p/0f7ee0e0b3be

https://www.jianshu.com/p/5259a8659112

GCC拥塞控制算法主要分两部分：基于丢包检测的拥塞控制和 基于延时检测的拥塞控制。

其中，发送端基于丢包率的码率控制，接收端基于延迟的码率控制。

基于延迟检测和丢包反馈的拥塞机制（GCC）和带宽调节策略来保证延迟、质量和网路速度之间平衡

带宽估计，传输反馈机制

基于丢包率（loss-based ）（发送端实现）发送端从接收端发送的 RTCP RR(Receiver Report）报文，根据 Report Block 中携带的丢包率信息，动态调整发送端码率。

通过丢包率信息以及计算RTT，并结合 TMMBR 或 REME 中携带的码率信息计算最终的码率值，然后媒体引擎根据码率配置编码器，实现码率自适应调整。

RTCP RR 反馈包，显示接收端丢包率，lost fraction 字段

基于延时带宽估计（delay-based） （接收端实现）

记录数据包时间戳，计算数据分组的延时变化，判断网络拥塞情况；最终评估码率，由 RTCP feedback（TMMBR 或 REME ）报文 反馈给发送端。

WebRTC 新版本中，GCC算法将两种拥塞控制算法都在发送端实现。

基于延时的拥塞控制由三个模块组成：到达时间滤波器、过载检查器和速率控制器。

使用 Kalman filter（卡夫曼过滤器）带宽评估模型；WebRTC M55 新版本都是采用发送端的 trendline 滤波器来做延迟带宽评估。

TMMBR

REME （Receiver Estimated Maximum Bitrate）

rtcp remb 消息反馈

Sendside-BWE 算法（Transport-CC Feedback）

M55 版本引进 Sendside-BWE 拥塞控制算法，把所有码率计算都移到发送端进行，并采用全新的 Trendline 滤波器取代之前的 Kalman 滤波器。能够更好更快的进行码率估计和网络过载恢复。

RTP头部扩展 TransportSequenceNumber ，代表传输序号（不同于媒体层序号，用于组帧和抗丢包），关注数据传输特性，用于码率估计。

接收端，通过检查头部是否有 TransportSequenceNumber 扩展，决定采用 Sendside-BWE 还是 GCC 算法。接收端的 EstimatorProxy 周期发送 Transport-CC 报文。

包括关键技术：包组延迟评估（InterArrival）、滤波器趋势判断（TrendlineEstimator）、过载检测（OveruseDetector）和码率调节（AimdRateControl）。

BBR 算法

BBR在实时视频领域应用

Google's BBR 拥塞控制算法模型解析

从TCP拥塞本质看BBR算法及其收敛性(附CUBIC的改进/NCL机制)

2.总结

---

3.音频QoS

---

以上部分，我们主要讨论 RTP 视频相关 Qos。这里，我们着重讨论音频相关Qos。

时延是语音通话的重要指标，时延低于150ms时人感觉不到，超过150ms且小于450ms时人能感受但不影响通话，当时延大于1s时将严重影响通话交流。

音频的时延包括：通信终端时延（采集、前处理、编码）、网络时延、通信终端与网络设备间时延。

发送端延时：采集延时、前处理算法延时、编码延时

网络延时：Jitter Buffer、FEC

接收端延时：网络延时、解码延时、后处理算法延时和播放延时。

减少延时方法：减少缓冲深度、加速信号处理算法（WSOLA、NetEQ）

WebRTC 音频相关两大核心技术：前后处理（3A，AEC/AGC/ANS）、netEQ。

此处主要介绍 netEQ 算法，3A算法在音频处理详细介绍。

netEQ

在 NetEQ 模块中，主要分为：MCU（微控制单元）和 DSP（数字信号处理）模块。

MCU：主要负责延时及抖动计算统计，并生成对应的控制命令；

DSP：主要负责接收并根据MCU控制命令进行对应的数据包处理。

浅谈WebRTC NetEQ

webrtc音频Qos汇总

抗丢包方法：NACK、FEC、交织编码

抗抖动方法：Jitter Buffer、音频平滑处理

4.Jitter Buffer

---

抗网络抖动由三个模块完成：网络延时统计算法、缓冲区延迟统计算法、控制命令决策判定。

webrtc 会根据网络延时（DelayManager）和缓冲区数据长度（Buffer Level Filter）以及上一帧的处理方式，决定给解码器发什么信号处理命令。

5.音频平滑处理方法

---

音频解码信号处理命令主要有五种：kNormal（正常播放）、kAccelerate（加速播放）、kExpand（减速播放）、kAlternativePlc（丢包补偿）、kMerge（融合）。

抗抖动方法尽量保证音频质量，但特定网络，音频渲染会出现音频数据堆积、断流现象。若不进行特殊处理，音频会时快时慢；所以引入音频不变调算法进行平滑处理。

在弱网丢包率比较高情况下，数据会长时间丢失，变速不变调算法也无法满足实际应用，webrtc又引入了丢包补偿、音频融合算法，衔接和平滑音频质量。

丢包补偿：根据前一帧的解码信息，利用基音同步重复的方法近似替代当前的丢失帧，以达到丢包补偿。

融合算法：当上一次播放的帧和当前解码的帧不连续的情况下，进行衔接和平滑处理。让两个数据包一部分播放时间重叠，使过度更自然。

原文 https://zhuanlan.zhihu.com/p/149675376

★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。

见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓