一些webrtc gcc相关

1. 
Google Congestion Control（就是WebRTC中用的）
WebRTC通控制发送端数据发送码率来达到控制网络拥塞。
draft-ietf-rmcat-gcc-02.pdf 
（较早的草案draft-alvestrand-rmcat-congestion-03.pdf）


2.
（1）从WebRTC的最初级阶段开始，媒体引擎（由Google搭建，但是Firefox和Chrome都在使用）
就是基于远端带宽估计理论而搭建的。正像我之前说的那样，接收端会分析包间延时，
并且会对可用带宽产生一个估计值，然后使用RTCP信息报回给发送端，其中RTCP信息使用了
一种被设计来完成这项工作的信息类型：REMB。
REMB文档： draft-alvestrand-rmcat-remb-03.pdf


（2）另一个关于WebRTC实现的细节是，发送端不会只使用这个在REMB包中接收的带宽估计值，
也会使用反馈的丢包来决定最终发送的目标视频比特率。


send_side_bandwidth_estimation.cc
UpdateEstimate中更新lossRate;


（3）源代码  
控制上行带宽的文件在webrtc/modules/bitrate_controller，
下行带宽的文件是webrtc/modules/remote_bitrate_estimator


（4）传输与反馈
#1 传输宽序列号的报头扩展；
#2 传输反馈：接收端会周期性地将包含有关已接收数据包和包间延时的信息反馈给发送端。为了完成这项工作，接收端使用了新的RTCP包（传输反馈）
采用了部分Google建议的规范：https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-00
采用了部分官方标准化：https://www.ietf.org/id/draft-dt-rmcat-feedback-message-03.txt
源代码中的具体实现：webrtc/modules/rtp_rtcp/source/rtcp_packet/transport_feedback.cc


 这个RTCP反馈默认100ms发送一次，但是实际上是动态适应的，只会使用5%的可用带宽（最小值是50ms，最大值是250ms）。
 为了将大小控制在最小，这种新的RTCP包的格式十分简洁，包括块内的分组包，以base+diff的形式存储数字，
 或者将粒度降低到0.25ms为间隔。有人做了一个简单的测试，有了这些改进方案，其依旧会使用16Kbps来每50ms发送一次反馈数据包。


反馈机制的源代码参考：   
   webrtc/modules/rtp_rtcp/source/rtcp_packet/transport_feedback.cc
   webrtc/modules/remote_bitrate_estimator/remote_estimator_proxy.cc


3. WebRTC视频接收缓冲区基于KalmanFilter的延迟模型
http://www.jianshu.com/p/bb34995c549a


4. webrtc中的网络反馈与控制
http://befo.io/4206.html 


5. WebRTC GCC算法介绍
http://befo.io/1149.html
http://befo.io/4539.html(比较详细)
http://befo.io/4579.html（比较详细）


源代码分析：
简单一点的分析：
http://blog.csdn.net/liuhongxiangm/article/details/73914551