RTC 系統音頻弱網對抗技術發展與實踐

本文整理自線上直播【MCtalk Live#2 ：RTC 系統音頻弱網對抗技術發展與實踐】網易雲信資深音視頻引擎開發專家崔承宗分享內容，文末也可查看直播回顧視頻。

1、背景介紹

RTC（Real Time Communication）系統廣泛應用在視頻會議、在線醫療、泛娛樂、在線教育等實時互動場景，為用戶提供低延時、高清晰度和流暢度、高保真音質的實時互動體驗。音頻弱網對抗技術旨在提升 RTC 系統在弱網（高丟包、大抖動、高延遲）條件下的用戶體驗。

本文從 RTC 系統的音頻弱網效果、弱網對抗的諸多技術以及 RTC 系統層面進行較為詳盡的分析，希望可以幫助讀者對 RTC 系統的音頻弱網對抗技術有所了解。

2、常見音頻弱網卡頓現象

實際場景中常見的音頻弱網卡頓現象有如下表所示幾次情況：

表1 常見 RTC 應用音頻弱網卡頓現象
序號	現象	排查路徑	問題歸類
1	音樂聲音不飽滿、發悶，飄忽、卡頓	確認 CODEC 采樣率、碼率，編碼器類型	CODEC類 型選型，CODEC參數設置
2	聲音快進、慢放	網絡 RTT，網絡數據突發數據量，設備信號強度等	網絡抖動、去抖動處理邏輯、網絡連接信號差等
3	聲音卡頓、卡死、斷續	網絡丟包率和 RTT、網絡帶寬預測、碼率分配、網絡擁塞控制等	網絡擁塞、網絡連接差等

3、RTC 系統音頻的抗性

針對上述音頻卡頓現象，我們該如何應對呢？表2列舉了業界常用的音頻抗丟包算法和相互對比。

表2 業界常用的音頻抗丟包算法對比
對比	帶外 FEC	Opus/SILK 帶內 FEC	RED	ARQ	PLC
延遲	分組延時+單向傳輸的時間	1或者2倍幀長+單向傳輸的時間	RED 最大層數 N 倍的幀長+單向傳輸的時間	N 倍 RTT 的傳輸延時，N 是最大重傳次數	無延遲
使用方式	前向糾錯	編碼器特性	前向糾錯	后驗糾錯	后驗糾錯
適用情況	隨機丟包、網絡 RTT 較大、包長度較大的場景	小丟包或者非連續丟包、編碼器編碼碼率較高的場景	隨機丟包、網絡 RTT 較大、包長度較小的場景	突發丟包和持續丟包、網絡 RTT 較小的場景	小丟包或者非連續丟包根據上下文或者臨近波形生成相似波形
實現難度	相對復雜，涉及到發端、收端FEC編解碼邏輯，動態冗余、反饋及時性等	相對簡單，涉及編碼器碼率和網絡丟包模型	復雜度低於帶外 FEC，涉及到動態冗余、反饋及時性等	看似簡單，實際上網絡復雜場景下的挑戰較大	相對復雜，通過波形相關性或者噪聲填充，提升抗丟包能力

下面，我們詳細介紹一下音頻抗性的這幾種算法。

抗丟包 FEC

前向糾錯也叫前向糾錯碼（Forward Error Correction，簡稱 FEC），是增加數據通信可信度的方法。FEC 利用數據進行冗余信息的傳輸，當傳輸中出現數據丟失時，將允許接收端根據已經接收的數據恢復丟失數據。

如下圖所示，我們可以看到，發送端將數據包根據冗余度參數進行分組 (block)，對分組數據增加冗余。接收端在收齊分組后，即可恢復丟失數據（條件是丟失不超過冗余包數）。因為接收端要等待FEC分組到齊，所以存在 FEC 恢復算法上的延時， FecDelay = Block個數 * 幀長。

圖1 發送端和接收端的 FEC 處理示意圖

那么，常用的 FEC 冗余算法包括哪些呢？

RTC 系統中常用的 FEC 冗余算法包括：XOR、Reed Solomon、噴泉碼等。其中，以 XOR 和 Reed Solomon 算法的應用較為廣泛。

下面簡單介紹一下 Reed Solomon 算法的數學背景。

Reed Solomon 算法的核心思想包括三個部分：

• 利用范德蒙德(Vandermonde)矩陣 F，通過數據塊計算編碼塊（即算冗余矩陣），如圖2所示

圖2 利用范德蒙德(Vandermonde)矩陣計算冗余矩陣示意圖

• 利用高斯消元法(Gaussian elimination) ，恢復損壞的數據塊 （即算冗余矩陣的逆矩陣）
• 為了方便計算機處理，所有的運算是在伽羅華域 Galios, GF(2^w) 的基礎上進行

抗丟包 RED

如前所述，RS FEC 算法由於涉及矩陣運算，在發送端和接收端都會增加額外的性能開銷。考慮到音頻包長度較小，采用 RED（Redundant Audio Data）方式進行冗余是一種更有優勢的策略，可以提高數據包 payload 的利用率，並降低性能開銷。

我們舉一個實際的例子：一個 RTP 音頻數據包，包括一個 DVI4(8KHz) 主編碼塊和一個單獨的 8KHz LPC 編碼的冗余塊，兩者長度均為 20ms。參照 RFC 2198 標准所定義，示例格式如圖3所示。

圖3 基於 RFC 2198 的 RED 組包示意圖

抗丟包 ARQ

介紹了 FEC 和 RED 這兩種前向糾錯方法之后，下面我們再看一下音頻 ARQ。

音頻 ARQ（自動重傳請求）重傳使用的是 NACK 方式，如下圖。

圖4 發送端和接收端的 ARQ 處理示意圖

假設是隨機均勻丟包場景，重傳失敗率概率為：Pn = P(n-1)*lossrate。對於音頻來說，假設當重傳失敗概率 Pn<1% 時，認為重傳成功，那么 n 就是重傳成功所需的次數(截斷二進制指數退避算法)。

各種丟包率條件下需要的理論重傳次數如表3所示。

表3 各種丟包率條件下需要的理論重傳次數
丟包率	需要重傳的理論次數
10%	1
20%	2
30%	3
40%	5
50%	6
60%	8
70%	10
80%	21

我們可以看一下兩種情況：

• 假設 10% 丟包：重傳一次失敗的概率 10% * 10% = 1%。
• 假設 50% 丟包：重傳一次失敗 50%50%=25%，2次：2550% = 12.5%，4次: 3.125%，6次：0.78%。

音頻快速重傳 ARQ 就是以“選擇重傳”算法作為基本的請求策略，其算法的關鍵特色在於重傳請求與 JitterBuffer 的緊密配合。

• 請求重傳模塊記錄並緩存所有重傳數據包的重傳成功所消耗的時間，並將重傳延時 Arq Delay 告知 JitterBuffer 模塊，提高了數據的緩沖等待時長的高可控性，參見(6)。
• 接收端通過 ARQ 請求，在數據緩沖隊列的數據幀被播放之前，當還未重傳成功的數據幀在已經達到播放時間時，接收端通過 ACK 通知取消請求重傳，減少無用請求，參見(5)。

圖5 發送端和接收端的 NACK 請求和重傳示意圖

ARQ 策略受 RTT 影響較大，由於 ARQ 的原理是針對丟包進行選擇性請求和重傳，所以它對於突發丟包有較好的對抗能力，冗余碼率的利用率遠高於 FEC 和 RED。

ARQ 策略在使用中的難點是合理把握 NACK 請求的時機和間隔以及重傳包的碼率控制，防止誤請求、多請求和多重傳，尤其在抖動場景下需要格外關注。

抗抖動

弱網環境除了丟包以外，在 4G 和 Wifi 等移動接入場景中抖動和亂序較為常見，主要原因是移動鏈路的多徑干擾、信號衰減、臨頻干擾等。為了處理抖動和亂序，保證接收端數據包的有序接收，在 RTC 系統的接收端引入抗抖動模塊，原理如圖6所示。

圖6 RTC 系統的抗抖動模塊原理示意圖

抗抖動模塊重要的組成部分之一是網絡抖動的預測。抗抖動模塊根據網絡抖動的預測結果自適應調節Jitterbuffer長度，以達到抗抖動的目的，並能夠在網絡無抖動的時候保證低延時。抗抖動模塊的抖動預測模塊原理如圖7和8所示。

Jitterbuffer 模塊的網絡延時估計是以 IAT（inter arrival time）為基礎的。IAT 的含義是相鄰包到達時間間隔。通話時間越長，包間隔 IAT 的概率分布越穩定。觀察周期內 IAT 的整體概率分布之和近似為1。一般采用 95% 作為滿足統計概率的閾值，計算出 Jitterbuffer 的目標值大小。

圖7 抗抖動模塊的抖動預測原理1

圖8 抗抖動模塊的抖動預測原理2

抖動預測之后，需要對 buffer 中音頻數據進行調節，常用的做法是進行加減速播放。在需要拉伸 jitterbuffer 的時候進行慢放操作，在需要壓縮 jitterbuffer 的時候進行快放操作。

• 語音時長修正（Time Scale Modification, TSM）是一種通過擴展或者壓縮語音長度，從而改變語音速度的技術。在進行時域壓縮或者擴展的同時，還應盡量保證語音信號的基音頻率及音色—即變長不變調。
• Wsola（波形形似同步疊加法）是一種基於語音信號准周期特性，進而插入基因周期整數倍的信號來實現波形長度變化的算法。

4、RTC 系統音頻的編解碼

在介紹了 RED、ARQ 和抗抖動等弱網對抗技術之后，我們再介紹一下基於音頻編解碼器實現的弱網對抗技術。

如下圖，說明了各種編解碼器的質量與碼率的關系：

圖9 音頻編碼器碼率和質量對比圖

圖中綠色線條代表的是無專利要求且開源的編解碼器，其中 G.711 和 G.722 是 ITU 早期應用於電信網絡的語音編碼標准，相應只支持窄帶和寬帶頻率范圍，碼率相對固定，壓縮率較低。藍色線條代表的是無專利要求但是閉源的編解碼器，相比 G.711 和 G.722，它們支持的頻帶更廣。最后，紅色線條代表的是有專利要求並且閉源的編解碼器，其中 AAC 和 MP3 是 Fraunhofer 主導制定的音樂編解碼器標准，廣泛應用在數字音樂領域。

圖10 則說明了各種編碼器的編碼延遲與碼率的關系：

圖10 音頻編碼器碼率和編碼延時對比圖

從圖中也可以看出，除了 Opus 以外，其他編解碼器的碼率變化范圍相對較小，這與編解碼器所覆蓋的頻帶范圍相關。另外，不同編解碼器的編碼延時也有明顯差異，MP3 和 AAC 等音樂編解碼器的編碼延時較大。

由此，我們可以得出結論，Opus(RFC 6716) 是唯一一個覆蓋全頻帶的音頻編碼器，並且它有如下的特性：

• 支持動態碼率
• 在同等碼率水平（高於8kbps），其質量高於其他音頻編碼器
• 其編碼延遲低於其他音頻編碼器

帶內 FEC

Opus 編解碼器內部支持的原生帶內 FEC 在 Speech 場景下，可以處理大約 20% 以內的丟包，其原理是通過當前幀攜帶前一幀的縮小版壓縮包信息來恢復丟失的信源。如圖11所示。

圖11 官方 Opus inband FEC 抗丟包能力

具體到 Opus 編碼器內部實現，inband FEC 是通過 LBRR（Low Bitrate Redundant）幀實現的。LBRR 幀包含了前一個音頻幀的信息，和當前幀一起打包編碼。圖12是 LBRR 幀的編碼代碼。

圖12 Opus 帶內 low bitrate redundant(LBRR)

PLC

以上介紹了多種帶外抗丟包策略，下面簡單介紹一下丟包補償策略 PLC。

PLC（Packet Loss Concealment）丟包補償是 Opus 編解碼器中的一個可選項，在弱網傳輸場景下應該開啟這個特征。

PLC 代碼的實現根據收到的數據包模式的不同而有所不同：在 CELT 模式（audio）和 SILK 模式(speech)，PLC 分別采用不同的方式進行丟包補償。

圖13 Opus PLC 官方介紹

5、總結

最后，我們總結一下音頻RTC系統整體的結構，從系統角度分析一下，如圖15所示。

圖15 音頻 RTC 系統

今天分享了音頻 RTC 系統的弱網對抗技術與實踐，總結值得我們思考的幾個方面：

• 表面上的音頻卡頓，背后往往隱藏着各種各樣的問題，需要對各個問題逐一進行分析；
• RTC 系統的任意一個環節出問題，最終呈現給用戶的就是不足的音頻體驗；
• RTC 系統中各個模塊組成一個有機整體，如何有效適應復雜多變的網絡環境，將各個模塊弱網對抗的能力有機結合，從而發揮最大的作用，是一個頗具挑戰的課題，值得我們不斷探索。

以上，就是本次分享的全部內容，本次分享的視頻內容，可以點擊“這里”進行觀看。

作者介紹

崔承宗，網易雲信音視頻引擎專家，10余年音視頻引擎開發經驗，對 WebRTC 引擎、音視頻會議系統、視頻編解碼技術有一定研究和實踐經驗。