webrtc拥塞机制和带宽调节

参考：https://blog.csdn.net/yuanrxdu/article/details/80449740

webrtc的gcc是通过延迟和丢包进行动态调整的，发送端通过接收到接收端rtcp反馈过来的信息（包延迟增量，丢包率信息等）计算出网络拥塞状态并评估出适合当前网络传输的码率，从而进行码率控制。所以重点是接收端rtcp反馈信息，和发送端是如何根据不同信息进行评估。

首先分析一下rtcp的传输信息，通过modules>rtp_rtcp>source->rtcp_sender.cc文件可以看出有一些rtcp常规信息如sr，rr，sdes等，还有pli，fir，tmmbr，rembr等。pli(picture loss indication)，sli(slice loss indication)，fir(full intra request)，remb（recevier estimated max bitrate），tmmbr（temporal max media bitrate request）。pli，sli，fir都是请求数据帧，而不同之处在于pli和sli一般在丢包情况下，而fir则是在用户新进入时请求关键帧。remb为接收端预估的最大码率，temmbr为接收端临时的最大码率请求。

接收端根据接收的数据包进行误差统计：webrtc在评估延迟差的时候不是对每个包进行评估，而是采用包组间进行延迟评估，包组的含义就是距包组中第一个包的发送时刻t0小与5ms发送的所有包。通过获取的包组信息反馈给发送端。

发送端通过获取的包组延迟信息，通过滤波器趋势判断，过载检测最终评估出一个码率，发送端码率调节并没有完全按照aimd机制(加性增窗，乘性减窗)，webrtc增加码率：开始通话时，相当于tcp慢启动，以倍数增加(1.08)，当达到”拥塞避免“阶段时其增加的码率是一个rtt时间周期内所能传输的数据速率。减少码率：发送端500ms时间窗内的最大ack bitrate乘以0.85，其基本原理和tcp码率控制相识。发送端的pacer模块通过定时器实现定时数据发送，这就避免了瞬时对网络的冲击，让视频数据按照评估码率均匀的分布在各个时间片。而且发送端发送数据包也是根据不同策略进行发送，比如优先级，时间戳等(重发数据包比普通包更有优先级)，从而尽可能的保证延迟时间尽量减少。

发送端根据丢包进行码率控制如下：当丢包率在2%到10%维持当前码率，而当大于10%则按照丢包率进行码率设置。且丢包重传请求在video_coding>nack_modules.cc文件中，每个包的最大请求次数为10次，最大请求时间为10*rtt。

webrtc通过各个环节进行拥塞控制，从而实现码率的动态控制。