在復(fù)雜的網(wǎng)絡(luò)環(huán)境中，想要實(shí)現(xiàn)實(shí)時(shí)視頻傳輸，擁塞控制算法是尤為重點(diǎn)的一環(huán)。本文整理自學(xué)霸君高級技術(shù)總監(jiān)袁榮喜在LiveVideoStackCon 2019上海大會中的分享，詳細(xì)介紹了BBR擁塞控制算法在實(shí)時(shí)視頻傳輸中新的實(shí)踐以及優(yōu)缺點(diǎn)。

文 /?袁榮喜

整理 /?LiveVideoStack

大家好，我是來自學(xué)霸君的袁榮喜，本次分享內(nèi)容的核心是BBR在實(shí)時(shí)視頻傳輸中的實(shí)踐。BBR其實(shí)是基于TCP的一種擁塞算法，在實(shí)時(shí)音視頻中的運(yùn)用也是一種全新的嘗試，接下來我將會為大家逐一介紹這種嘗試所帶來的優(yōu)缺點(diǎn)。

1.?傳輸與擁塞

?

講到音視頻的傳輸或者實(shí)時(shí)傳輸，就必須要了解傳輸和擁塞的關(guān)系。

1.1 傳輸三角關(guān)系

?

實(shí)時(shí)傳輸領(lǐng)域存在著一種三角關(guān)系，其中成本一般認(rèn)為是硬件、軟件和通訊帶寬所帶來的成本，延遲是指獲得整個(gè)流媒體的時(shí)延，比如實(shí)時(shí)視頻中的雙端延遲和觀看長視頻時(shí)的首幀延遲，質(zhì)量可以理解為視頻清晰度和數(shù)據(jù)完備性，這種三角關(guān)系均是以保證其中一角而犧牲其余兩角的方案來建立實(shí)時(shí)傳輸方案。隨著互聯(lián)網(wǎng)的發(fā)展，設(shè)備的成本越來越低，手持設(shè)備越來越方便，但由此也帶來很多在實(shí)時(shí)視頻傳輸過程中的問題。

1.2 實(shí)時(shí)視頻的困擾

?

實(shí)時(shí)視頻傳輸中常見的問題主要有卡頓、延遲、抖動、視頻模糊和斷線重連五種。造成這些問題的原因是多種多樣的，但其中最不能忽視的一個(gè)原因就是網(wǎng)絡(luò)擁塞。

1.3 網(wǎng)絡(luò)擁塞

?

網(wǎng)絡(luò)擁塞是指發(fā)送的數(shù)據(jù)超過了網(wǎng)絡(luò)能承載的傳輸能力，但人的需求無限，即使新技術(shù)在不斷地發(fā)展，網(wǎng)絡(luò)擁塞的情況在未來還是會不斷出現(xiàn)。

網(wǎng)絡(luò)發(fā)生擁塞的原因大致有以下幾點(diǎn)，WiFi/4G信號衰減、核心傳輸鏈路衰減、網(wǎng)絡(luò)出口競爭、重發(fā)風(fēng)暴和設(shè)備性能衰減等問題都會帶來網(wǎng)絡(luò)擁塞的問題，其中WiFi/4G信號衰減意味著信號被污染，導(dǎo)致傳輸信道的吞吐率下降，最終造成網(wǎng)絡(luò)擁塞。

針對網(wǎng)絡(luò)擁塞的問題，業(yè)界也一直在提出不同的擁塞控制算法，擁塞算法的核心包括判斷擁塞狀態(tài)和決策合適的發(fā)送碼率，這兩個(gè)其實(shí)是map和reduce模型，把網(wǎng)絡(luò)上返回的數(shù)據(jù)進(jìn)行map，通過網(wǎng)絡(luò)狀態(tài)ruduce出一個(gè)合理的發(fā)送碼率。

GCC是一種基于延遲預(yù)估和丟包的擁塞控制算法，算法分為在接收端進(jìn)行卡爾曼算法預(yù)估后返回發(fā)送端進(jìn)行碼率調(diào)整兩部分。Transport CC是基于發(fā)送端線性預(yù)測的擁塞控制算法，與GCC一樣主體都是基于時(shí)延的擁塞控制判斷。這兩種算法存在不同程度上的缺陷，在實(shí)現(xiàn)算法的過程中過于學(xué)術(shù)，比如GCC中有一個(gè)丟包率2%/10%的預(yù)值，但其實(shí)擁塞發(fā)生并不一定會產(chǎn)生丟包，而且丟包也不一定意味著發(fā)生擁塞，這種情況對于GCC是失效的。GCC基于時(shí)延估算的主體在現(xiàn)階段來看與帶寬的記憶丟包沒有爭搶率，斯坦福大學(xué)提出的Salsify算法是基于視頻幀之間的時(shí)延去估算整個(gè)編碼器的編碼速度，但它一定要在編碼器的基礎(chǔ)上執(zhí)行，無法滿足將視頻傳到sever上進(jìn)行分發(fā)的要求，如果只做分段擁塞控制就需要在sever上進(jìn)行重解碼和重編碼，無法滿足目前實(shí)時(shí)視頻領(lǐng)域的應(yīng)用。

實(shí)時(shí)傳輸理想的擁塞控制算法要滿足三個(gè)特點(diǎn)，第一要相對激進(jìn)，算法要能搶過流氓軟件和一些基于丟包的算法。第二要對百毫秒級或者是毫秒級的碼率進(jìn)行實(shí)時(shí)調(diào)整，間隔盡量減小，盡量快的適應(yīng)傳輸條件，這樣卡頓時(shí)間不會太長，也能夠帶來更好的用戶體驗(yàn)。第三是要能應(yīng)對延遲型和丟包型的擁塞，同時(shí)能夠進(jìn)行分段計(jì)算。

2. BBR

?

BBR是基于接收端反饋和發(fā)送端調(diào)節(jié)碼率的擁塞控制算法。

2.1 模型

遠(yuǎn)端packet feedback反饋信息輸送到BBR之后，經(jīng)過一系列運(yùn)算得到擁塞控制的窗口大小（TCP發(fā)送端口）和發(fā)送碼率。

2.2 網(wǎng)絡(luò)FIFO概念

?

首先整個(gè)網(wǎng)絡(luò)分為正在傳輸和發(fā)生堆積兩部分，BBR在構(gòu)建模型中只計(jì)算網(wǎng)絡(luò)正在傳輸?shù)牟糠?#xff0c;計(jì)算過程中引入了BDP（擁塞控制窗口）的概念。當(dāng)前路由器的吞吐和緩沖能力大大加強(qiáng)，包在發(fā)送到路由器時(shí)雖然會發(fā)生擁塞，但在足夠的內(nèi)存和磁盤存儲空間的條件下不會發(fā)生丟包現(xiàn)象，記憶延遲對網(wǎng)絡(luò)更加敏感，但記憶丟包如果不發(fā)生丟包碼率就不會下降，在這種情況下記憶延遲搶不過丟包。

BDP的計(jì)算方式是網(wǎng)絡(luò)周期性最小延遲*網(wǎng)路周期性最大帶寬。

BDP中網(wǎng)絡(luò)周期性最小延遲和網(wǎng)路周期性最大帶寬是通過BBR的四個(gè)狀態(tài)機(jī)來計(jì)算的，第一個(gè)狀態(tài)是STARTUP，BBR剛進(jìn)入STARTUP時(shí)會進(jìn)行慢啟動，慢啟動不斷地增加帶寬到帶寬不再增長或者發(fā)生丟包現(xiàn)象就會切入DRAIN排空狀態(tài)，進(jìn)入排空狀態(tài)是由于BPD已滿，飛行數(shù)據(jù)發(fā)生堆積。DRAIN狀態(tài)會在發(fā)送數(shù)據(jù)小于BDP時(shí)進(jìn)入重新評估帶寬的過程，如果持續(xù)一定周期還沒有探測到最小RTT的值，就需要進(jìn)行最小RTT的探測工作，BBR將窗口設(shè)置為4個(gè)miss大小或者保留3/4的大小去估算最小延遲，估算結(jié)束后重新回到STARTUP狀態(tài)。

BDP/RTT就是我們認(rèn)為可以發(fā)送的碼率。

發(fā)送出去會有pace sender通過平滑發(fā)送發(fā)到接收端，接收端會把一個(gè)一個(gè)的包返回給發(fā)送端，發(fā)送端通過事件可以很快得到最小延遲和最大帶寬的樣本，結(jié)合一定的算法得到相對應(yīng)的BDP，由BDP可以得到pacing rate，最后不斷調(diào)整帶寬形成循環(huán)，達(dá)成擁塞控制的目的。

3. 實(shí)時(shí)視頻傳輸與BBR

?

3.1 實(shí)時(shí)視頻傳輸與BBR相結(jié)合

網(wǎng)絡(luò)協(xié)議進(jìn)入網(wǎng)絡(luò)接收器以后，通過RTCP的方式獲得feedback信息直接輸入BBR，再通過一系列狀態(tài)機(jī)計(jì)算出帶寬和窗口大小，碼率分配器會根據(jù)各種情況對碼率進(jìn)行重新分配，調(diào)節(jié)視頻編碼器使碼率達(dá)到縮放自如的反饋。實(shí)時(shí)視頻有非持續(xù)性的特點(diǎn)，關(guān)鍵幀之間流量不均勻，幀間存在時(shí)延，突然發(fā)送實(shí)時(shí)視頻會導(dǎo)致中間為空的狀態(tài)，為了防止這樣的情況發(fā)生設(shè)計(jì)了pacer用來平滑發(fā)送。

3.2 Feedback

RTT在實(shí)際應(yīng)用中設(shè)計(jì)的是記憶幀的反饋，這樣減少了反饋數(shù)量的同時(shí)也提升了效率，通過上圖中的公式可以得到RTT的反饋序列。

即時(shí)速率是通過發(fā)送的數(shù)據(jù)和接收/發(fā)送端的相互統(tǒng)計(jì)，由于網(wǎng)絡(luò)發(fā)生抖動會使send bitrate變得非常大，即時(shí)速率不能超過發(fā)送端本身的速度，所以要在兩值中取最小值以減少誤差。

3.3 Pacer

pacer的發(fā)送機(jī)制基于BDP發(fā)送數(shù)據(jù)和pacing rate發(fā)送數(shù)據(jù)，如果發(fā)送數(shù)據(jù)已經(jīng)超過了BDP的吞吐量，此時(shí)pacer不會再向外發(fā)送數(shù)據(jù)加重網(wǎng)絡(luò)擁塞，pacing是間隔5毫秒的間隔發(fā)送，pacing rate是基于5毫秒發(fā)送的數(shù)據(jù)量，基于這兩個(gè)條件就可以構(gòu)建出定時(shí)發(fā)送的pacer。

在探測最高帶寬時(shí)，使用pacer的padding來滿足BBR的probe_bw狀態(tài)最大帶寬探測要求。

3.4 AIMD碼率決策

BBR是及時(shí)發(fā)送的碼率而不是編碼器需要采用的碼率，這樣會導(dǎo)致網(wǎng)絡(luò)擁塞問題更加復(fù)雜，因此設(shè)計(jì)了AIMD碼率決策來控制video碼率的機(jī)制。如果BDP<infight_size時(shí)，需要把視頻碼率降到比較低的位置，這樣擁塞很快就可以緩解，如果BDP>infight_size時(shí)，并不會采用即時(shí)碼率而是用和式加來對碼率進(jìn)行控制，通過添加一個(gè)固定倍數(shù)碼率來平滑地控制整個(gè)運(yùn)作的反饋機(jī)制，避免網(wǎng)絡(luò)惡化。

3.5 擁塞控制與QoS

?

QoS和擁塞控制是兩個(gè)概念，QoS是在擁塞控制的范疇之下進(jìn)行的，碼率和擁塞控制的窗口大小會制約QoS的行為。FEC/NACK之間是制約關(guān)系，所以一定要基于決策碼率來做。

3.6 BBR與GCC比較

?

上圖中可以明顯看到BBR在網(wǎng)絡(luò)限速的情況下表現(xiàn)要比GCC良好一些，不會有大幅度的網(wǎng)絡(luò)抖動和衰減。

3.7 多路競爭測試

?

上圖是關(guān)于BBR多路競爭的測試，測試過程是在300kBps的帶寬下分時(shí)間段引入三路BBR數(shù)據(jù)流，最終觀察發(fā)送碼率是否是平均分配的。

4. 總結(jié)

BBR的比較豪放激進(jìn)，具有不容易被其他應(yīng)用搶占帶寬、碼率調(diào)節(jié)實(shí)時(shí)性高，能很好應(yīng)對網(wǎng)絡(luò)變化、可以對應(yīng)各種類型的網(wǎng)絡(luò)丟包和技術(shù)成熟等優(yōu)勢。

但BBR的不足也表現(xiàn)在，評估最小RTT時(shí)會減小窗口，這樣會使發(fā)送碼率下降，極端情況下會使實(shí)時(shí)視頻瞬間質(zhì)量變差。BBR在誕生之初并不是用做小帶寬傳輸，因此在小碼率視頻傳輸過程中，BBR的效果并不明顯。最重要的問題還有padding計(jì)算流量不經(jīng)濟(jì)實(shí)用，需要在使用過程中重點(diǎn)考量。BBR所有的帶寬統(tǒng)計(jì)和實(shí)效性都是基于RTT，如果RTT過大會導(dǎo)致帶寬的條件不太平滑。

?

源碼實(shí)現(xiàn)：https://github.com/yuanrongxi/razor

更多精彩內(nèi)容：人物專訪（行業(yè)趨勢解讀）、LiveVideoStackCon 大會演講內(nèi)容回顧及線上分享內(nèi)容回顧（+線上分享PPT資料下載），=>>點(diǎn)擊【閱讀原文】！

總結(jié)

以上是生活随笔為你收集整理的实时视频传输中的BBR拥塞控制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。