https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=2bf0147fa84c44a9b6a5d448669f16c0

　　大家好，我是藍(lán)貓微會的創(chuàng)始人兼CEO 鄧昀澤，本次我分享的主題是：視頻會議場景下的弱網(wǎng)優(yōu)化，下面我將從以下三個(gè)方面展開本次分享的全部內(nèi)容：

　　要探究視頻會議在弱網(wǎng)場景的優(yōu)化，需要首先從場景化與數(shù)字化角度對弱網(wǎng)進(jìn)行準(zhǔn)確的定義，這樣在處理相關(guān)問題時(shí)才能得出一些具有針對性的解決方案。接下來就需要評估并優(yōu)化算法，結(jié)合場景與數(shù)字化的方式驗(yàn)證優(yōu)化方法的可行性、有效性。算法優(yōu)化永遠(yuǎn)是在各場景之間尋求一種平衡，不同場景對參數(shù)的選擇是不同的。如果沒有一個(gè)場景化的評估標(biāo)準(zhǔn)，那么針對不同場景的算法優(yōu)化容易導(dǎo)致一個(gè)場景有效，另外場景惡化。因此弱網(wǎng)的定義與評估至關(guān)重要。在針對性地分析并得出優(yōu)化算法之后，我們需要根據(jù)整個(gè)過程的效果評估不同場景下的算法選型。

　　首先我們需要明確弱網(wǎng)的定義，我們從兩個(gè)維度進(jìn)行定義：丟包率與帶寬限制。丟包率在多少以下代表網(wǎng)絡(luò)可用？網(wǎng)絡(luò)帶寬究竟達(dá)到多少代表該網(wǎng)絡(luò)可穩(wěn)定運(yùn)行？只有在丟包和帶寬都處于可接受范圍內(nèi)時(shí)，該網(wǎng)絡(luò)才不算弱網(wǎng)。如果任何一個(gè)維度的指標(biāo)出現(xiàn)異常，例如丟包率過高或者帶寬限制明顯，就可將其視為一種弱網(wǎng)環(huán)境。

　　在音視頻這個(gè)對網(wǎng)絡(luò)延遲十分敏感的應(yīng)用場景當(dāng)中，弱網(wǎng)是普遍存在的。例如在像網(wǎng)吧這樣的環(huán)境中，下載一個(gè)文件網(wǎng)絡(luò)帶寬可以達(dá)到2～3M。但網(wǎng)絡(luò)的抖動非常嚴(yán)重，不能滿足音視頻穩(wěn)定傳輸?shù)男枨螅�這種波動明顯的網(wǎng)絡(luò)環(huán)境在音視頻領(lǐng)域也會被稱為弱網(wǎng)。所以音視頻領(lǐng)域?qū)θ蹙W(wǎng)的定義和一般互聯(lián)網(wǎng)中對弱網(wǎng)的定義存在一定區(qū)別，音視頻對弱網(wǎng)的定義需要建立在相對可控的丟包率和延遲均衡的基礎(chǔ)上。

　　100k的帶寬可以被定義為很差的網(wǎng)絡(luò)環(huán)境，在該網(wǎng)絡(luò)環(huán)境下基本無法實(shí)現(xiàn)視頻會議。該網(wǎng)絡(luò)環(huán)境更多地出現(xiàn)在老舊小區(qū)的電梯間或地鐵車廂當(dāng)中，此時(shí)我們作為視頻會議解決方案的提供方，會檢測到該場景并建議客戶改用語音模式進(jìn)行會議溝通。

　　300kb的網(wǎng)絡(luò)環(huán)境比較典型，例如使用家庭無線網(wǎng)絡(luò)同時(shí)進(jìn)行互聯(lián)網(wǎng)實(shí)時(shí)游戲與音視頻會議，此時(shí)便會出現(xiàn)音視頻會議體驗(yàn)不佳的情況；在公共場合例如高鐵或人流密集的車站當(dāng)中；人數(shù)相對密集的星巴克。300K的網(wǎng)絡(luò)勉強(qiáng)可以支撐視240P的視頻會議，但是如果視頻會議系統(tǒng)自適應(yīng)算法沒做好，沒控制好碼流，那么持續(xù)的網(wǎng)絡(luò)抖動會使得畫面分辨率在清晰與模糊之間不斷變化。優(yōu)化出色的算法可以讓300kb的網(wǎng)絡(luò)承載320p甚至是480p的視頻會議；而優(yōu)化不佳的算法則會讓視頻出現(xiàn)持續(xù)的卡頓和分辨率抖動。

　　600kb的網(wǎng)絡(luò)代表很多公司的正常網(wǎng)絡(luò)環(huán)境。大量位于密集寫字樓，軟件園區(qū)等位置的中小型公司，缺乏專業(yè)IT，雖然字面上帶寬不低，但是時(shí)間帶寬非常有限。

　　600kb的另外一個(gè)典型場景是夜間網(wǎng)絡(luò)使用高峰期時(shí)的小區(qū)帶寬。此時(shí)大家都打開了互聯(lián)網(wǎng)電視或者使用聯(lián)網(wǎng)設(shè)備時(shí)，整個(gè)帶寬便僅有600kb左右。根據(jù)我們的統(tǒng)計(jì)我們認(rèn)為，擁有600kb穩(wěn)定帶寬的用戶，可能會占到總用量的40%左右。

　　如果身處現(xiàn)代化的正規(guī)寫字樓，或是企業(yè)擁有正規(guī)的辦公網(wǎng)絡(luò)與專業(yè)的IT運(yùn)維團(tuán)隊(duì)，那么1M的帶寬還是不難實(shí)現(xiàn)的，這種網(wǎng)絡(luò)環(huán)境屬于正常網(wǎng)絡(luò)，可以支撐720P的流暢視頻會議，不屬于弱網(wǎng)的定義范圍。

　　從弱網(wǎng)的定義上來說，我們將網(wǎng)絡(luò)與視頻會議的應(yīng)用總結(jié)為以下三檔：網(wǎng)絡(luò)帶寬為300kb，算法優(yōu)化可以使得視頻會議流暢在低清進(jìn)行；網(wǎng)絡(luò)帶寬為600kb，則480p左右的視頻會議可流暢進(jìn)行；若需追求720p或更高清的視頻會議體驗(yàn)，那么還需進(jìn)一步提升弱網(wǎng)算法優(yōu)化網(wǎng)絡(luò)環(huán)境。

　　在明確弱網(wǎng)的分類之后，我們需要一個(gè)高質(zhì)量算法，以根據(jù)丟包、延遲等指標(biāo)準(zhǔn)確評估網(wǎng)絡(luò)并為用戶選擇合適的分辨率或是否繼續(xù)進(jìn)行視頻會議。檢測的算法非常重要，因?yàn)樗惴�決定了發(fā)送流量與客戶能否正常接收并成功播放。

　　大家可以在公開資料上查到許多評估算法的開源標(biāo)準(zhǔn)，如Google的流量控制算法GCC以及TCP標(biāo)準(zhǔn)算法BBR等。從算法指標(biāo)來看：丟包率在2%以內(nèi)的網(wǎng)絡(luò)可被視為質(zhì)量不錯，丟包率為4%~6%則屬于正常網(wǎng)絡(luò)，丟包率大于10%則網(wǎng)絡(luò)環(huán)境較差，20%則意味著網(wǎng)絡(luò)環(huán)境非常糟糕。

　　這里我們談到的延遲并不是指RTP從發(fā)送端發(fā)送到接收端接收（服務(wù)端到客戶端）之間的時(shí)間，例如新疆的用戶到北京的服務(wù)器需要120毫秒，北京的用戶到北京的服務(wù)器則可能需要10毫秒。本次所討論的延遲是：假設(shè)客戶端向服務(wù)器發(fā)100個(gè)同樣的數(shù)據(jù)包，發(fā)端共耗時(shí)100毫秒；如果服務(wù)器沒有延遲、路由器沒有阻塞，則服務(wù)器收到這些包的時(shí)間也是100毫秒；但如果客戶端發(fā)送100個(gè)數(shù)據(jù)包花費(fèi)100毫秒而服務(wù)器接收這100個(gè)數(shù)據(jù)包用了200毫秒，說明發(fā)包的速度被卡住了。一般來說，出現(xiàn)這種情況不是由于服務(wù)器流量卡住而是客戶端本地路由器流量卡住，例如家用網(wǎng)絡(luò)游戲或小區(qū)寬帶的路由器限速等。當(dāng)然，發(fā)包耗時(shí)100毫秒但是接收端只用了80毫秒的情況一般不可能出現(xiàn)。因此，這里的延遲是指發(fā)端發(fā)送所需時(shí)間與收端接收所需時(shí)間之差，一般情況下服務(wù)器會將該數(shù)據(jù)反饋給客戶端，客戶端根據(jù)指標(biāo)判斷網(wǎng)絡(luò)環(huán)境是否已經(jīng)達(dá)到了穩(wěn)定承載服務(wù)所要求的上限。

　　因?yàn)閬G包與延遲只能幫助我們進(jìn)行一個(gè)瞬間的評估，例如第一次客戶端在200毫秒之內(nèi)向服務(wù)器傳輸100個(gè)包，隨后得到來自服務(wù)器的反饋；第二次客戶端發(fā)送100個(gè)數(shù)據(jù)包可能就需要300毫秒——網(wǎng)絡(luò)在細(xì)節(jié)上的抖動非常之大，尤其是在一些并不那么穩(wěn)定的網(wǎng)絡(luò)當(dāng)中。如果我們僅將某一固定指標(biāo)作為評估依據(jù)，顯然是不科學(xué)的。我們需要積累所有瞬間狀態(tài)并推斷出連續(xù)的網(wǎng)絡(luò)狀況，才能實(shí)現(xiàn)相對可靠的評估。

　　GCC全稱為Google Congestion Control 擁塞控制算法。上圖大致展示了GCC的運(yùn)行過程，其中有兩個(gè)核心數(shù)據(jù)包：SR（SendReport）表示發(fā)送端（客戶端）上報(bào)，RR（Receive Report）接收端（服務(wù)端）上報(bào)。其中的時(shí)間表示了發(fā)送一個(gè)數(shù)據(jù)包需要多長時(shí)間對端才能接收以及其他一些數(shù)據(jù)標(biāo)準(zhǔn)。以上圖展示的為例：首先客戶端向服務(wù)器發(fā)送15個(gè)包，數(shù)據(jù)區(qū)間是100-115，發(fā)送之后客戶端告訴服務(wù)端數(shù)據(jù)包已發(fā)送，同時(shí)服務(wù)端接收到數(shù)據(jù)包之后就會去檢測區(qū)間100-115的數(shù)據(jù)是否接收完整，有多少包在傳輸過程中丟失。

　　除此之外，服務(wù)端也會統(tǒng)計(jì)收到這些數(shù)據(jù)包所花費(fèi)的時(shí)間并將其作為RR發(fā)送給客戶端，緊接著客戶端持續(xù)不停地發(fā)SR，服務(wù)端也會不斷地反饋 RR……客戶端可基于此對網(wǎng)絡(luò)進(jìn)行精準(zhǔn)評估并得出相應(yīng)丟包率，以及統(tǒng)計(jì)發(fā)送這些數(shù)據(jù)包的開始與結(jié)束的時(shí)間并得出DLSR，就能知道該數(shù)據(jù)包發(fā)送過程是否存在明顯的延遲。通過兩個(gè)數(shù)據(jù)包之間來回的交互，統(tǒng)計(jì)之間的丟包率和延遲，我們就能夠?qū)�網(wǎng)絡(luò)質(zhì)量有一個(gè)相對可靠的評估。

　　例如現(xiàn)在有一個(gè)限速600kb的網(wǎng)絡(luò)，而一個(gè)480p的視頻會議需要帶寬在300~800kb。如果我們將該視頻會議服務(wù)建立在600kb的網(wǎng)絡(luò)之下，客戶端首先會傳輸500kb，服務(wù)器反饋丟包率很低并且延遲也在可接受范圍之內(nèi)，此時(shí)客戶端便知道該網(wǎng)絡(luò)環(huán)境尚可，可以持續(xù)向上提升比特率；當(dāng)比特率提升至所需帶寬達(dá)到550kb時(shí)，客戶端評估網(wǎng)絡(luò)仍然能夠接受；當(dāng)比特率提升至所需帶寬達(dá)到600kb時(shí)，服務(wù)端偵測到1%的丟包但延遲卻沒有太大變化，視頻會議服務(wù)還沒有超過帶寬的限制，此時(shí)服務(wù)端將該信息反饋給客戶端，如果客戶端的評估算法足夠精準(zhǔn)，那么客戶端就不會再繼續(xù)提升比特率，從而控制丟包率與延遲在合理區(qū)間內(nèi)；但如果評估算法不夠精確，那么客戶端可能會繼續(xù)提升所需帶寬至610kb、620kb，這會進(jìn)一步提升丟包與延遲，此時(shí)網(wǎng)絡(luò)環(huán)境便會呈現(xiàn)非常糟糕的狀態(tài)�？蛻舳藨�(yīng)該做的是快速降低比特率，使得網(wǎng)關(guān)能夠很快處理完上一次積壓的數(shù)據(jù)，整個(gè)傳輸在經(jīng)歷一個(gè)小范圍抖動之后恢復(fù)正常；如果在播放器端添加緩沖，那么該抖動可被抹平并達(dá)到平穩(wěn)流暢的播放狀態(tài)。

　　GCC算法的核心是SR與RR——通過二者持續(xù)的交互將整個(gè)網(wǎng)絡(luò)的丟包與延遲清晰地呈現(xiàn)給系統(tǒng)；在匯總這些數(shù)據(jù)之后，得出一個(gè)網(wǎng)絡(luò)質(zhì)量評估的標(biāo)準(zhǔn)。隨后客戶端就要通過該網(wǎng)絡(luò)評估標(biāo)準(zhǔn)來決定應(yīng)該使用多大的帶寬與服務(wù)器和其他的客戶端進(jìn)行數(shù)據(jù)交互。

　　在這里我們對網(wǎng)絡(luò)評估算法有了大致的了解，其實(shí)視頻會議本身的環(huán)節(jié)更加復(fù)雜。

　　我們主要從兩個(gè)方面建立對傳輸?shù)膬?yōu)化：控制流量與充分利用流量。首先，帶寬資源有限，主播端與客戶端的網(wǎng)絡(luò)環(huán)境可能存在天壤之別，也許主播端擁有10Mb的上行帶寬而客戶端所在的弱網(wǎng)環(huán)境導(dǎo)致其僅擁有600kb的下行網(wǎng)絡(luò)帶寬，為了應(yīng)對這種情況我們需要建立有效的流量控制，也就是通過SVC或動態(tài)碼流來實(shí)現(xiàn)。

　　SVC是可伸縮視頻編碼技術(shù)，其原理是將視頻信號編碼為一組圖層，各層互相依賴形成一個(gè)層次結(jié)構(gòu)，特定層及其所依賴的層提供了以特定的保真度解碼視頻信號時(shí)所必需的信息。例如我們將視頻分為多個(gè)部分：一部分的數(shù)據(jù)包用于240p，一部分?jǐn)?shù)據(jù)包用于480p或者是對480p的細(xì)節(jié)補(bǔ)充編碼數(shù)據(jù)，還有一部分是對720p的細(xì)節(jié)補(bǔ)充編碼數(shù)據(jù)。主播方會把240p、480p的補(bǔ)充數(shù)據(jù)與720p的補(bǔ)充數(shù)據(jù)都發(fā)出去，接收方則根據(jù)網(wǎng)絡(luò)環(huán)境選擇合適的數(shù)據(jù)包。若網(wǎng)絡(luò)狀況良好則選取720p，若網(wǎng)絡(luò)狀況不佳則選擇480p甚至240p。這樣的話無論網(wǎng)絡(luò)環(huán)境如何變化客戶端都可以流暢播放，改變的只是畫面清晰度。

　　無論是對H.265還是VP9而言，SVC的算法復(fù)雜度都較高，其實(shí)H.264同樣支持SVC，但我們希望尋求復(fù)雜度更低的算法。

　　于是我們可以采取大小流模式，例如有些客戶需要480p，另一些客戶需要720p，那么發(fā)端便可針對240p、480p、720p發(fā)兩路或者三路，且不會相互干擾。

　　另一種解決方案是動態(tài)碼流。我們無法按照自己的網(wǎng)絡(luò)帶寬決定所需傳輸指標(biāo)，而是按照客戶的帶寬需求決定上線什么樣的服務(wù)。例如在一對一情況下，如果客戶擁有高性能終端與高質(zhì)量傳輸網(wǎng)絡(luò)，可能會提出4k的需求；此時(shí)我們便會在現(xiàn)有網(wǎng)絡(luò)條件的基礎(chǔ)之上不斷提升分辨率，從而支持客戶的網(wǎng)絡(luò)帶寬訴求。如果客戶將終端換成手機(jī)等一般設(shè)備，可能僅支持240p，那么我們就會按照240p的需求調(diào)整傳輸。當(dāng)然，SVC和動態(tài)碼流實(shí)際上是相互配合的，對于傳輸有顯著的優(yōu)化效果。

　　除此之外，我們也會通過一些算法補(bǔ)充，盡可能充分地利用現(xiàn)有流量。例如在600kb的網(wǎng)絡(luò)帶寬下丟包率較低而延遲可控，那么通過一些高質(zhì)量算法我可以把600kb的上限提升到800～900kb的水平，其優(yōu)化效果也顯而易見。比如典型的方法是FEC與ARQ。

　　FEC最初來源于光纖層面的算法優(yōu)化，例如這里我需要傳輸10個(gè)數(shù)據(jù)包，一旦出現(xiàn)一個(gè)包丟失的情況，接收端會重新尋求該包，這其中就有一個(gè)包的損失。因此FEC采取了一個(gè)補(bǔ)償方法，若需發(fā)送10個(gè)數(shù)據(jù)包，則發(fā)送端會多發(fā)一個(gè)數(shù)據(jù)包，該數(shù)據(jù)包根據(jù)前面10個(gè)數(shù)據(jù)包通過FEC算法算出，接收端實(shí)際上只需成功接收到11個(gè)包中任意10個(gè)包即可把原數(shù)據(jù)流重新組裝出來。在這種模式下如果控制丟包率在10%以下，實(shí)際上是不需要做任何重傳請求的，因此丟包率在10%以下的延遲基本上沒有什么影響。當(dāng)然這里存在一個(gè)10%的額外帶寬消耗，如果在一些網(wǎng)絡(luò)下丟包率較高而帶寬沒有問題的話，那么FEC會把丟包重傳帶來的損失降低，繼而把延遲損失降低到最小。

　　ARQ則是接收端在偵測到丟包時(shí)自動發(fā)送重傳請求，例如發(fā)送端發(fā)送十個(gè)數(shù)據(jù)包：1、2、3、4、5、6、7、8、9、10；而接收端在依次收到1、2、3、4、5、6、8、10后未收到7、9，隨后接收端會向發(fā)送端發(fā)送一個(gè)重傳請求，請求發(fā)送端再次發(fā)送7與9，隨后發(fā)送端會重新打包7和9并發(fā)送到對端。ARQ是一個(gè)很常見的重傳算法，該重傳算法也存在連續(xù)型ARQ與不連續(xù)型ARQ，ARQ與FEC可以相互配合。如果網(wǎng)絡(luò)帶寬不錯但延遲比較明顯，我們會優(yōu)先使用FEC，且控制丟包率在20%以內(nèi)；如果丟包率超過20%，使用FEC會額外消耗更多的帶寬，繼而導(dǎo)致整個(gè)傳輸鏈路的持續(xù)惡化。一般情況下在丟包率超過20%，甚至達(dá)到10%時(shí)， 控制降低FEC算法的權(quán)重，并進(jìn)一步使用ARQ能夠帶來更加出色的優(yōu)化效果。

　　除了FEC與ARQ，還有一種被稱為PacedSender的算法。在視頻通信中，傳輸存在峰值與低谷，單幀視頻可能有上百KB，我們知道視頻當(dāng)中存在I幀與B幀，一般情況下I幀出現(xiàn)時(shí)，代表著達(dá)到一個(gè)流量高峰；而B幀則是一個(gè)很小的片段，這就造成整個(gè)傳輸?shù)亩秳臃浅��?yán)重。如果是當(dāng)視頻幀被編碼器編碼出來后，就立即進(jìn)行打包發(fā)送，瞬間會發(fā)送大量的數(shù)據(jù)到網(wǎng)絡(luò)上，這可能會引起網(wǎng)絡(luò)衰減和通信惡化。WebRTC引入pacer，pacer會根據(jù)estimator評估出來的碼率，按照最小單位時(shí)間（5ms）做時(shí)間分片進(jìn)行遞進(jìn)發(fā)送數(shù)據(jù)，避免瞬時(shí)對網(wǎng)絡(luò)的沖擊。pacer的目的就是讓視頻數(shù)據(jù)按照評估碼率均勻的分布在各個(gè)時(shí)間片里發(fā)送，所以在弱網(wǎng)的WiFi環(huán)境，pacer是個(gè)非常重要的步驟，其可通過拉長時(shí)間，使得整個(gè)發(fā)送的抖動情況趨于平緩。

　　以上三個(gè)算法可有效提升弱網(wǎng)環(huán)境下的傳輸效率并降低丟包率。也許有些人會提到SRT，SRT不是一個(gè)算法而是一個(gè)開源的包，實(shí)際上是內(nèi)置了FEC、ARQ等算法，通過UDP+FEC+ARQ來模擬TCP的算法。TCP嚴(yán)格遵循質(zhì)量優(yōu)先策略，不允許丟失任何一個(gè)數(shù)據(jù)幀，一旦丟包超過限度就會中斷鏈路，而這對音視頻的應(yīng)用場景來說有些過于嚴(yán)苛。相對而言，基于UDP的SRT則更加適合音視頻應(yīng)用場景。我們知道最近業(yè)界有不少公司都開始測試 SRT算法，目前來看效果還是非常不錯的。

　　除了以上介紹的內(nèi)容，我們也會根據(jù)視頻會議的具體場景進(jìn)行動態(tài)碼流方面的優(yōu)化。例如在1對1視頻會議場景下，用戶希望追求更好的視頻質(zhì)量。我們就會根據(jù)雙方的網(wǎng)絡(luò)狀況，不斷調(diào)整分辨率，動態(tài)調(diào)控分配策略。

　　一旦加入視頻會議的人數(shù)越來越多，甚至達(dá)到一二百人，由于用戶所處網(wǎng)絡(luò)環(huán)境是千差萬別的，因此很難完美滿足所有人的需求。在此情況下，我們可以提供給網(wǎng)絡(luò)非常差的用戶480p的流而給網(wǎng)絡(luò)環(huán)境出色的用戶最高720p的流，根據(jù)用戶的數(shù)目進(jìn)行優(yōu)化和調(diào)整，以使服務(wù)盡量符合大多數(shù)人的利益與需求。

　　以常見的1對1授課為例，該場景下主播端會傳出兩路流：主播與PPT，此時(shí)為了保證傳輸?shù)姆�(wěn)定可靠，我們會適當(dāng)降低主播視頻畫面分辨率并提升PPT的分辨率，以使得用戶能夠更加清晰地觀看PPT內(nèi)容。綜合考慮各方因素并根據(jù)場景進(jìn)行優(yōu)化，我們希望盡量讓視頻會議的比特率與帶寬占用能夠達(dá)到相對比較好的水平，以保證盡可能多的用戶享受到清晰流暢、不卡頓的音視頻服務(wù)。