實時音頻抗弱網技術揭祕

本文由百度智能雲-視頻雲技術架構師——柯於剛 在百度開發者沙龍線上分享的演講內容整理而成。內容從抗弱網技術意義出發，梳理抗弱網的概念與方法，結合百度RTC抗弱網過程中遇到的問題，重點分享抗弱網技術優化的探索與實踐。希望本次分享能夠讓開發者對抗弱網技術有一個全面的認識並掌握一定的webRTC優化方法

文/ 柯於剛
整理/ 百度開發者中心
視頻回放：https://developer.baidu.com/live.html?id=9

本次分享的主題是：實時音頻抗弱網技術揭祕，內容主要分爲以下三個方面：

1. RTC抗弱網技術的意義
2. RTC抗弱網技術解析
3. 百度RTC抗弱網實踐與探索

   1.抗弱網技術的意義

   
   在開發過程中，直播、點播 CDN 等雲服務往往會經過從「能用」、「好用」到「大規模使用」等階段。
   類似地，RTC 正處於從「能用」走向「好用」的過程中。我們需要提升用戶的視頻觀賞體驗，實現標準化的服務，而抗弱網技術是一個關鍵性的步驟。
   另一方面，不同於RTMP、RTSP 等「盡力而爲」的網絡協議，它們只解決網絡問題；RTC 是一個面向視頻交付的協議，聯動傳輸和編解碼，形成可靠的視頻交付。因此，抗弱網技術是實現全場景交付的支撐性技術。

   2.RTC抗弱網技術解析

   2.1 抗弱網涉及的環節和常用手段

   2.1.1抗弱網涉及的環節

   
   最典型的RTC系統結構通常包括兩個部分：平臺側和終端。
   而平臺側通常又分以下兩部分：
4. 用戶端接入， 包括信令和媒體。
5. 服務間流的中轉和控制，包括媒體分發、調度。

2.1.2 RTC抗弱網的技術手段

抗弱網的技術手段可以歸納爲2個層面，包含4個方法。
「2個層面」即網絡層面和音視頻層面。
「4個方法」包括：
（1）自適應方法。自適應地對網絡的帶寬進行評估、合理使用帶寬，並根據帶寬自適應地調整碼率。
（2）糾錯方法。針對丟包、丟幀等情況，通過前向糾錯，在網絡數據包、視頻、音頻層面上進行糾錯。
（3）緩存方法。針對網絡抖動、設備不穩定、設備性能有限等問題，設置視頻、音頻的緩存區。
（4）調度方法。儘可能地將用戶調度到最好的接入點，或在服務器側進行中轉，實現最優的內容分發調度，從而解決低延時和穩定性問題。

2.2 WebRTC抗弱網技術簡介

WebRTC 提供了包含一系列組件的低延時框架，主要環節包括：編碼、發送、接收和解碼。
絕大部分自研系統的架構也與此類似，但會在具體實現過程中對算法做相應的調整。
編碼環節：就發送方而言，我們需要根據其網絡情況自適應地採用合適的碼率；就接收方而言，我們會通過 Simulcast、SVC 等編碼手段根據網絡情況自適應地選擇接收方法。此外，我們還可以通過動態 Gop 根據場景控制傳輸壓力。
發送環節：首先進行帶寬估計和分配。如果發生了數據錯誤，我們會進行 RTX 重傳，或採取 FEC 等手段。此外，我們還可以採用 PACING實現網絡的平滑發送，並確定數據帶寬使用和發送的優先級。
接受環節：需要與發送方就帶寬的估計、重傳等操作進行配合。我們可以通過 NACK 請求發送方重新發送數據包，或者通過 RTCP 的反饋指示接收方實際的接受情況，也可以通過動態視頻、音頻緩存適應網絡的抖動。
解碼環節：需要解決錯誤隱藏問題，在數據出錯之後儘可能提升用戶體驗。此外，我們還需要針對不均衡、不穩定的網絡實現穩定的持續輸出。
之前的流媒體協議主要作用在網絡層面，沒有實現網絡和編解碼環節的聯動，而WebRTC 可以大大提升對弱網的適應性。

2.3 抗弱網技術總覽

進一步歸納，抗弱網技術主要需要解決丟包、延時、亂序抖動、限速、網絡質量突變等情況。我們會在帶寬評估、帶寬分配、帶寬使用、緩存、解碼渲染等環節上解決上述問題。
在進行帶寬估計時，我們可以採用基於丟包、基於時延、基於 ACK 帶寬的方法，也可以通透與探測實現帶寬估計；
在進行帶寬分配時，我們可以通過網絡情況動態地分配視頻、音頻的編碼碼率，實現 FEC 前向糾錯和相互糾錯重傳的帶寬預分配。
在帶寬使用方面，對於糾錯後分配的帶寬，我們需要通過 Nack、Sack、FEC 等數據重傳，或通過 Pacing 等技術確定數據的優先級，提升發送的均衡性；
就緩存技術而言，WebRTC 中提供了面向視頻的 JitterBuff 和麪向音頻的 NetEQ，從而適應網絡的抖動、修補數據的殘缺、將網絡數據包轉換成音頻幀或視頻幀。

2.4 關鍵技術解析

2.4.1 帶寬評估——TCC基本理解

TCC 是一種帶寬評估技術，其輸入爲接收狀況的反饋，該數據會輸入給帶寬估計的三個控制點：丟包估計、延時估計、確認帶寬估計。
丟包估計：根據丟包率的大小，在上次評估的帶寬基礎上，判斷是增加帶寬還是降低帶寬。
延時估計：採用 Aimd 調節實現「和」式的帶寬增加，以及乘法級的帶寬降低。具體實現方式：分別計算再發送端和接收端，連續兩個包之間的差值之差，擬合線性迴歸函數，根據斜率判定網絡是擁塞、輕載、穩定，再確定如何調節帶寬，帶寬基值依賴於接受方反饋帶寬估值，調節方式依照和增乘減方式。
確認帶寬估計：基於FeedBack接收統計丟包率，採用貝葉斯評估接收方到碼率，該值作爲延時估計的帶寬基值。
我們對丟包估計得出的帶寬值和由 Aimd 處理後的時延估計結果取最小值，從而得到最終的帶寬評估結果。值得一提的是，確認帶寬估計提供帶寬需要調節的基準值，而丟包估計和時延估計則提供調節意向。

2.4.2 TCC的優缺點

TCC技術的設計優點包括：

1. 採用「丟包+延時」網絡擁塞檢測方法，實現了邊界性的保護。
2. 面向視頻應用，考慮未充分使用的帶寬、應用已確認的帶寬，並探測估計出的帶寬是否有效。

TCC 技術的不足之處在於：

1. 所有估計強烈依賴反饋，接收端會影響發送端。
2. 發送方的丟包、延時擁塞估計都基於統計實現，反映靈敏度低。
3. 未覆蓋高抖動等場景。

2.4.3 帶寬分配

帶寬分配最典型的應用場景是對視頻和音頻的帶寬分配。就音頻而言，其帶寬主要包含音頻的原始碼率以及爲重傳、糾錯預留的帶寬。大部分的帶寬將分配給視頻，視頻的帶寬分爲三部分：
（1）視頻原始碼率（2）前向糾錯的 FEC帶寬（3）視頻的 Nack 所需要的帶寬。
需要指出的是，Nack 的帶寬不是預分配得到的，而是根據之前的網絡情況統計得出。在具體實現中，我們會採取一些保護措施，
例如：要求視頻 FEC 的碼率加上實際重傳的碼率小於等於最終分配給視頻的帶寬的一半。在這種設置下，WebRTC 的抗丟包率約爲20-30%，我們可以根據實際的丟包、延時情況改變 nack+fec 的帶寬分配比例，從而提升抗丟包率。

2.4.4 帶寬使用——NACK+重傳

帶寬使用主要涉及重傳和 FEC 兩個場景。就重傳而言，如上圖所示，發送端的 host1 丟掉了 101、102 兩個包。
接收方發現丟包的時機可能有兩個：
（1）在接收 103 號包時，基於包序規則發現丟掉了前兩個包，因此重新對發送方申請發送 101 和 102 號包。
（2）如果重新請求後經過了 RTT+退避期的時間仍然沒有收到這兩個包，則會通過基於超時的方式重傳包，避免了
NACK 的風暴。
發送方收到NACK的請求之後，也會採取一定的措施進行控制。如：同一個RTP包，在兩次重傳間會隔1倍的RTT，通過這種方式可以保護因多次發送導致的帶寬佔用。

2.4.5 帶寬使用——前向糾錯FEC

前向糾錯 FEC 技術經歷了從 UlpFEC 到FlexFEC 的發展。UlpFEC 是一種基於行式的生成方式，如果連續丟掉了兩個包就很難恢復。爲此，FlexFEC 採取了行列交織的方式，即使連續丟包也有可能恢復，但是會引入額外的計算開銷，計算開銷與恢復率成正比。FEC 在穩定環境（例如，丟包率成正態分佈）中較爲容易恢復，然而在現實網絡中的效果會有一定的降低。
在啓用 FEC 時，我們要進行發送端和接收端的 SDP 協商，並根據當前網絡帶寬狀況選擇是否開啓。就 FEC 的參數而言，我們需要設定幀內的 FEC，確定每個 FEC 包由多少數據包生成、行列矩陣的組成，以及帶寬的使用情況。目前，WebRTC 根據 FEC 通過異或計算生成 FEC 包，記錄包的依賴關係，並根據它恢復出丟失的原始 RTP 包。

2.4.6 視頻緩存與解碼——JitterBuff基本理解

JitterBuff 的輸入爲網絡的 RTP 包，輸出爲一個視頻幀，它實現了以下功能：
（1）一套動態緩存機制，處理丟包、超時、亂序、延遲、幀殘缺等異常情況。
（2）一套將 RTP 包解碼成幀的控制機制，確定還原幀的時機、參考關係，以及根據 RTP 包還原殘缺幀的方法。
（3）計算網絡抖動延時，通過卡爾曼濾波，預測包到達的時間，實現出幀的平滑性。

2.7 音視頻緩存與解碼——NetEQ基本理解

NetEQ 被用於實現音頻的動態緩存，通過計算網絡抖動，實現 RTP 包的緩存、去重、排序、糾錯等功能。
NetEQ 採用直方圖估算平穩抖動，通過峯值檢測應對突發變化情況。當緩存中數據不足時，降低出幀的頻率；當緩存中數據過多時，提升出幀頻率，從而實現均勻出幀。對於空幀，NetEQ 會根據前幀和後幀擬合出補償幀。日前，Opus 編碼格式下開啓 DTX 的幀內 FEC 後，抗弱網的能力會大大提升。

3.百度RTC抗弱網實踐與探索

3.1 百度RTC抗弱網總覽

RTC是一種低延時的通信技術，也可以被用於低延時直播等場景，更好的實現對弱網的適應性。
RTC 抗弱網技術主要被應用於 1對1、Ｎ對Ｎ，以及流場景下。我們不僅需要考慮如何應對媒體環境下的抗弱網問題，還需要從接入、調度、用戶體驗的角度考慮如何抗弱網。

3.2 媒體抗弱網實踐

就媒體抗弱網而言，
在帶寬估計階段，我們首先要判斷丟包的類型，確定對帶寬的調整方案，提升抗亂序抖動效果、提升對網絡變化感知的靈敏度。
在帶寬分配階段，我們以清晰和流暢爲目標導向，根據對丟包率、延時、抖動的統計情況，預測恢復效果，動態調整 ARQ、FEC，以及編碼帶寬比。
在帶寬使用階段，我們需要精細地考慮重傳機制，優化接收方發起重傳的時機和發送方發送數據包的時機，從而避免重傳風暴，保證重傳的有效性。在重傳 Nack 請求丟失時，我們需要及早發現並儘可能快速恢復。此外，我們還需要重點優化音頻的連續丟包問題、採用 Pacing Sender 優化，也會結合解碼環節採用多碼流的 Simulcast 和 SVC 技術。
在緩存\解碼\渲染階段，我們對視頻、音頻 Jitter 進行了優化，從而適應抖動、亂序等場景。值得注意的是，目前的 WebRTC
協議是端到端的，然而目前許多商業系統並不是端到端的系統，它們只考慮了服務器端的優化，而我們還需要考慮發送端的抖動情況。

3.3 其它技術實踐

3.3.1 帶寬估計TCC優化——增強丟包抗性

爲了增強對丟包的抗性，我們將丟包的情況分爲擁塞丟包、非擁塞丟包和偶發丟包。
非擁塞丟包場景下，個體的避讓對整體信號質量的影響有限，爲了保證視頻的流暢，我們不能降低帶寬，需要發送更多的數據包，將帶寬分配給糾錯部分。目前，我們還很難解決擁塞丟包問題。偶發丟包問題可能是非持續的網絡信號抖動，無需通過降低帶寬來優化。

3.3.2 帶寬估計TCC優化——增強亂序抖動抗性

帶寬估計對亂序抖動的適應性較差。爲此，我們需要避免將亂序誤判爲丟包。在存在一定丟包的情況下，也應該考慮對亂序和延時的估計，提升對弱網的適應性。

3.3.3 帶寬估計TCC優化——提升擁塞靈敏度

在帶寬估計過程中，默認的實現以事後統計數據爲基礎。爲了提升探測擁塞的靈敏度，我們可以通過在發送端增加 TCP 擁塞窗口，動態地分配窗口，可以很靈敏地感知到發送方下行帶寬出現的擁塞。

3.3.4 百度在媒體抗弱網的優化方案

弱網中可能會出現丟包、延時、抖動、亂序以及一些突發情況，每個因素可能會影響到上行、下行信號，而不同的控制機制會涉及推流和拉流方。因此，抗弱網場景十分複雜。
如上圖所示，我們會提取一些關鍵路徑上的組合點，並且在每一步中對算法進行調整優化。接着，我們會重新在上述場景下檢測優化後的算法，並且在線上進行 A/B 驗證，逐漸得到理想的算法。

3.3.5 Wifi+4G同傳，抗弱網另闢蹊徑的方法

如今，手機/電腦等終端往往可以同時使用 4G 和WiFi 信號。我們會持續檢測 4G 和 WiFi 的網絡質量，在 WiFi 信號較差時及時使用 4G 信號作爲補償，強化音頻傳輸，保證音頻數據的連續性。

3.3.6 分發與調度——虛擬低延遲分發網

在分發與調度環節中，我們試圖得到服務器之間的最優分發路徑，不斷檢測部署的雲節點、公網的邊緣節點之間的連通性，挑選出較優的連接，形成虛擬的低延時中轉網絡。
在下次使用時，我們優先使用事先挑選出的虛擬中轉網絡。爲了降低服務器網絡波動對實時通信結果的影響，我們在分發時會建立多條冗餘備路，隨時自動切換，並採用重傳、糾錯等手段避免分發不穩定的問題。

以上是老師的全部分享內容，有問題歡迎在評論區提出。

點擊進入獲得更多技術信息~~