目前总结出webrtc用于提升QOS的方法有：

NACK、JitterBuffer、关键帧请求、FEC、PACER、REMB、动态帧率调整。也许还有其他，待后续知识更新后，补充。

这几种方法在webrtc架构分布如下：

具体实现原理如下：

一、NACK

NACK是在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端发送缓冲区的支持，RFC5104定义NACK数据包的格式。若在JB缓冲时间内接收端收到发送端重传的报文，就可以解决丢包问题。对应上图发送端的RTCP RTPFB

二、JitterBuffer

JitterBuffer实现原理是，在收到网络上的RTP报文后，不直接进行解码，需要缓存一定个数的RTP报文，按照时间戳或者seq的顺序进行重排，消除报文的乱序和抖动问题。JitterBuffer分动态JitterBuffer和静态JitterBuffer两种模式。静态JitterBuffer缓存报文个数固定。动态JitterBuffer是根据网络环路延时的情况，动态调整缓存报文个数。

三、关键帧请求

关键帧也叫做即时刷新帧，简称IDR帧。对视频来说，IDR帧的解码无需参考之前的帧，因此在丢包严重时可以通过发送关键帧请求进行画面的恢复。关键帧的请求方式分为三种：RTCP FIR反馈（Full intra frame request）、RTCP PLI 反馈（Picture Loss Indictor）或SIP Info消息，具体使用哪种可通过协商确定。

四、FEC

FEC是发送端在发送报文的时候，将之前的旧包也打包到新包里面，若接收端有丢包，就用新包里面冗余的旧包恢复数据。说到这里大家可能认为这就是RFC2198冗余。但是在webrtc里面，这不是简单的RFC2198冗余。RFC2198冗余带宽占有量是倍增，简单冗余，对网络差的情况是恶化。

FEC可以有很多种算法实现，大概思路是根据接收端反馈回来的丢包信息，总结一些规律，把预判丢失概率比较大的包，冗余打包出去。用到的协议是：RFC5109

五、PACER

PACER，是网络报文平滑策略。一个视频帧有可能分别封装在几个RTP报文，若这个视频帧的RTP报文一起发送到网络上，必然会因为网络拥塞。以25fps为例，若这帧视频的RTP报文，能够在40ms之内发送给接收端，接收端既可以正常工作，也缓冲了网络拥塞的压力。PACER就是实现把RTP同一时刻生产的若干包，周期性的发送，防止上行流量激增导致拥塞。

六、REMB（Receiver Estimated Maximum Bitrate）

这个算法的思路是在接收端根据丢包率或延时情况维护一个状态机。以根据丢包率为例，在判断为overuse时，就根据一定的系数减少当前remb值，当判断为underuse时又根据增加系数来增加remb值；然后将这个值通过rtcp包发送给发送端，发送端根据该值来动态的调整码率。

七、动态帧率调整策略

视频发送端根据REMB等参数调整出一组比较合适的码率值，当网络条件好的时候，码率值会比较大，当网络条件比较差的时候，码率值会比较低。但是若是发送端仅调整码率，不调整帧率，当网络条件比较好的时候，仅仅提升了视频质量，没有充分利用网络条件，提升实时性。当网络条件比较差的时候，码率降的比较低，若不降低帧率，视频质量会大幅度下降。所以这里需要一种算法，根据发送端的码率值，动态调整发送端的帧率值。

这个过程在webrtc\modules\video_coding\utility\frame_dropper.cc通过漏桶算法实现。

这五种方法实现的细节，待续。。。。。