Saw a group of articles valuable analysis of QOS, specially reprinted over the original: https://blog.csdn.net/CrystalShaw/article/details/80432267 thank landlord
Currently summed up a webrtc for lifting QOS are:
NACK, FEC, SVC, JitterBuffer, IDR Request, PACER, Sender Side BWE, VFR (dynamic frame rate adjustment strategy).
These methods in webrtc architecture distributed as follows:
Specific implementation principle is as follows:
A, NACK
corresponding to NACK is ACK, ACK is arrival notification technology. TCP as an example, he was reliable because the receiver will return to the sender message (ACK) a "data has been received" after receiving the data, tell the sender "I have received", to ensure reliable message. NACK notification is also a technology, but the conditions that triggered the notification of ACK just the opposite, when the message is not received, notify the sender "I have not received the message," that is less than notification.
NACK is detected at the receiving end the packet loss, it transmits a NACK packet to the transmitting terminal; transmitting end according NACK packet sequence number, finds the corresponding data packet in the transmission buffer and re-transmitted to the receiving side. The sender sends the NACK needs to support buffer, RFC5104 defines the format of the NACK packet. If the receiver receives the transmitting side retransmits the packets in the buffer JB time, packet loss problems can be solved. RTCP RTPFB transmitting end corresponding to the FIG.
Refer to https://blog.csdn.net/CrystalShaw/article/details/81218394
Two, the FEC
the FEC sending end is sending a packet when the previous packet is also old packed inside a new packet, if the receiving terminal has packet loss, to recover the data packet with the new redundancy inside the old package.
webrtc achieve this redundancy, there are three ways:
1, RED is RFC2198 redundancy. The front of the packets directly to the new package into the inside, and the receiving side parses redundant packets in the main package.
2、ULPFEC，目前webrtc仅将SVC编码的Level 0视频帧打包成FEC。其余层有丢包，就逐步将帧率，保证视频相对流畅。用到的协议是：RFC5109。
3、FLEXFEC根据接收端反馈回来的丢包信息，总结一些规律，把预判丢失概率比较大的包，冗余打包出去。
三、SVC
webrtc的VPX用到的是时间可适性（Temporal Scalability）算法。通过改变一个GOP内帧的线性参考关系。防止网络丢包对视频传输造成的影响。
具体请参考：https://blog.csdn.net/crystalshaw/article/details/81184531
webrtc使用NACK+FEC+SVC作为QOS的解决方案。参考链接：https://ieeexplore.ieee.org/document/6738383/
四、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同一时刻生产的若干包，周期性的发送，防止上行流量激增导致拥塞。
七、Sender Side BWE或REMB（Receiver Estimated Maximum Bitrate）
这个算法的思路是根据接收端的丢包率或延时情况维护一个状态机。以根据丢包率为例，在判断为overuse时，就根据一定的系数减少当前发送端的码率值，当判断为underuse时又根据增加系数来增加发送端的码率值；然后将这个值通过rtcp包发送给发送端，发送端根据该值来动态的调整码率。
具体请参考https://blog.csdn.net/CrystalShaw/article/details/82981183介绍
八、动态帧率调整策略
视频发送端根据Sender Side BWE或REMB等参数调整出一组比较合适的码率值，当网络条件好的时候，码率值会比较大，当网络条件比较差的时候，码率值会比较低。但是若是发送端仅调整码率，不调整帧率，当网络条件比较好的时候，仅仅提升了视频质量，没有充分利用网络条件，提升实时性。当网络条件比较差的时候，码率降的比较低，若不降低帧率，视频质量会大幅度下降。所以需要增加一种机制，根据发送端的码率值，动态调整发送端的帧率值。
具体请参考https://blog.csdn.net/CrystalShaw/article/details/83340323