轉自：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信息以調整碼率。