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

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

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

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

　　在音視頻這個對網(wǎng)絡(luò)延遲十分敏感的應(yīng)用場景當(dāng)中，弱網(wǎng)是普遍存在的。例如在像網(wǎng)吧這樣的環(huán)境中，下載一個文件網(wǎng)絡(luò)帶寬可以達到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)境下基本無法實現(xiàn)視頻會議。該網(wǎng)絡(luò)環(huán)境更多地出現(xiàn)在老舊小區(qū)的電梯間或地鐵車廂當(dāng)中，此時我們作為視頻會議解決方案的提供方，會檢測到該場景并建議客戶改用語音模式進行會議溝通。

　　300kb的網(wǎng)絡(luò)環(huán)境比較典型，例如使用家庭無線網(wǎng)絡(luò)同時進行互聯(lián)網(wǎng)實時游戲與音視頻會議，此時便會出現(xiàn)音視頻會議體驗不佳的情況；在公共場合例如高鐵或人流密集的車站當(dāng)中；人數(shù)相對密集的星巴克。300K的網(wǎng)絡(luò)勉強可以支撐視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，雖然字面上帶寬不低，但是時間帶寬非常有限。

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

　　如果身處現(xiàn)代化的正規(guī)寫字樓，或是企業(yè)擁有正規(guī)的辦公網(wǎng)絡(luò)與專業(yè)的IT運維團隊，那么1M的帶寬還是不難實現(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)化可以使得視頻會議流暢在低清進行；網(wǎng)絡(luò)帶寬為600kb，則480p左右的視頻會議可流暢進行；若需追求720p或更高清的視頻會議體驗，那么還需進一步提升弱網(wǎng)算法優(yōu)化網(wǎng)絡(luò)環(huán)境。

　　在明確弱網(wǎng)的分類之后，我們需要一個高質(zhì)量算法，以根據(jù)丟包、延遲等指標(biāo)準(zhǔn)確評估網(wǎng)絡(luò)并為用戶選擇合適的分辨率或是否繼續(xù)進行視頻會議。檢測的算法非常重要，因為算法決定了發(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ù)端到客戶端）之間的時間，例如新疆的用戶到北京的服務(wù)器需要120毫秒，北京的用戶到北京的服務(wù)器則可能需要10毫秒。本次所討論的延遲是：假設(shè)客戶端向服務(wù)器發(fā)100個同樣的數(shù)據(jù)包，發(fā)端共耗時100毫秒；如果服務(wù)器沒有延遲、路由器沒有阻塞，則服務(wù)器收到這些包的時間也是100毫秒；但如果客戶端發(fā)送100個數(shù)據(jù)包花費100毫秒而服務(wù)器接收這100個數(shù)據(jù)包用了200毫秒，說明發(fā)包的速度被卡住了。一般來說，出現(xiàn)這種情況不是由于服務(wù)器流量卡住而是客戶端本地路由器流量卡住，例如家用網(wǎng)絡(luò)游戲或小區(qū)寬帶的路由器限速等。當(dāng)然，發(fā)包耗時100毫秒但是接收端只用了80毫秒的情況一般不可能出現(xiàn)。因此，這里的延遲是指發(fā)端發(fā)送所需時間與收端接收所需時間之差，一般情況下服務(wù)器會將該數(shù)據(jù)反饋給客戶端，客戶端根據(jù)指標(biāo)判斷網(wǎng)絡(luò)環(huán)境是否已經(jīng)達到了穩(wěn)定承載服務(wù)所要求的上限。

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

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

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

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

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

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

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

　　SVC是可伸縮視頻編碼技術(shù)，其原理是將視頻信號編碼為一組圖層，各層互相依賴形成一個層次結(jié)構(gòu)，特定層及其所依賴的層提供了以特定的保真度解碼視頻信號時所必需的信息。例如我們將視頻分為多個部分：一部分的數(shù)據(jù)包用于240p，一部分數(shù)據(jù)包用于480p或者是對480p的細節(jié)補充編碼數(shù)據(jù)，還有一部分是對720p的細節(jié)補充編碼數(shù)據(jù)。主播方會把240p、480p的補充數(shù)據(jù)與720p的補充數(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ù)雜度都較高，其實H.264同樣支持SVC，但我們希望尋求復(fù)雜度更低的算法。

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

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

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

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

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

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

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

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

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

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