转自：http://blog.csdn.net/u013160228/article/details/46392037
WebRTC的代码真是非常之大啊，下载以及编译了我好几天才搞完。。。。。
可以看到WebRTCd代码分成了4个部分，目前为止只看了talk里的一些东西。
1、 talk中的项目文件大多数都是以libjingle开头的，可以看出libjingle是WebRTC中非常核心的一个东西啦。
libjingle中开辟了两个通道，分别为会话通道和数据通道，一个用来会话建立管理等，一个用来传输数据。
libjingle_media是用来渲染获取视频，libjingle_p2p和libjingle_peerconnection是不同的会话方式用到的库吧，现在还没有细看
peerconnection_client和peerconnection_server则是可以直接运行的demo，设为启动项目就可以测试了，先运行server。
2、由于项目研究的是关于带宽估计的东西，所以我们看的文件主要有两个，一个是上行带宽的估计和控制，一个是下行带宽的估计和控制
上行带宽的文件在webrtc/modules/bitrate_controller，下行带宽的文件是remote_bitrate_estimator
下面讲一讲Goolge的WebRTC中自带的码率控制：
发送端发送RTP包，同时接收来自于接收端的RTCP反馈报告，整个拥塞控制算法分成了接收端和发送端两个部分。接收端的控制算法是基于时延的算法，其目的是减小时延；发送端的控制算法是基于丢包率的算法，其目的是减少丢包。接收端的算法计算出一个速率Ar，然后将这个码率反馈给发送端，用来限制发送端基于丢包率算法计算出来的发送速率。
发送端基于丢包率的控制方法在每一个tk时刻或者tr时刻启动。tk表示第k个RTCP反馈报告的到达时间，tr表示第r个REMB信息到达发送端的时间，其中REMB信息中包含接收端反馈的Ar信息。RTCP包内包含丢包率fl(tk)，发送端根据丢包率计算接下来的发送速率，具体计算方式图公式1所示：
接收端速率控制：
接收端算法的目的就是计算出能保证低时延情况下的接收速率Ar，Ar的计算过程如图2所示：
下面介绍接收端也就是remote_bitrate_estimator中的几个模块算法
1) The arrival-time filter
该模块的目的是为了计算排队时延m(ti),单向时延（one way delay variation）计算方式如下：dm(ti)= ti–ti-1–(Ti –Ti-1 ) （3）
式中，Ti表示第i帧视频发送的时间戳，ti 表示第i个视频帧接收到的时间戳。单向时延是三个部分的总和，包括传输时间、排队时延m(ti)、网络抖动n(ti)。GCC算法中提出了下面这个公式：
式中，∆L(ti) = L(ti) −L(ti−1)，L(ti)是第i个视频帧的长度，C(ti)是瓶颈链路容量估计，n(ti)是网络抖动（高斯噪声模型）。为了将dm(ti) − d(ti)的差值缩小到趋于零，用卡尔曼滤波器提取出状态向量，具体工作方式如图3所示：
The over-use detector
每帧视频收到的时刻，即ti时刻，该模块都会产生一个s信号以驱动下一个码率控制模块。当m(ti)大于阀值γ，信号为overuse；当m(ti)小于阀值γ，信号为underuse。
Remote rate controller
该模块的目的是为了估算数接收速率Ar，其算法流程如图2所示，由信号s决定码率的调整，η ∈[1.005,1.3],α ∈[0.8,0.95]分别为增性系数和碱性系数。
上调：Ar(ti)= ηAr(ti−1)
下调：Ar(ti)= αR(ti)，其中R(ti)是最近500ms内的平均接收速率。
REMB Processing
该模块的功能是将上一个模块计算出的速率Ar通过REMB信息发给客户端。REMB信息发送间隔为1s，但当Ar下降了3%，即Ar(ti) < 0.97Ar(ti−1)时，则立即发送REMB信息以调整码率。