聲明：本文轉載自——藍貓微會創(chuàng)始人兼CEO 鄧昀澤在LiveVideoStack線上分享鲸睛，原文鏈接：https://mp.weixin.qq.com/s/zCVi2Q6BAZTtzMIeytD8XA

視頻會議場景下的弱網(wǎng)優(yōu)化，下面我將從以下三個方面展開本次分享的全部內容：

1坡贺、弱網(wǎng)的定義

2官辈、評估算法

3、傳輸優(yōu)化

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

1、弱網(wǎng)的定義：

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

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

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

●????100kb網(wǎng)絡

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

●????300kb網(wǎng)絡

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

●????600kb網(wǎng)絡

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

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

●????1000kb網(wǎng)絡

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

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

2涎拉、評估算法

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

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

如果是延遲呢消痛？

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

累計評估

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

GCC

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

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

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

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

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

3、傳輸優(yōu)化

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

SVC是可伸縮視頻編碼技術锋喜，其原理是將視頻信號編碼為一組圖層，各層互相依賴形成一個層次結構豌鸡，特定層及其所依賴的層提供了以特定的保真度解碼視頻信號時所必需的信息嘿般。例如我們將視頻分為多個部分：一部分的數(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)絡環(huán)境選擇合適的數(shù)據(jù)包瞻赶。若網(wǎng)絡狀況良好則選取720p赛糟，若網(wǎng)絡狀況不佳則選擇480p甚至240p。這樣的話無論網(wǎng)絡環(huán)境如何變化客戶端都可以流暢播放砸逊，改變的只是畫面清晰度虑灰。

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

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

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

除此之外伞芹，我們也會通過一些算法補充忘苛，盡可能充分地利用現(xiàn)有流量。例如在600kb的網(wǎng)絡帶寬下丟包率較低而延遲可控丑瞧，那么通過一些高質量算法我可以把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%以下的延遲基本上沒有什么影響尽纽。當然這里存在一個10%的額外帶寬消耗，如果在一些網(wǎng)絡下丟包率較高而帶寬沒有問題的話童漩，那么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)絡帶寬不錯但延遲比較明顯饵沧，我們會優(yōu)先使用FEC，且控制丟包率在20%以內赌躺；如果丟包率超過20%狼牺，使用FEC會額外消耗更多的帶寬，繼而導致整個傳輸鏈路的持續(xù)惡化礼患。一般情況下在丟包率超過20%是钥，甚至達到10%時， 控制降低FEC算法的權重缅叠，并進一步使用ARQ能夠帶來更加出色的優(yōu)化效果咏瑟。

除了FEC與ARQ，還有一種被稱為PacedSender的算法痪署。在視頻通信中码泞，傳輸存在峰值與低谷，單幀視頻可能有上百KB狼犯，我們知道視頻當中存在I幀與B幀余寥，一般情況下I幀出現(xiàn)時，代表著達到一個流量高峰悯森；而B幀則是一個很小的片段宋舷，這就造成整個傳輸?shù)亩秳臃浅乐亍Ｈ绻钱斠曨l幀被編碼器編碼出來后绎狭，就立即進行打包發(fā)送，瞬間會發(fā)送大量的數(shù)據(jù)到網(wǎng)絡上蹦狂，這可能會引起網(wǎng)絡衰減和通信惡化朋贬。WebRTC引入pacer，pacer會根據(jù)estimator評估出來的碼率锦募，按照最小單位時間（5ms）做時間分片進行遞進發(fā)送數(shù)據(jù)御滩，避免瞬時對網(wǎng)絡的沖擊富弦。pacer的目的就是讓視頻數(shù)據(jù)按照評估碼率均勻的分布在各個時間片里發(fā)送，所以在弱網(wǎng)的WiFi環(huán)境，pacer是個非常重要的步驟蓖扑，其可通過拉長時間唉铜，使得整個發(fā)送的抖動情況趨于平緩。

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

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

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

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