背景介紹

實(shi)時(shi)音(yin)視(shi)頻通(tong)(tong)話在當前(qian)的生活中是無時(shi)不刻存在的，包(bao)括社交、安防、交通(tong)(tong)等(deng)等(deng)各(ge)個方面都需要。用戶場景復(fu)雜多(duo)變(bian)、要求嚴(yan)苛、網絡環境不一(yi)致(zhi)等(deng)給實(shi)時(shi)音(yin)視(shi)頻通(tong)(tong)話帶來很大(da)(da)條件。我們(men)在這(zhe)方向(xiang)稍微做了(le)一(yi)些工作(zuo)，雖然和(he)其(qi)他大(da)(da)廠的優化工作(zuo)相比，我們(men)還處于劣勢(shi)，還有(you)很多(duo)可以優化和(he)改進(jin)(jin)的，但是目前(qian)的一(yi)些進(jin)(jin)展和(he)工作(zuo)內容(rong)和(he)大(da)(da)家分享一(yi)下。

0.1 網絡傳輸：

我們知道網(wang)(wang)絡(luo)(luo)傳(chuan)輸(shu)目前(qian)有 TCP 和 UDP 兩種，相(xiang)關優(you)(you)缺點如下腦(nao)圖(tu)；而(er)影(ying)響網(wang)(wang)絡(luo)(luo)傳(chuan)輸(shu)質(zhi)量(liang)也有很(hen)多原因(yin)：包括(kuo)網(wang)(wang)絡(luo)(luo)擁(yong)塞、網(wang)(wang)絡(luo)(luo)丟包等(deng)等(deng)。這些因(yin)素直接決定當前(qian)實(shi)時視頻通話(hua)的質(zhi)量(liang)，也會給(gei)用戶帶來很(hen)大的體驗影(ying)響。這也是我們為什(shen)么(me)要進行優(you)(you)化的基本原因(yin)了。

0.2 弱網定義：

對(dui)于實(shi)時音(yin)視頻通(tong)話來(lai)說：網(wang)(wang)絡(luo)的(de)復(fu)雜性(xing)(xing)(xing)、異構性(xing)(xing)(xing)、協(xie)議部分(fen)不規范性(xing)(xing)(xing)、網(wang)(wang)絡(luo)異常，網(wang)(wang)絡(luo)錯誤等各(ge)種網(wang)(wang)絡(luo)環境被破壞的(de)特性(xing)(xing)(xing)都稱(cheng)之為弱網(wang)(wang)。弱網(wang)(wang)環境無法(fa)提(ti)供高質量的(de)網(wang)(wang)絡(luo)傳輸，對(dui)于接(jie)收端就是無法(fa)收到(dao)連續的(de)媒(mei)體包，造成(cheng)(cheng)聲音(yin)異常、視頻馬賽(sai)克(ke)、花屏(ping)、黑屏(ping)等現象，對(dui)于音(yin)視頻實(shi)時通(tong)話來(lai)說是非(fei)常致命(ming)的(de)，直接(jie)影響到(dao)用戶的(de)體驗，造成(cheng)(cheng)產品質量問題(ti)或者客訴問題(ti)。

0.3 實時音視頻(pin)特點

對(dui)于實時音視(shi)(shi)頻通話來說要求(qiu)最高(gao)的(de)(de)條件(jian)低延遲(chi)和高(gao)質(zhi)(zhi)量(liang)，這一(yi)對(dui)特性的(de)(de)存在就是(shi)天生的(de)(de)矛盾結(jie)合(he)體(ti)。高(gao)質(zhi)(zhi)量(liang)就要求(qiu)發(fa)送端(duan)盡可能(neng)(neng)發(fa)送高(gao)分辨率，高(gao)質(zhi)(zhi)量(liang)的(de)(de)音視(shi)(shi)頻流(liu)，對(dui)于帶寬(kuan)和網(wang)絡(luo)環境(jing)要求(qiu)比較高(gao)，不允(yun)許有(you)各種丟包(bao)(bao)、高(gao)抖(dou)動的(de)(de)現象(xiang)存在；而低延遲(chi)則對(dui)于網(wang)絡(luo)環境(jing)沒有(you)那么嚴苛，是(shi)允(yun)許存在一(yi)定丟包(bao)(bao)量(liang)、允(yun)許一(yi)定范圍內的(de)(de)接收抖(dou)動的(de)(de)，否(fou)則只能(neng)(neng)用空間(jian)換時間(jian)，導致音視(shi)(shi)頻實時性時效，無(wu)法達(da)到低延遲(chi)的(de)(de)要求(qiu)。所以這是(shi)一(yi)對(dui)矛與盾的(de)(de)故事。只能(neng)(neng)在矛上尋求(qiu)突破，在盾上給予保護，才能(neng)(neng)滿(man)足這樣苛刻的(de)(de)條件(jian)。

一 FEC

webrtc FEC 的實現方式有三(san)種：RED（rfc2198）、ULPFEC（rfc5109）、FLEXFEC(還未通過(guo))。但是 Ulpfec 是套用了(le) RED 的殼進行(xing)傳(chuan)輸(shu)的，所(suo)以我們(men)采用的是 ULPFEC 進行(xing) FEC 保護。

其基本(ben)原(yuan)理(li)是(shi)：在發(fa)送端，針對(dui)媒(mei)(mei)體包(bao)增加一定冗(rong)余 FEC 包(bao)，FEC 包(bao)是(shi)通過(guo)異或(huo) XOR 得到(dao)的(de)。如果(guo)在網(wang)(wang)絡傳(chuan)輸過(guo)程中丟掉(diao)了一部分媒(mei)(mei)體包(bao)，則在接收端通過(guo)接收到(dao)的(de)媒(mei)(mei)體包(bao)和 FEC 包(bao)進(jin)行異或(huo) XOR 得到(dao)丟失的(de)媒(mei)(mei)體包(bao)，這樣(yang)就不用發(fa)送 NACK 重發(fa)包(bao)占用網(wang)(wang)絡資源了。

由于(yu)這(zhe)部分在 WebRTC 中已經(jing)實現的(de)比較好，只(zhi)需要進行兼容(rong)性測試即可，這(zhe)部分沒有作為(wei)重(zhong)點(dian)優(you)化對象(xiang)，沿用 WebRTC 中內容(rong)即可。

二 NACK

2.1 NACK 介紹(shao)：

NACK 代表否定確(que)認。 它是(shi) WebRTC 中(zhong)的錯誤(wu)恢復機制之一。NACK 是(shi)接收端表明它沒有收到特(te)定數據包的一種(zhong)方式。

NACK 消息(xi)通過 RTCP 發(fa)(fa)送(song)(song)(song)給媒體的(de)發(fa)(fa)送(song)(song)(song)方，后(hou)者需(xu)要根據其在緩(huan)(huan)存中(zhong)(zhong)的(de)可用(yong)(yong)性(xing)以(yi)及對重(zhong)傳(chuan)(chuan)有(you)用(yong)(yong)性(xing)的(de)估計（是否(fou)可以(yi)使用(yong)(yong)）來決定是否(fou)重(zhong)傳(chuan)(chuan)丟失的(de)數據包(bao) 它曾(ceng)經收到(dao)。發(fa)(fa)送(song)(song)(song)端維(wei)護一個緩(huan)(huan)沖(chong)(chong)隊列(lie)，如果重(zhong)發(fa)(fa)包(bao)在緩(huan)(huan)沖(chong)(chong)隊列(lie)中(zhong)(zhong)則(ze)從緩(huan)(huan)沖(chong)(chong)隊列(lie)中(zhong)(zhong)取出再(zai)次發(fa)(fa)送(song)(song)(song)；如果沒有(you)在緩(huan)(huan)沖(chong)(chong)隊列(lie)中(zhong)(zhong)，則(ze)不再(zai)發(fa)(fa)送(song)(song)(song)，這樣解碼端就無法收到(dao)重(zhong)發(fa)(fa)包(bao)了。

2.2 優化和改進(jin)：

由(you)于當前系統中采用的(de)仍然是舊版本中的(de) NACK 流(liu)程(cheng)，具體流(liu)程(cheng)如下：

RTP 模(mo)塊解封包(bao)后(hou)，將數(shu)據包(bao)按照(zhao)到達順序(xu)依次傳送到 JitterBuffer 模(mo)塊中；

每(mei)個數據(ju)包在插入 JitterBuffer 模塊時都(dou)需要(yao)進行序(xu)(xu)列(lie)號的(de)(de)比較和排序(xu)(xu)，如(ru)果(guo)序(xu)(xu)列(lie)號比較新的(de)(de)數據(ju)包，則進行 NACK 構建，以(yi)上次保存的(de)(de)序(xu)(xu)列(lie)號+1 為起始(shi)值，以(yi)新收到的(de)(de)序(xu)(xu)列(lie)號為結束(shu)，將之間的(de)(de)序(xu)(xu)列(lie)號先緩存到 missing_sequence_numbers 中；

WebRTC 在(zai)(zai) JitterBuffer 中采用線(xian)程(cheng)查詢(xun)的(de)方式，每個(ge)一定(ding)時(shi)間進(jin)行一次遍(bian)歷，確認當前 nack List 中是否存在(zai)(zai)當前時(shi)間節點(dian)沒有按照順序收到的(de)數(shu)據包，如果存在(zai)(zai)就會組裝并發送 NACK RTCP 包到發送端，請(qing)求發送對應的(de)為接收到的(de)數(shu)據包。

NACK 是(shi)一個未到達數據包(bao)的(de)確(que)認過(guo)程(cheng)(cheng)，原(yuan)先流(liu)程(cheng)(cheng)中有很(hen)多(duo)嵌套(tao)功能，或者流(liu)程(cheng)(cheng)復(fu)雜(za)的(de)地(di)方(fang)，因此我們再理解的(de)基礎上做了兩次優化，其(qi)兩輪優化的(de)大概流(liu)程(cheng)(cheng)圖如下：

還有(you)一個 NACK 無法回避的(de)問題時(shi)：如果網(wang)(wang)絡(luo)丟包(bao)(bao)率比(bi)較高(gao)，或者網(wang)(wang)絡(luo)抖動，網(wang)(wang)絡(luo)異構導致網(wang)(wang)絡(luo)各種(zhong)亂序(xu)到達(da)情況比(bi)較嚴重，比(bi)如抖動超(chao)過(guo) 200ms 時(shi)，某些丟失的(de)數據包(bao)(bao)遲遲不到達(da)，則(ze)該包(bao)(bao)會重復發送多次(ci)，這樣會導致網(wang)(wang)絡(luo)擁(yong)塞的(de)現象，特別是分(fen)辨率比(bi)較高(gao)時(shi)，極容(rong)易(yi)造成視頻幀無法完(wan)整(zheng)解碼，出現馬賽克或者黑(hei)屏現象。

因此我們再次基礎(chu)上增加和(he)修改了一些判斷條件，進行緩存(cun)隊列(lie)和(he)清空(kong)隊列(lie)判斷條件優(you)化，以(yi)及獲取完(wan)整(zheng)視頻幀(zhen)流程部(bu)分(fen)調整(zheng)和(he)優(you)化，盡量減緩以(yi)上情況(kuang)的(de)影響，提升用戶體(ti)驗。

三 帶寬自適應

3.1 帶寬(kuan)自適(shi)應：

我們在(zai)進行視頻實(shi)時(shi)(shi)通(tong)話時(shi)(shi)，在(zai)設(she)備端(duan)(duan)(duan)按(an)照不(bu)同的幀(zhen)率(lv)采集(ji)數據設(she)置的參數，這樣(yang)發(fa)(fa)送(song)端(duan)(duan)(duan)就維護一個最大(da)幀(zhen)率(lv)參數集(ji)。之后采集(ji)的圖(tu)像進行編碼(ma)(ma)，分包發(fa)(fa)送(song)到網絡中。但是如果網絡發(fa)(fa)生了(le)變化，仍然按(an)照當前的碼(ma)(ma)率(lv)逐幀(zhen)發(fa)(fa)送(song)到上行網絡時(shi)(shi)，亦或者(zhe)采集(ji)端(duan)(duan)(duan)編碼(ma)(ma)性能不(bu)穩定無法消耗采集(ji)的圖(tu)像幀(zhen)序(xu)列，發(fa)(fa)送(song)端(duan)(duan)(duan)將(jiang)采取降幀(zhen)率(lv)或者(zhe)丟(diu)幀(zhen)的方式緩解發(fa)(fa)送(song)端(duan)(duan)(duan)的發(fa)(fa)送(song)壓力(li)。

在 WebRTC 中當編(bian)碼后(hou)的(de)傳(chuan)輸碼率(lv)過(guo)載或(huo)負載不均時，通過(guo)調用 MediaOptimization 類(lei)相關接口降(jiang)低或(huo)升高(gao)幀率(lv)進而減小或(huo)者(zhe)(zhe)升高(gao)碼率(lv)，從而有效利用當前帶寬，防止網(wang)絡更差，或(huo)者(zhe)(zhe)網(wang)絡帶寬負載不夠，影響(xiang)用戶體驗(yan)。

3.2 框架圖

發送(song)端(duan)：基(ji)于丟包率估算當前可用帶寬

接(jie)受端(duan)：基(ji)于包到(dao)達(da)時間計算可用帶(dai)寬

綜合：接(jie)收(shou)端(duan)發(fa)送(song)(song) REMB 反饋給發(fa)送(song)(song)端(duan)，然后基于發(fa)送(song)(song)端(duan)的(de)帶(dai)(dai)寬估(gu)算和接(jie)收(shou)端(duan)的(de)帶(dai)(dai)寬估(gu)算決定最終的(de)發(fa)送(song)(song)速(su)率。

3.3 發送端

發送(song)端的帶寬估(gu)計(ji)算(suan)(suan)法(fa)基(ji)本(ben)原(yuan)理(li)：是讀取 RTCP 中的丟包(bao)率信息，進而通過算(suan)(suan)法(fa)來動(dong)態計(ji)算(suan)(suan)當前網絡中基(ji)本(ben)情況，并判斷是否增加或減少帶寬資源(yuan)。如果(guo)判斷需要減少帶寬時，則(ze)采用 TFRC 算(suan)(suan)法(fa)來平滑處理(li)，減弱(ruo)突(tu)然增加或者(zhe)減少的風(feng)險。

3.4 接收端

接收端的帶(dai)(dai)(dai)寬(kuan)(kuan)(kuan)估計(ji)算(suan)法基本原理：讀取收到 RTP 數據(ju)統(tong)計(ji)進而估算(suan)當前網(wang)絡帶(dai)(dai)(dai)寬(kuan)(kuan)(kuan)；WebRTC 中采(cai)用卡爾曼濾(lv)波幀對(dui)當前幀的接收時間戳和(he)發送時間戳完成基本統(tong)計(ji)和(he)計(ji)算(suan)，從(cong)而估算(suan)當前網(wang)絡帶(dai)(dai)(dai)寬(kuan)(kuan)(kuan)擁塞情況和(he)利用率，評估和(he)修正帶(dai)(dai)(dai)寬(kuan)(kuan)(kuan)大小(xiao)，進而影響網(wang)絡帶(dai)(dai)(dai)寬(kuan)(kuan)(kuan)。

四 優化和改進：

4.1 優化和改進

我們做的(de)工作主要(yao)的(de)優(you)化點如(ru)下：

NACK 兩(liang)輪優(you)化(hua)：包(bao)括之前版本算(suan)法的(de)整(zheng)(zheng)體提升（重構原來 R4X 相(xiang)關代(dai)碼(ma)，采(cai)用和(he) iOS 相(xiang)同(tong)的(de) NACK 獲(huo)取算(suan)法，并在此基礎上進行緩存隊列和(he)清空判斷(duan)條件調(diao)整(zheng)(zheng)優(you)化(hua)、獲(huo)取完整(zheng)(zheng)解(jie)碼(ma)幀相(xiang)關流程優(you)化(hua)、長時間緩存幀丟棄策略調(diao)整(zheng)(zheng)等方案）、Jitterbuffer 參(can)數的(de)優(you)化(hua)調(diao)整(zheng)(zheng)；

FEC、動(dong)態(tai)分辨(bian)(bian)率、NACK 整體(ti)(ti)策略(lve)優化：針對(dui)不同(tong)的(de)(de)網絡條件，依據丟(diu)包率、RTT 等(deng)相關參(can)數，以(yi)及 5s 內的(de)(de)抖(dou)動(dong)平均值等(deng)，設計一套動(dong)態(tai)調整當前(qian)組(zu)合(he)的(de)(de)整體(ti)(ti)方案，既(ji)增加一定(ding)冗余防(fang)止 FEC 高丟(diu)包時時效現象，也可以(yi)在高丟(diu)包時逐步(bu)降(jiang)低(di)分辨(bian)(bian)率達到流暢播(bo)放的(de)(de)體(ti)(ti)驗。

網(wang)(wang)絡風暴抑(yi)制優化(hua)：WebRTC 中有重發(fa)(fa)(fa)包的網(wang)(wang)絡抑(yi)制策(ce)(ce)略，重發(fa)(fa)(fa)包占(zhan)比為 35%時(shi)候(hou)不(bu)再發(fa)(fa)(fa)送(song) NACK 重發(fa)(fa)(fa)包和 FEC 冗(rong)余包，但是這個占(zhan)比對于 720P、30%以上丟(diu)包時(shi)非常不(bu)友好，因此大量實際(ji)驗證測試，重發(fa)(fa)(fa)包和 FEC 冗(rong)余包占(zhan)比為 30%時(shi)，能夠(gou)合理(li)規避(bi)網(wang)(wang)絡風暴現象，同時(shi)滿足 NACK 請(qing)求重發(fa)(fa)(fa)的策(ce)(ce)略，達到 720P、30%丟(diu)包仍然可以獲取(qu) 15~25 幀率(lv)，實現流暢播放(fang)。

4.2 優化結果

整體方案(an)進(jin)行(xing)了部(bu)分(fen)實(shi)驗(yan)室場景的測試(shi)和驗(yan)收：包括 IP 和 SIP 通話，720P 和 VGA 分(fen)辨率驗(yan)證，相比之(zhi)前(qian)的版本，在一(yi)(yi)定(ding)程度上提(ti)(ti)高的用(yong)戶體驗(yan)。特別是有線網絡條件下 IP 直播(bo)時(shi)提(ti)(ti)升明(ming)顯(xian)(xian)，總體主觀的分(fen)有了明(ming)顯(xian)(xian)提(ti)(ti)升。同時(shi)對(dui)抗(kang)延遲也從(cong)無到有，能夠(gou)覆(fu)蓋 300ms 一(yi)(yi)下環(huan)境(jing)(jing)。該方案(an)得到用(yong)到實(shi)際環(huan)境(jing)(jing)中，得到用(yong)戶認可(ke)，并在和競爭對(dui)手(shou) PK 過程中，全面(mian)領先。

五 問題和措施：

5.1 擁塞檢測：

需(xu)要更加快(kuai)速準確定(ding)位到當(dang)前網絡(luo)狀態，一旦出(chu)現擁塞可以快(kuai)速調整當(dang)前發送策略。已(yi)經有視(shi)頻專項開始預研(yan)。

5.2 最新 WebRTC 中弱網控制

WebRTC 中(zhong)(zhong) NACK 模塊作(zuo)為獨(du)立的 module 集成到 VIE 模塊中(zhong)(zhong)，和 Jitterbuffer 模塊解(jie)耦，實(shi)現實(shi)時監控(kong)網絡丟(diu)包，并獨(du)立發送。

優點(dian)：可以(yi)實時獲取到 NACK 列表(biao)； 和(he) JitterBuffer 解耦，獲取更便捷、更迅速(su)。已經有視(shi)頻專項開始預研。

5.3 弱網前沿

2020-10-24 參加(jia)聲(sheng)網(wang) RTE2020 互(hu)聯網(wang)實時互(hu)聯網(wang)大會(hui)，聲(sheng)網(wang)已經實現 720P 2.0M 帶寬下 65%的丟包，流暢(chang)播放(fang)了。

1.深(shen)度強(qiang)化算法(fa)那在擁塞控制中(zhong)的應用；

2.實時 H264 視頻編(bian)碼器算法(fa)的(de)深度優化。

這些(xie)是我們之后要去調研學習(xi)(xi)的地(di)方，也期待(dai)有相關經驗的童鞋(xie)可以一(yi)起探討學習(xi)(xi)。

————————————————

版(ban)權聲明(ming)：本文為(wei)CSDN博主「聲網」的原創文章，遵循CC 4.0 BY-SA版(ban)權協議，轉載請附上原文出處(chu)鏈(lian)接及(ji)本聲明(ming)。

原(yuan)文鏈接(jie)：//blog.csdn.net/agora_cloud/article/details/120832250