QOS : Quality Of Service, 顾名思义就是服务质量的意思.
以下内容参考自: blog.csdn.net/CrystalShaw…
webrtc有一系列的方案来提高服务质量: NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）、AVSync（音视频同步）、动态分辨率调整.
NACK
丢包重传, NACK就是接收端在检测到丢包后, 发送NACK报文到发送端, 告诉发送端 “我没有收到”.
发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端.
NACK需要发送端发送缓冲区的支持。若在jitterBuffer缓冲时间内接收端收到发送端重传的报文，就可以解决丢包问题.
FEC
以冗余包的方式向前纠错, FEC是发送端在发送报文的时候，将之前的旧包也打包到新包里面，若接收端有丢包，就用新包里面冗余的旧包恢复数据.
webrtc实现该冗余功能，有三种方式：
1、RED就是RFC2198冗余。将前面的报文直接打入到新包里面，在接收端解析主包和冗余包。
2、ULPFEC，目前webrtc仅将SVC编码的Level 0视频帧打包成FEC。其余层有丢包，就逐步降低帧率，保证视频相对流畅。用到的协议是：RFC5109。
3、FLEXFEC较ULPFEC，增加纵向OXR运算。增加网络抗丢包能力。
-
webrtc的opus音频使用的是inband FEC和交织编码
-
webrtc的视频ulpfec使用的是异或XOR
-
Reed Solomon算法比较复杂，理论上数据恢复能力比较强。
-
webrtc默认使能Red+Ulp的FEC。Flex仅在实验阶段，还不能正式使用
SVC
SVC（可适性视频编码或可分级视频编码）是传统H.264/MPEG-4 AVC编码的延伸，可提升更大的编码弹性，并具有时间可适性（Temporal Scalability）、空间可适性（Spatial Scalability）及质量可适性（SNR/Quality/Fidelity scalability）三大特性，使视频传输更能适应在异质的网络带宽。
SVC以AVC视频编解码器标准为基础，利用了AVC编解码器的各种高效算法工具，在编码产生的编码视频时间上（帧率）、空间上（分辨率）、视频质量方面的可扩展，产生不同帧速率、分辨率、质量等级的解码视频.
JitterBuffer
JitterBuffer实现原理是，在收到网络上的RTP报文后，不直接进行解码，需要缓存一定个数的RTP报文，按照时间戳或者seq的顺序进行重排，消除报文的乱序和抖动问题.JitterBuffer分动态JitterBuffer和静态JitterBuffer两种模式。静态JitterBuffer缓存报文个数固定。动态JitterBuffer是根据网络环路延时的情况，动态调整缓存报文个数.
IDR Request
关键帧也叫做即时刷新帧，简称IDR帧. 对视频来说，IDR帧的解码无需参考之前的帧，因此在丢包严重时可以通过发送关键帧请求进行画面的恢复。关键帧的请求方式分为三种：RTCP FIR反馈（Full intra frame request）、RTCP PLI 反馈（Picture Loss Indictor）或SIP Info消息，具体使用哪种可通过协商确定.
PACER
PACER，是网络报文平滑策略。一个视频帧有可能分别封装在几个RTP报文，若这个视频帧的RTP报文一起发送到网络上，必然会导致网络瞬间拥塞。以25fps为例，若这帧视频的RTP报文，能够在40ms之内发送给接收端，接收端既可以正常工作，也缓冲了网络拥塞的压力。PACER就是实现把RTP同一时刻生产的若干包，周期性的发送，防止上行流量激增导致拥塞.
BWE : REMB（Receiver Estimated Maximum Bitrate）
这个算法的思路是根据接收端的丢包率或延时情况维护一个状态机.以根据丢包率为例，在判断为overuse时，就根据一定的系数减少当前发送端的码率值，当判断为underuse时又根据增加系数来增加发送端的码率值；然后将这个值通过rtcp包发送给发送端，发送端根据该值来动态的调整码率.
目前REMB已被Transport-cc替代
BWE :Transport-cc
Transport-cc指的是Transport-wide Congestion Control。WebRTC最新的拥塞控制算法（Sendside BWE）基于Transport-cc，接收端记录数据包到达时间，构造相关RTCP包，然后反馈给发送端，在发送端做带宽估计，从而进行拥塞控制。之所以基于Transport-cc，放到发送端进行带宽估计，除了方便维护，也增加了相关算法的灵活性，因为大多数处理逻辑都放到了发送端。WebRTC中为了使用Transport-cc，需要用到RTP报头扩展以及增加新的RTCP类型.
RTP报头扩展详情参考: blog.jianchihu.net/webrtc-rese…
REMB、Transport- CC对比参考: www.dazhuanlan.com/chairse_xd/…
动态帧率调整策略
视频发送端根据Sender Side BWE或REMB等参数调整出一组比较合适的码率值，当网络条件好的时候，码率值会比较大，当网络条件比较差的时候，码率值会比较低。但是若是发送端仅调整码率，不调整帧率，当网络条件比较好的时候，仅仅提升了视频质量，没有充分利用网络条件，提升实时性。当网络条件比较差的时候，码率降的比较低，若不降低帧率，视频质量会大幅度下降.所以需要增加一种机制，根据发送端的码率值，动态调整发送端的帧率值.
AVSync音视频同步
由于音视频处理的系统路径不同，并且音视频媒体流是分开以RTP over UDP报文形式传输，UDP报文对网络丢包延时敏感，若不进行特殊平滑处理，会导致实际播放时音视频的渲染相对延时与采集延时有偏差，这样就容易产生音视频不同步现象.音视频同步的基本思想是，以RTCP报文的NTP时间为参考，在接收端渲染前，对音视频分别进行不同长度的适当缓冲，尽量保证音视频渲染different time = 音视频采集different time.保证音视频同步.
动态分辨率调整策略
动态分辨率调整策略设计思想是，在网络传输质量变差、CPU占有率过高，编码器编码质量QP值过大等情况下，动态降低视频传输分辨率，缓解当前异常。反之则动态增加分辨率，提供高质量的视频传输.
通过阅读void SendSideBandwidthEstimation::UpdateEstimate(Timestamp at_time)函数源码可以发现, 码率调整策略为:
- 丢包率低于2%时, 码率提升8%
- 丢包率在2% - 10%之间, 维持原码率,不做处理
- 丢包率高于10%时, 以1-(0.5*丢包率)为系数降低码率
