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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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