疫情將遠程辦公，視頻會議推上了風口的同時，同樣也為視頻會議平臺的運作帶來了更多的挑戰。藍貓微會創始人兼CEO 鄧昀澤在LiveVideoStack線上分享中針對視頻會議系統優化中弱網定義，算法評估及技術實現等細節進行了詳細解析。

?

文 / 鄧昀澤

整理 / LiveVideoStack

視頻回放

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

大家好，我是藍貓微會的創始人兼CEO 鄧昀澤，本次我分享的主題是：視頻會議場景下的弱網優化，下面我將從以下三個方面展開本次分享的全部內容：

弱網的定義

評估算法

傳輸優化

?

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

弱網定義

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

?

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

?

接下來我們按照帶寬資源分情況討論：

●????100kb網絡

100k的帶寬可以被定義為很差的網絡環境，在該網絡環境下基本無法實現視頻會議。該網絡環境更多地出現在老舊小區的電梯間或地鐵車廂當中，此時我們作為視頻會議解決方案的提供方，會檢測到該場景并建議客戶改用語音模式進行會議溝通。

?

●????300kb網絡

?

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

?

●????600kb網絡

600kb的網絡代表很多公司的正常網絡環境。大量位于密集寫字樓，軟件園區等位置的中小型公司，缺乏專業IT，雖然字面上帶寬不低，但是時間帶寬非常有限。

?

600kb的另外一個典型場景是夜間網絡使用高峰期時的小區帶寬。此時大家都打開了互聯網電視或者使用聯網設備時，整個帶寬便僅有600kb左右。根據我們的統計我們認為，擁有600kb穩定帶寬的用戶，可能會占到總用量的40%左右。

?

●????1000kb

?

如果身處現代化的正規寫字樓，或是企業擁有正規的辦公網絡與專業的IT運維團隊，那么1M的帶寬還是不難實現的，這種網絡環境屬于正常網絡，可以支撐720P的流暢視頻會議，不屬于弱網的定義范圍。

?

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

評估算法

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

?

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

?

如果是延遲呢？

?

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

累計評估

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

?

GCC

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

?

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

?

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

?

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

?

在這里我們對網絡評估算法有了大致的了解，其實視頻會議本身的環節更加復雜。

傳輸優化

我們主要從兩個方面建立對傳輸的優化：控制流量與充分利用流量。首先，帶寬資源有限，主播端與客戶端的網絡環境可能存在天壤之別，也許主播端擁有10Mb的上行帶寬而客戶端所在的弱網環境導致其僅擁有600kb的下行網絡帶寬，為了應對這種情況我們需要建立有效的流量控制，也就是通過SVC或動態碼流來實現。

?

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

?

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

?

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

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

?

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

?

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

?

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

?

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

?

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

?

除了以上介紹的內容，我們也會根據視頻會議的具體場景進行動態碼流方面的優化。例如在1對1視頻會議場景下，用戶希望追求更好的視頻質量。我們就會根據雙方的網絡狀況，不斷調整分辨率，動態調控分配策略。

?

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

?

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

LiveVideoStackCon 2020

上海/北京/舊金山 講師招募

2020年LiveVideoStackCon將持續迭代，LiveVideoStackCon將分別在上海（6月13-14日），北京（9月11-12日）和舊金山（11月）舉行。歡迎將你的技術實踐、踩坑與填坑經歷、技術與商業創業的思考分享出來，獨樂不如眾樂。請將個人資料和話題信息郵件到 speaker@livevideostack.com 或點擊【閱讀原文】了解成為LiveVideoStackCon講師的權益與義務，我們會在48小時內回復。

總結

以上是生活随笔為你收集整理的视频会议场景下的弱网优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。