當下社會,實時音視頻通話已經成為人們生活、工作中重要的組成部分,如商務會談、親朋聊天等。而在通話過程中,總會存在着這樣那樣的意外情況:可能你坐在飛馳的高鐵上——信号時好時壞;又或者在會議途中離開辦公室——網絡從 wifi 切換到 4G……實現高質量的實時音視頻通話需要搭建一座無視距離連接人們的“橋梁”,而這座“橋梁”需要優秀的“基建技術”來保障網絡傳輸的穩定性和可靠性。
網絡傳輸鍊路上存在着許多不穩定的情況,造成所發出去的數據包出現丢包、延時或者抖動。不穩定的原因有很多,兩個通訊雙方在物理空間上存在距離,傳輸過程經過很多設備的處理,中途存在線路硬件故障、軟件驅動限制、或者鍊路數據擁塞等情況,都會導緻發送出去的數據包在接收端沒有辦法收到或者延遲收到。
我們可以通過一些簡單基礎的工具檢測網絡是否處于波動情況,比如 ping 命令或者 Iperf 工具可以幫助統計丢包、延時以及單向抖動。我們用 ping 命令向一個遠端的主機發送 ICMP 消息,遠端主機會對你進行應答,這個過程中如果你發送出去的 ICMP 消息丢了,或者遠端服務器應答的消息丢了,在命令行界面上,對應的 icmp_seq 就會顯示超時未收到,這種情況就直觀地體現了丢包。
ping vs iPerf
帶寬分配和冗餘策略是弱網對抗核心模塊,随着算法的演進叠代,我們能夠保證線上大部分場景的優質音視頻體驗。對于一些小概率或特殊場景,如突發網損、擁塞恢複、PPT 翻頁等,我們還引入了多種冗餘策略,來兼顧流暢、恢複效率和低延時的需求。
2. 常用包恢複技術通常,一個數據包在網絡傳輸鍊路中丢失了,主要有兩種方式将包進行恢複:一種是發送端利用接收端通知或者超時的機制,重新将這個包發送過來;另一種則是基于其他收到的冗餘包,在接收端将該包恢複出來。
第一種是我們熟知的自動重傳請求 ARQ 技術。與 TCP 協議中的 ACK 應答機制不同,實時音視頻場景使用的是 NACK 否定應答機制,通過接收端檢查包序号的連續性,主動将丢失的包信息通知給發送端進行重新發送。這種方式的優點是在低延時場景下的恢複效率高,帶寬利用率好,但在高延時場景下的效果比較差,存在重傳風暴等情況。
第二種是 Forward Error Correction (FEC) 即前向糾錯編碼,一種通過冗餘發送對抗網絡丢包的技術。它主要的技術原理就是分組編碼,組内進行冗餘恢複。假設每個分組由 k 個媒體包和 r 個冗餘包組成,一個分組中 k r 個數據包中任意 k 個包可以用來重建 k 個原始媒體包。這種方式的優勢是根據先驗知識進行冗餘決策,不受延時影響。
在上述基本的包恢複技術下,為了使各種場景的整體抗弱網能力最大化,需要針對帶寬分配、抗丢包技術的組合配置等進行一系列的優化,從而達到抗丢包能力、端到端延時、卡頓率、冗餘率的平衡,達到“消耗最小的代價,實現最優的體驗”。
下面具體介紹我們在這方面做的幾項優化。
3.1 自适應調整策略
冗餘策略大緻可以分為兩類,一類是前向冗餘,一類是被動冗餘。按照前文的描述,我們知道前向冗餘的優點是不需要交互,在高延時環境下更加适用,缺點是帶寬占用過多。被動冗餘的優點是按需發送,占用帶寬較少,缺點是高延時場景效果會急劇下滑。
我們的冗餘策略則是在尋找一個平衡點,通過被動冗餘和前向冗餘策略比例的調整,在保證丢包恢複率(比如 99.5%)的前提下,盡量的減小冗餘占比,盡量的減小抗丢包恢複時間。所以,我們可以将當前問題抽象成如下一個數學場景:
基于上面的模型,在 m (平均幀分組大小), k (允許時間範圍内的重傳次數), i,j 是可以自變量。我們隻要将 n 從 0 開始代入,上面求和的結果大于 99%,就可以将這個 n 作為 FEC 的冗餘率。
通過上面的算法,我們定義一個抗丢包恢複時間 resend_delay,就可以獲得被動重傳次數 k。通過參數 k,可以推導出為了達到恢複率 99%,還需要的 FEC 比例。
上述就是理論上的最優冗餘率計算邏輯。通過該算法邏輯,我們可以獲得一個自适應的冗餘調整策略,從而獲得最優的冗餘比例、最合适的延時損耗、以及最佳的丢包恢複率。
3.2 可靠重傳策略
在接收端媒體緩存中,對于 seq 最新和最老範圍内沒有接收到的數據,接收端會發送 Nack 請求,然後發送端接收 Nack 請求,将相應的包傳送過來。
正常工作狀态中,Pacer 優先發送 RTX 重傳數據,然後再發送媒體數據,這樣接收端這邊較老的丢失數據包,總能夠優先得到恢複。
但是在一些場景下,比如大丢包(70% 或以上的丢包率),或者突然限寬(4M ---> 300K)時,會出現大量的數據包被丢棄掉。這個數據包既包括原始包,也包括 Nack 重傳包,這樣會導緻如下圖的一些問題。
如圖,如果丢包恢複效果比較差,比如上面 n 3 的幀已經開始發送了,但是 n 幀還沒有被接收端全部接收到,這時,接收端生成的需要重傳的包列表 nack_list 就會很長。對于發送端來說,由于媒體數據還在繼續發送,理論上接收端請求的 nack 會越來愈多,這樣就會形成 nack 風暴。
Nack 風暴不但會導緻大量的重傳流量擠占媒體帶寬,導緻帶寬分配模塊分配給媒體的碼率降低,也會導緻 Pacer 擁堵,從而帶來更大的端到端延時。同時,由于不是選擇性的重傳某個幀的媒體包,導緻接收端需要解碼的幀能夠被完整丢包恢複的概率比較低。
為了避免上述情況,我們引入了可靠重傳模塊:在檢測到上述情況後,及時暫停媒體發送,同時全力保障已經發送的幀數據能夠完全恢複。
我們通過 TccAck 和 Nack 請求的信息來确定某一個包處于什麼狀态,然後統計當前已經發送的數據中沒有被完整 ACK 的幀數量。如果這個數量過大,則會暫停媒體發送(同時暫停編碼器)。暫停媒體發送後,按照幀從老到新的順序,把 pacer 預算分配給最高優先級的幀,主動發送這些幀裡面沒有被 ACK 的數據。
通過上面的方式,我們有效解決了目标場景長時間卡死或者卡頓過多的問題。
3.3 擁塞恢複場景下快速抑制 FEC 碼率
我們 FEC 使用 loss 計算 FEC 冗餘率,為了防止抖動帶來的劇烈變化,這個 loss 值被平滑過。但是對于一些場景,比如帶寬突然掉落到較低的場景下,當擁塞狀态解除後,網絡丢包就會消失。這個時候,我們需要快速的抑制 FEC 碼率,讓出帶寬給到媒體,這樣可以盡快地提升畫面質量。
使用上面的狀态機,在接收到擁塞解除信号(擁塞狀态解除,并且瞬時 tcc loss 變為0)後,在平滑 loss 沒有變為 0 的情況下,使用瞬時 loss,可以快速取消掉 FEC 冗餘。
3.4 空餘帶寬利用優化
在共享場景下,冗餘策略會遇到進一步的挑戰。比如在 PPT 不翻頁的時候,空餘帶寬需要讓給視頻。但是在翻頁的時候共享流又會迅速占據帶寬。這樣就會導緻視頻碼率在翻頁時出現較大的波動。如果整體可用帶寬較低,就能夠看到視頻質量的明顯變化——卡頓率、延時上升。
如圖,在 PPT 翻頁場景,video 會使用 screen 空餘未被使用的帶寬。靜止畫面下,video 使用了大部分原本共享的預算。一旦 PPT 翻頁,共享的碼率瞬時提高,而 video 沒有及時把編碼碼率降下來,就會造成 pacer 模塊的擁堵,導緻丢幀從而攝像頭流卡頓。
針對該場景,我們對帶寬分配策略進行了優化:
帶寬分配過程中對每個媒體流使用的上一層傳過來的空餘碼率進行緩升快降操作,防止高優先級碼流過快讓出空餘帶寬,導緻低優先級碼流的分配碼率大幅波動。
當某個媒體流開始收到關鍵幀的時候,降低該流讓出空餘帶寬的量,使得整體輸出碼率的波動性降低。
使用 300ms 統計窗口判斷波峰,出現較大的波峰數據時,降低該流讓出帶寬的量,減小整體輸出碼率的波動性。
4. 優化效果在上述的冗餘策略優化下,飛書會議整體冗餘率大幅度降低(部分上漲是由于原有算法冗餘不足,出現大量卡頓,算法優化後,整體冗餘率調整為最佳值)。同時,在保證了音視頻整體效果的前提下,整體端到端延時也進一步下降,提升了飛書會議的整體音視頻體驗。
在與同類産品的比較中,我們優化算法的冗餘度明顯低于同類産品,在流暢度對齊的情況下,消耗更小的帶寬。特别是在高丢包,高延時場景下,我們的冗餘率隻相當于同類産品的 40%。
通過這些經優化的冗餘策略,當前飛書會議在弱網場景下的卡頓率、端到端延時、冗餘率等指标得到了大幅度的優化。在此基礎上,我們未來會在極端弱網支持,帶内冗餘聯動策略,智能場景識别等方面,進一步加大投入,增加飛書會議在各種弱網場景下的客戶端體驗。
5.1 極端場景下的抗弱網能力支持
增加針對極高丢包、極高延時、丢包 延時,低帶寬 高丢包等場景的支持,配合冗餘策略以及帶寬分配策略,達到極端弱網場景下面的最佳音視頻體驗。
5.2 帶内冗餘聯動下的抗弱網策略
冗餘策略,除了前面提到的非音視頻編碼内的帶外冗餘(Nack,FEC 等),也包含音視頻編碼内的帶内冗餘。相比于帶外冗餘,帶内冗餘往往結合編碼自身的特點,使用更少的冗餘碼率代價,達到更高的抗弱網效果。
我們的冗餘策略也會進一步結合、更大化利用帶内冗餘算法,進一步提高抗弱網能力,降低整體延時和帶寬占用。
5.3 場景識别下的抗弱網策略優化
後續,我們還将對當前的網絡環境進行識别,獲取到當前的網絡場景,從而可以進一步對冗餘策略以及編碼策略進行預判式的策略下發。
比如,我們識别到當前場景為高鐵場景,就可以在冗餘策略生成的時候偏向于抗連續丢包的策略,也可以預先增加默認前向冗餘來增加突發弱網的抗性。根據識别場景的特性,可以在實際發生弱網之前以及發生弱網之後,做出策略上的區别。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!