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

文｜崔承宗 網易云信資深音視頻引擎開發專家

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

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

?

常見音頻弱網卡頓現象

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

?

RTC 系統音頻的抗性

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

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

?抗丟包 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所示。

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

• 假設 10% 丟包：重傳一次失敗的概率 10% * 10% = 1%。

• 假設 50% 丟包：重傳一次失敗 50%*50%=25%，2次：25*50% = 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（波形形似同步疊加法）是一種基于語音信號準周期特性，進而插入基因周期整數倍的信號來實現波形長度變化的算法。?

?

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 官方介紹

?

總結

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

圖14 音頻 RTC 系統

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

• 表面上的音頻卡頓，背后往往隱藏著各種各樣的問題，需要對各個問題逐一進行分析；

• RTC 系統的任意一個環節出問題，最終呈現給用戶的就是不足的音頻體驗；

• RTC 系統中各個模塊組成一個有機整體，如何有效適應復雜多變的網絡環境，將各個模塊弱網對抗的能力有機結合，從而發揮最大的作用，是一個頗具挑戰的課題，值得我們不斷探索。

以上，就是本次分享的全部內容，本次分享的視頻內容，可以點擊“閱讀原文”或者掃碼進行觀看。

?作者介紹?

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

?延伸閱讀?

• 云信技術系列課｜淺談AWS Serverless開發與應用

• 云信技術系列課回顧視頻｜視頻直播關鍵技術和趨勢

?

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的云信技术系列课 | RTC 系统音频弱网对抗技术发展与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。