WebRTC 基于GCC的擁塞控制(上)
實(shí)時(shí)流媒體應(yīng)用的最大特點(diǎn)是實(shí)時(shí)性,而延遲是實(shí)時(shí)性的最大敵人。從媒體收發(fā)端來講,媒體數(shù)據(jù)的處理速度是造成延遲的重要原因;而從傳輸角度來講,網(wǎng)絡(luò)擁塞則是造成延遲的最主要原因。網(wǎng)絡(luò)擁塞可能造成數(shù)據(jù)包丟失,也可能造成數(shù)據(jù)傳輸時(shí)間變長,延遲增大。
擁塞控制是實(shí)時(shí)流媒體應(yīng)用質(zhì)量保證(QoS)的重要手段之一,它在緩解網(wǎng)絡(luò)擁堵、減小網(wǎng)絡(luò)延遲、平滑數(shù)據(jù)傳輸?shù)荣|(zhì)量保證方面發(fā)揮重要作用。WebRTC通控制發(fā)送端數(shù)據(jù)發(fā)送碼率來達(dá)到控制網(wǎng)絡(luò)擁塞的目的,其采用谷歌提出的擁塞控制算法(Google Congestion Control,簡稱GCC[1])來控制發(fā)送端碼率。
本文是關(guān)于WebRTC擁塞控制算法GCC的上半部分,主要集中于對(duì)算法的理論分析,力圖對(duì)WebRTC的QoS有一個(gè)全面直觀的認(rèn)識(shí)。在下半部分,將深入WebRTC源代碼內(nèi)部,仔細(xì)分析GCC的實(shí)現(xiàn)細(xì)節(jié)。
1 GCC算法綜述
Google關(guān)于GCC的RFC文檔在文獻(xiàn)[1],該RFC目前處于草案狀態(tài),還沒有成為IETF的正式RFC。此外,Google陸續(xù)發(fā)布了一系列論文[2][3][4]來論述該算法的實(shí)現(xiàn)細(xì)節(jié),以及其在Google Hangouts、WebRTC等產(chǎn)品中的應(yīng)用。本文主要根據(jù)這些文檔資料,從理論上學(xué)習(xí)GCC算法。
GCC算法分兩部分:發(fā)送端基于丟包率的碼率控制和接收端基于延遲的碼率控制。如圖1所示。
圖1 GCC算法整體結(jié)構(gòu)
基于丟包率的碼率控制運(yùn)行在發(fā)送端,依靠RTCP RR報(bào)文進(jìn)行工作。WebRTC在發(fā)送端收到來自接收端的RTCP RR報(bào)文,根據(jù)其Report Block中攜帶的丟包率信息,動(dòng)態(tài)調(diào)整發(fā)送端碼率As?;谘舆t的碼率控制運(yùn)行在接收端,WebRTC根據(jù)數(shù)據(jù)包到達(dá)的時(shí)間延遲,通過到達(dá)時(shí)間濾波器,估算出網(wǎng)絡(luò)延遲m(t),然后經(jīng)過過載檢測(cè)器判斷當(dāng)前網(wǎng)絡(luò)的擁塞狀況,最后在碼率控制器根據(jù)規(guī)則計(jì)算出遠(yuǎn)端估計(jì)最大碼率Ar。得到Ar之后,通過RTCP REMB報(bào)文返回發(fā)送端。發(fā)送端綜合As、Ar和預(yù)配置的上下限,計(jì)算出最終的目標(biāo)碼率A,該碼率會(huì)作用到Encoder、RTP和PacedSender等模塊,控制發(fā)送端的碼率。
2 發(fā)送端基于丟包率的碼率控制
GCC算法在發(fā)送端基于丟包率控制發(fā)送碼率,其基本思想是:丟包率反映網(wǎng)絡(luò)擁塞狀況。如果丟包率很小或者為0,說明網(wǎng)絡(luò)狀況良好,在不超過預(yù)設(shè)最大碼率的情況下,可以增大發(fā)送端碼率;反之如果丟包率變大,說明網(wǎng)絡(luò)狀況變差,此時(shí)應(yīng)減少發(fā)送端碼率。在其它情況下,發(fā)送端碼率保持不變。
GCC使用的丟包率根據(jù)接收端RTP接收統(tǒng)計(jì)信息計(jì)算得到,通過RTCP RR報(bào)文中返回給發(fā)送端。RTCP RR報(bào)文統(tǒng)計(jì)接收端RTP接收信息,如Packet Loss,Jitter,DLSR等等,如圖2所示:
圖2 RTCP RR報(bào)文結(jié)構(gòu)[5]
發(fā)送端收到RTCP RR報(bào)文并解析得到丟包率后,根據(jù)圖3公式計(jì)算發(fā)送端碼率:當(dāng)丟包率大于0.1時(shí),說明網(wǎng)絡(luò)發(fā)生擁塞,此時(shí)降低發(fā)送端碼率;當(dāng)丟包率小于0.02時(shí),說明網(wǎng)絡(luò)狀況良好,此時(shí)增大發(fā)送端碼率;其他情況下,發(fā)送端碼率保持不變。
圖3 GCC基于丟包率的碼率計(jì)算公式[4]
最終碼率會(huì)作用于Encoder、RTP和PacedSender模塊,用以在編碼器內(nèi)部調(diào)整碼率和平滑發(fā)送端發(fā)送速率。
3 接收端基于延遲的碼率控制
GCC算法在接收端基于數(shù)據(jù)包到達(dá)延遲估計(jì)發(fā)送碼率Ar,然后通過RTCP REMB報(bào)文反饋到發(fā)送端,發(fā)送端把Ar作為最終目標(biāo)碼率的上限值。其基本思想是: RTP數(shù)據(jù)包的到達(dá)時(shí)間延遲m(i)反映網(wǎng)絡(luò)擁塞狀況。當(dāng)延遲很小時(shí),說明網(wǎng)絡(luò)擁塞不嚴(yán)重,可以適當(dāng)增大目標(biāo)碼率;當(dāng)延遲變大時(shí),說明網(wǎng)絡(luò)擁塞變嚴(yán)重,需要減小目標(biāo)碼率;當(dāng)延遲維持在一個(gè)低水平時(shí),目標(biāo)碼率維持不變。
基于延時(shí)的擁塞控制由三個(gè)主要模塊組成:到達(dá)時(shí)間濾波器,過載檢查器和速率控制器;除此之外還有過載閾值自適應(yīng)模塊和REMB報(bào)文生成模塊,如圖1所示。下面分別論述其工作過程。
3.1 到達(dá)時(shí)間濾波器(Arrival-time Filter)
該模塊用以計(jì)算相鄰相鄰兩個(gè)數(shù)據(jù)包組的網(wǎng)絡(luò)排隊(duì)延遲m(i)。數(shù)據(jù)包組定義為一段時(shí)間內(nèi)連續(xù)發(fā)送的數(shù)據(jù)包的集合。一系列數(shù)據(jù)包短時(shí)間里連續(xù)發(fā)送,這段時(shí)間稱為突發(fā)時(shí)間,建議突發(fā)時(shí)間為5ms。不建議在突發(fā)時(shí)間內(nèi)的包間隔時(shí)間做度量,而是把它們做為一組來測(cè)量。通過相鄰兩個(gè)數(shù)據(jù)包組的發(fā)送時(shí)間和到達(dá)時(shí)間,計(jì)算得到組間延遲d (i)。組間延遲示意圖及計(jì)算公式如圖4所示:
圖4 組間延遲示意圖
T(i)是第i個(gè)數(shù)據(jù)包組中第一個(gè)數(shù)據(jù)包的發(fā)送時(shí)間,t(i)是第i個(gè)數(shù)據(jù)包組中最后一個(gè)數(shù)據(jù)包的到達(dá)時(shí)間。幀間延遲通過如下公式計(jì)算得到:
d(i)?=?t(i)?–?t(i-1)?–?(T(i)?–?T(i-1))????(3.1.1)
公式1.3.1是d(i)的觀測(cè)方程。另一方面,d(i)也可由如下狀態(tài)方程得到:
d(i)?=?dL(i)/C(i)?+?w(i)??????????????????(3.1.2) d(i)?=?dL(i)/C(i)?+?m(i)?+?v(i)???????????(3.1.3)
其中dL(i)表示相鄰兩幀的長度差,C(i)表示網(wǎng)絡(luò)信道容量,m(i)表示網(wǎng)絡(luò)排隊(duì)延遲,v(i)表示零均值噪聲。m(i)即是我們要求得的網(wǎng)絡(luò)排隊(duì)延遲。通過Kalman Filter可以求得該值。具體計(jì)算過程請(qǐng)參考文獻(xiàn)[1][4][6]。
3.2 過載檢測(cè)器(Over-use Detector)
該模塊以到達(dá)時(shí)間濾波器計(jì)算得到的網(wǎng)絡(luò)排隊(duì)延遲m(i)為輸入,結(jié)合當(dāng)前閾值gamma_1,判斷當(dāng)前網(wǎng)絡(luò)是否過載。判斷算法如圖5所示[2]。
圖5 過載檢測(cè)器偽代碼
算法基于當(dāng)前網(wǎng)絡(luò)排隊(duì)延遲m(i)和當(dāng)前閾值gamma_1判斷當(dāng)前網(wǎng)絡(luò)擁塞狀況[2]:當(dāng)m(i) > gamma_1時(shí),算法計(jì)算處于當(dāng)前狀態(tài)的持續(xù)時(shí)間t(ou) = t(ou) + delta(t),如果t(ou)大于設(shè)定閾值gamma_2(實(shí)際計(jì)算中設(shè)置為10ms),并且m(i) > m(i-1),則發(fā)出網(wǎng)絡(luò)過載信號(hào)Overuse,同時(shí)重置t(ou)。如果m(i)小于m(i-1),即使高于閥值gamma_1也不需要發(fā)出過載信號(hào)。當(dāng)m(i) < -gamma_1時(shí),算法認(rèn)為當(dāng)前網(wǎng)絡(luò)處于空閑狀態(tài),發(fā)出網(wǎng)絡(luò)低載信號(hào)Underuse。當(dāng) – gamma_1 <= m(i) <= gamma_1是,算法認(rèn)為當(dāng)前網(wǎng)絡(luò)使用率適中,發(fā)出保持信號(hào)Hold。算法隨著時(shí)間軸的計(jì)算過程可從圖6中看到。
圖6 時(shí)間軸上的過載檢測(cè)過程
需要注意的是,閥值gamma_1對(duì)算法的影響很大,并且閾值gamma_1是自適應(yīng)性的。如果其是靜態(tài)值,會(huì)帶來一系列問題,詳見文獻(xiàn)[4]。所以gamma_1需要?jiǎng)討B(tài)調(diào)整來達(dá)到良好的表現(xiàn)。這就是圖1中的Adaptive threshould模塊。閾值gamma_1動(dòng)態(tài)更新的公式如下:
gamma_1(i)?=?gamma_1(i-1)?+?(t(i)-t(i-1))?*?K(i)?*?(|m(i)|-gamma_1(i-1))????(3.2.4)
當(dāng)|m(i)|>gamma_1(i-1)時(shí)增加gamma_1(i),反之減小gamma_1(i),而當(dāng)|m(i)|– gamma_1(i) >15,建議gamma_1(i)不更新。K(i)為更新系數(shù),當(dāng)|m(i)|
gamma_1(0)?=?12.5?ms gamma_2??=?10?ms K_u?=?0.01 K_d?=?0.00018
3.3 速率控制器(Remote Rate Controller)
該模塊以過載檢測(cè)器給出的當(dāng)前網(wǎng)絡(luò)狀態(tài)s為輸入,首先根據(jù)圖7所示的有限狀態(tài)機(jī)判斷當(dāng)前碼率的變化趨勢(shì),然后根據(jù)圖8所示的公式計(jì)算目標(biāo)碼率Ar。
圖7 目標(biāo)碼率Ar變化趨勢(shì)有限狀態(tài)機(jī)
當(dāng)前網(wǎng)絡(luò)過載時(shí),目標(biāo)碼率處于Decrease狀態(tài);當(dāng)前網(wǎng)絡(luò)低載時(shí),目標(biāo)碼率處于Hold狀態(tài);當(dāng)網(wǎng)絡(luò)正常時(shí),處于Decrease狀態(tài)時(shí)遷移到Hold狀態(tài),處于Hold/Increase狀態(tài)時(shí)都遷移到Increase狀態(tài)。當(dāng)判斷出碼率變化趨勢(shì)后,根據(jù)圖8所示公式進(jìn)行計(jì)算目標(biāo)碼率。
圖8 目標(biāo)碼率Ar計(jì)算公式
當(dāng)碼率變化趨勢(shì)為Increase時(shí),當(dāng)前碼率為上次碼率乘上系數(shù)1.05;當(dāng)碼率變化趨勢(shì)為Decrease,當(dāng)前碼率為過去500ms內(nèi)的最大接收碼率乘上系數(shù)0.85。當(dāng)碼率變化趨勢(shì)為Hold時(shí),當(dāng)前碼率保持不變。目標(biāo)碼率Ar計(jì)算得到之后,下一步把Ar封裝到REMB報(bào)文中發(fā)送回發(fā)送端。在REMB報(bào)文中,Ar被表示為Ar = M * 2^Exp,其中M封裝在BR Mantissa域,占18位;Exp封裝在BR Exp域,占6位。REMB報(bào)文是Payload為206的RTCP報(bào)文[7],格式如圖9所示。
圖9 REMB報(bào)文格式
REMB報(bào)文每秒發(fā)送一次,當(dāng)Ar(i) < 0.97 * Ar(i-1)時(shí)則立即發(fā)送。
3.4 發(fā)送端目標(biāo)碼率的確定
發(fā)送端最終目標(biāo)碼率的確定結(jié)合了基于丟包率計(jì)算得到的碼率As和基于延遲計(jì)算得到的碼率Ar。此外,在實(shí)際實(shí)現(xiàn)中還會(huì)配置目標(biāo)碼率的上限值和下限值。綜合以上因素,最終目標(biāo)碼率確定如下:
????target_bitrate?=?max(?min(?min(As,?Ar),?Amax),?Amin)????????(3.4.1)
目標(biāo)碼率確定之后,分別設(shè)置到Encoder模塊和PacedSender模塊。
4 總結(jié)
本文在廣泛調(diào)研WebRTC GCC算法的相關(guān)RFC和論文的基礎(chǔ)上,全面深入學(xué)習(xí)GCC算法的理論分析,以此為契機(jī)力圖對(duì)WebRTC的QoS有一個(gè)全面直觀的認(rèn)識(shí)。為將來深入WebRTC源代碼內(nèi)部分析GCC的實(shí)現(xiàn)細(xì)節(jié)奠定基礎(chǔ)。
參考文獻(xiàn)
[1] A Google Congestion Control Algorithm for Real-Time Communication.
draft-alvestrand-rmcat-congestion-03
[2] Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb.
[3] Experimental Investigation of the Google Congestion Control for Real-Time Flows.
[4] Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC). MMSys’16, May 10-13, 2016, Klagenfurt, Austria
[5] RFC3550: RTP - A Transport Protocol for Real-Time Applications
[6] WebRTC視頻接收緩沖區(qū)基于KalmanFilter的延遲模型.
[7] RTCP message for Receiver Estimated Maximum Bitrate. draft-alvestrand-rmcat-remb-03