WebRTC 基于GCC的擁塞控制(下)

本文在文章[1]的基礎(chǔ)上，從源代碼實(shí)現(xiàn)角度對(duì)WebRTC的GCC算法進(jìn)行分析。主要內(nèi)容包括： RTCP RR的數(shù)據(jù)源、報(bào)文構(gòu)造和接收，接收端基于數(shù)據(jù)包到達(dá)延遲的碼率估計(jì)，發(fā)送端碼率的計(jì)算以及生效于目標(biāo)模塊。

擁塞控制是實(shí)時(shí)流媒體應(yīng)用的重要服務(wù)質(zhì)量保證。通過(guò)本文和文章[1][2]，從數(shù)學(xué)基礎(chǔ)、算法步驟到實(shí)現(xiàn)細(xì)節(jié)，對(duì)WebRTC的擁塞控制GCC算法有一個(gè)全面深入的理解，為進(jìn)一步學(xué)習(xí)WebRTC奠定良好基礎(chǔ)。

1 GCC算法框架再學(xué)習(xí)

本節(jié)內(nèi)容基本上是文章[1]第1節(jié)的復(fù)習(xí)，目的是再次復(fù)習(xí)GCC算法的主要框架，梳理其算法流程中的數(shù)據(jù)流和控制流，以此作為后續(xù)章節(jié)的行文提綱。GCC算法的數(shù)據(jù)流和控制流如圖1所示。

圖1 GCC算法數(shù)據(jù)流和控制流

對(duì)發(fā)送端來(lái)講，GCC算法主要負(fù)責(zé)兩件事：1)接收來(lái)自接收端的數(shù)據(jù)包信息反饋，包括來(lái)自RTCP RR報(bào)文的丟包率和來(lái)自RTCP REMB報(bào)文的接收端估計(jì)碼率，綜合本地的碼率配置信息，計(jì)算得到目標(biāo)碼率A。2)把目標(biāo)碼率A生效于目標(biāo)模塊，包括PacedSender模塊，RTPSender模塊和ViEEncoder模塊等。

對(duì)于接收端來(lái)講，GCC算法主要負(fù)責(zé)兩件事：1）統(tǒng)計(jì)RTP數(shù)據(jù)包的接收信息，包括丟包數(shù)、接收RTP數(shù)據(jù)包的最高序列號(hào)等，構(gòu)造RTCP RR報(bào)文，發(fā)送回發(fā)送端。2）針對(duì)每一個(gè)到達(dá)的RTP數(shù)據(jù)包，執(zhí)行基于到達(dá)時(shí)間延遲的碼率估計(jì)算法，得到接收端估計(jì)碼率，構(gòu)造RTCP REMB報(bào)文，發(fā)送回發(fā)送端。

由此可見(jiàn)，GCC算法由發(fā)送端和接收端配合共同實(shí)現(xiàn)，接收端負(fù)責(zé)碼率反饋數(shù)據(jù)的生成，發(fā)送端負(fù)責(zé)根據(jù)碼率反饋數(shù)據(jù)計(jì)算目標(biāo)碼率，并生效于目標(biāo)模塊。本文接下來(lái)基于本節(jié)所述的GCC算法的四項(xiàng)子任務(wù)，分別詳細(xì)分析之。

2 RTCP RR報(bào)文構(gòu)造及收發(fā)

關(guān)于WebRTC上的RTP/RTCP協(xié)議的具體實(shí)現(xiàn)細(xì)節(jié)，可參考文章[3]。本節(jié)主要從RR報(bào)文的數(shù)據(jù)流角度，對(duì)其數(shù)據(jù)源、報(bào)文構(gòu)造和收發(fā)進(jìn)行分析。其數(shù)據(jù)源和報(bào)文構(gòu)造如圖2所示，報(bào)文接收和作用于碼率控制模塊如圖3所示。

在數(shù)據(jù)接收端，RTP數(shù)據(jù)包從Network線程到達(dá)Worker線程，經(jīng)過(guò)Call對(duì)象，VideoReceiveStream對(duì)象到達(dá)RtpStreamReceiver對(duì)象。在該對(duì)象中，主要執(zhí)行三項(xiàng)任務(wù)：1)接收端碼率估計(jì)；2) 轉(zhuǎn)發(fā)RTP數(shù)據(jù)包到VCM模塊；3)接收端數(shù)據(jù)統(tǒng)計(jì)。其中1)是下一節(jié)的重點(diǎn)，2)是RTP數(shù)據(jù)包進(jìn)一步組幀和解碼的地方；3)是統(tǒng)計(jì)RTP數(shù)據(jù)包接收信息，作為RTCP RR報(bào)文和其他數(shù)據(jù)統(tǒng)計(jì)模塊的數(shù)據(jù)來(lái)源，是我們本節(jié)重點(diǎn)分析的部分。

在RtpStreamReceiver對(duì)象中，RTP數(shù)據(jù)包經(jīng)過(guò)解析得到頭部信息，作為輸入?yún)?shù)調(diào)用ReceiveStatistianImpl::IncomingPacket()。該函數(shù)中分別調(diào)用UpdateCounters()和NotifyRtpCallback()，前者用來(lái)更新對(duì)象內(nèi)部的統(tǒng)計(jì)信息，如接收數(shù)據(jù)包計(jì)數(shù)等，后者用來(lái)更新RTP回調(diào)對(duì)象的統(tǒng)計(jì)信息，該信息用來(lái)作為getStats調(diào)用的數(shù)據(jù)源。

圖2 RTCP RR報(bào)文數(shù)據(jù)源及報(bào)文構(gòu)造

RTCP發(fā)送模塊在ModuleProcess線程中工作，RTCP報(bào)文周期性發(fā)送。當(dāng)線程判斷需要發(fā)送RTCP報(bào)文時(shí)，調(diào)用SendRTCP()進(jìn)行發(fā)送。接下來(lái)調(diào)用PrepareReport()準(zhǔn)備各類(lèi)型RTCP報(bào)文的數(shù)據(jù)。對(duì)于我們關(guān)心的RR報(bào)文，會(huì)調(diào)用AddReportBlock()獲取數(shù)據(jù)源并構(gòu)造ReportBlock對(duì)象:該函數(shù)首先通過(guò)ReceiveStatistianImpl::GetStatistics()拿到類(lèi)型為RtcpStatistics的數(shù)據(jù)源，然后以此填充ReportBlock對(duì)象。GetStatistics()會(huì)調(diào)用CalculateRtcpStatistics()計(jì)算ReportBlock的每一項(xiàng)數(shù)據(jù)，包括丟包數(shù)、接收數(shù)據(jù)包最高序列號(hào)等。ReportBlock對(duì)象會(huì)在接下來(lái)的報(bào)文構(gòu)造環(huán)節(jié)通過(guò)BuildRR()進(jìn)行序列化。RTCP報(bào)文進(jìn)行序列化之后，交給Network線程進(jìn)行網(wǎng)絡(luò)層發(fā)送。

圖3 RTCP RR報(bào)文接收及反饋

在發(fā)送端(即RTCP報(bào)文接收端)，RTCP報(bào)文經(jīng)過(guò)Network線程到達(dá)Worker線程，最后到達(dá)ModuleRtpRtcpImpl模塊調(diào)用IncomingRtcpPacket()進(jìn)行報(bào)文解析工作。解析完成以后，調(diào)用TriggerCallbacksFromRTCPPackets()反饋到回調(diào)模塊。在碼率估計(jì)方面，會(huì)反饋到BitrateController模塊。ReportBlock消息最終會(huì)到達(dá)BitrateControllerImpl對(duì)象，進(jìn)行下一步的目標(biāo)碼率確定。

至此，關(guān)于RTCP RR報(bào)文在擁塞控制中的執(zhí)行流程分析完畢。

3 接收端基于延遲的碼率估計(jì)

接收端基于數(shù)據(jù)包到達(dá)延遲的碼率估計(jì)是整個(gè)GCC算法最復(fù)雜的部分，本節(jié)在分析WebRTC代碼的基礎(chǔ)上，闡述該部分的實(shí)現(xiàn)細(xì)節(jié)。

接收端基于延遲碼率估計(jì)的基本思想是：RTP數(shù)據(jù)包的到達(dá)時(shí)間延遲m(i)反映網(wǎng)絡(luò)擁塞狀況。當(dāng)延遲很小時(shí)，說(shuō)明網(wǎng)絡(luò)擁塞不嚴(yán)重，可以適當(dāng)增大目標(biāo)碼率；當(dāng)延遲變大時(shí)，說(shuō)明網(wǎng)絡(luò)擁塞變嚴(yán)重，需要減小目標(biāo)碼率；當(dāng)延遲維持在一個(gè)低水平時(shí)，目標(biāo)碼率維持不變。其主要由三個(gè)模塊組成：到達(dá)時(shí)間濾波器，過(guò)載檢查器和速率控制器。

在實(shí)現(xiàn)上，WebRTC定義該模塊為遠(yuǎn)端碼率估計(jì)模塊RemoteBitrateEstimator，整個(gè)模塊的工作流程如圖4所示。需要注意的是，該模塊需要RTP報(bào)文擴(kuò)展頭部abs-send-time的支持，用以記錄RTP數(shù)據(jù)包在發(fā)送端的絕對(duì)發(fā)送時(shí)間，詳細(xì)請(qǐng)參考文獻(xiàn)[4]。

圖4 GCC算法基于延遲的碼率估計(jì)

接收端收到RTP數(shù)據(jù)包后，經(jīng)過(guò)一系列調(diào)用到RtpStreamReceiver對(duì)象，由該對(duì)象調(diào)用遠(yuǎn)端碼率估計(jì)模塊的總控對(duì)象RemoteBitrateEstimatorAbsSendTime，由該對(duì)象的總控函數(shù)IncomingPacketInfo()負(fù)責(zé)整個(gè)碼率估計(jì)流程，如圖4所示，算法從左到右依次調(diào)用子對(duì)象的功能函數(shù)。

總控函數(shù)首先調(diào)用InterArrival::ComputeDeltas()函數(shù)，用以計(jì)算相鄰數(shù)據(jù)包組的到達(dá)時(shí)間相對(duì)延遲，該部分對(duì)應(yīng)文章[1]的3.1節(jié)內(nèi)容。在計(jì)算到達(dá)時(shí)間相對(duì)延遲時(shí)，用到了RTP報(bào)文頭部擴(kuò)展abs-send-time。另外，實(shí)現(xiàn)細(xì)節(jié)上要注意數(shù)據(jù)包組的劃分，以及對(duì)亂序和突發(fā)時(shí)間的處理。

接下來(lái)算法調(diào)用OveruseEstimator::Update()函數(shù)，用以估計(jì)數(shù)據(jù)包的網(wǎng)絡(luò)延遲，該部分對(duì)應(yīng)文章[1]的3.2節(jié)內(nèi)容。對(duì)網(wǎng)絡(luò)延遲的估計(jì)用到了Kalman濾波，算法的具體細(xì)節(jié)請(qǐng)參考文章[2]。Kalman濾波的結(jié)果為網(wǎng)絡(luò)延遲m(i)，作為下一階段網(wǎng)絡(luò)狀態(tài)檢測(cè)的輸入?yún)?shù)。

算法接著調(diào)用OveruseDetector::Detect()，用來(lái)檢測(cè)當(dāng)前網(wǎng)絡(luò)的擁塞狀況，該部分對(duì)應(yīng)文章[1]的3.2節(jié)內(nèi)容。網(wǎng)絡(luò)狀態(tài)檢測(cè)用當(dāng)前網(wǎng)絡(luò)延遲m(i)和閾值gamma_1進(jìn)行比較，判斷出overuse，underuse和normal三種網(wǎng)絡(luò)狀態(tài)之一。在算法細(xì)節(jié)上，要注意overuse的判定相對(duì)復(fù)雜一些：當(dāng)m(i) > gamma_1時(shí)，計(jì)算處于當(dāng)前狀態(tài)的持續(xù)時(shí)間t(ou)，如果t(ou) > gamma_2，并且m(i) > m(i-1)，則發(fā)出網(wǎng)絡(luò)過(guò)載信號(hào)Overuse。如果m(i)小于m(i-1)，即使高于閥值gamma_1也不需要發(fā)出過(guò)載信號(hào)。在判定網(wǎng)絡(luò)擁塞狀態(tài)之后，還要調(diào)用UpdateThreshold()更新閾值gamma_1。

算法接著調(diào)用AimdRateControl::Update()和UpdateBandwidthEstimate()函數(shù)，用以估計(jì)當(dāng)前網(wǎng)絡(luò)狀態(tài)下的目標(biāo)碼率Ar，該部分對(duì)應(yīng)文章[1]的3.3節(jié)。算法基于當(dāng)前網(wǎng)絡(luò)狀態(tài)和碼率變化趨勢(shì)有限狀態(tài)機(jī)，采用AIMD(Additive Increase Multiplicative Decrease)方法計(jì)算目標(biāo)碼率，具體計(jì)算公式請(qǐng)參考文章[1]。需要注意的是，當(dāng)算法處于開(kāi)始階段時(shí)，會(huì)采用Multiplicative Increase方法快速增加碼率，以加快碼率估計(jì)速度。

此時(shí)，我們已經(jīng)拿到接收端估計(jì)的目標(biāo)碼率Ar。接下來(lái)以Ar為參數(shù)調(diào)用VieRemb對(duì)象的OnReceiveBitrateChange()函數(shù)，發(fā)送REMB報(bào)文到發(fā)送端。REMB報(bào)文會(huì)推送到RTCP模塊，并設(shè)置REMB報(bào)文發(fā)送時(shí)間為立即發(fā)送。關(guān)于REMB報(bào)文接下來(lái)的發(fā)送和接收流程，和第1節(jié)描述的RTCP報(bào)文一般處理流程是一樣的，即經(jīng)過(guò)序列化發(fā)送到網(wǎng)絡(luò)，然后發(fā)送端收到以后，反序列化出描述結(jié)構(gòu)，最后通過(guò)回調(diào)函數(shù)到達(dá)發(fā)送端碼率控制模塊BitrateControllerImpl。

至此，接收端基于延遲的碼率估計(jì)過(guò)程描述完畢。

4 發(fā)送端碼率計(jì)算及生效

在發(fā)送端，目標(biāo)碼率計(jì)算和生效是異步進(jìn)行的，即Worker線程從RTCP接收模塊經(jīng)回調(diào)函數(shù)拿到丟包率和REMB碼率之后，計(jì)算得到目標(biāo)碼率A；然后ModuleProcess線程異步把目標(biāo)碼率A生效到目標(biāo)模塊如PacedSender和ViEEncoder等。下面分別描述碼率計(jì)算和生效過(guò)程。

圖5 發(fā)送端碼率計(jì)算過(guò)程

碼率計(jì)算過(guò)程如圖5所示：Worker線程從RTCPReceiver模塊經(jīng)過(guò)回調(diào)函數(shù)拿到RTCP RR報(bào)文和REMB報(bào)文的數(shù)據(jù)，到達(dá)BitrateController模塊。RR報(bào)文中的丟包率會(huì)進(jìn)入U(xiǎn)pdate()函數(shù)中計(jì)算碼率，碼率計(jì)算公式如文章[1]第2節(jié)所述。然后算法流程進(jìn)入CapBitrateToThreshold()函數(shù)，和配置的最大最小碼率和遠(yuǎn)端估計(jì)碼率進(jìn)行比較后，確定最終目標(biāo)碼率。而REMB報(bào)文的接收端估計(jì)碼率Ar則直接進(jìn)入CapBitrateToThreshold()函數(shù)參與目標(biāo)碼率的確定。目標(biāo)碼率由文章[1]的3.4節(jié)所示公式進(jìn)行確定。需要注意的是，RR報(bào)文和REMB報(bào)文一般不在同一個(gè)RTCP報(bào)文里。

圖6 發(fā)送端碼率生效過(guò)程

發(fā)送端碼率生效過(guò)程如圖6所示：ModuleProcess線程調(diào)用擁塞控制總控對(duì)象CongestionController周期性從碼率控制模塊BitrateControllerImpl中獲取當(dāng)前最新目標(biāo)碼率A，然后判斷目標(biāo)碼率是否有變化。若是，則把最新目標(biāo)碼率設(shè)置到相關(guān)模塊中，主要包括PacedSender模塊，RTPSender模塊和ViEEncoder模塊。

對(duì)于PacedSender模塊，設(shè)置碼率主要是為了平滑RTP數(shù)據(jù)包的發(fā)送速率，盡量避免數(shù)據(jù)包Burst造成碼率波動(dòng)。對(duì)于RTPSender模塊，設(shè)置碼率是為了給NACK模塊預(yù)留碼率，如果預(yù)留碼率過(guò)小，則在某些情況下對(duì)于NACK報(bào)文請(qǐng)求選擇不響應(yīng)。對(duì)于ViEEncoder模塊，設(shè)置碼率有兩個(gè)用途：1)控制發(fā)送端丟幀策略，根據(jù)設(shè)定碼率和漏桶算法決定是否丟棄當(dāng)前幀。2)控制編碼器內(nèi)部碼率控制，設(shè)定碼率作為參數(shù)傳輸?shù)骄幋a器內(nèi)部，參與內(nèi)部碼率控制過(guò)程。

至此，發(fā)送端碼率計(jì)算和生效過(guò)程分析完畢。

5 總結(jié)

本文結(jié)合文章[1]，深入WebRTC代碼內(nèi)部，詳細(xì)分析了WebRTC的GCC算法的實(shí)現(xiàn)細(xì)節(jié)。通過(guò)本文，對(duì)WebRTC的代碼結(jié)構(gòu)和擁塞控制實(shí)現(xiàn)細(xì)節(jié)有了更深層次的理解，為進(jìn)一步學(xué)習(xí)WebRTC奠定良好基礎(chǔ)。

參考文獻(xiàn)

[1] WebRTC基于GCC的擁塞控制(上) – 算法分析
http://www.jianshu.com/p/0f7ee0e0b3be
[2] WebRTC視頻接收緩沖區(qū)基于KalmanFilter的延遲模型.
http://www.jianshu.com/p/bb34995c549a
[3] WebRTC中RTP/RTCP協(xié)議實(shí)現(xiàn)分析
http://www.jianshu.com/p/c84be6f3ddf3
[4] abs-send-time.?https://webrtc.org/experiments/rtp-hdrext/abs-send-time/