導(dǎo)讀：本文整理自線上直播【MCtalk Live#2 ：RTC 系統(tǒng)音頻弱網(wǎng)對抗技術(shù)發(fā)展與實(shí)踐】網(wǎng)易云信資深音視頻引擎開發(fā)專家崔承宗分享內(nèi)容，文末也可查看直播回顧視頻。

文｜崔承宗 網(wǎng)易云信資深音視頻引擎開發(fā)專家

RTC（Real Time Communication）系統(tǒng)廣泛應(yīng)用在視頻會(huì)議、在線醫(yī)療、泛娛樂、在線教育等實(shí)時(shí)互動(dòng)場景，為用戶提供低延時(shí)、高清晰度和流暢度、高保真音質(zhì)的實(shí)時(shí)互動(dòng)體驗(yàn)。音頻弱網(wǎng)對抗技術(shù)旨在提升 RTC 系統(tǒng)在弱網(wǎng)（高丟包、大抖動(dòng)、高延遲）條件下的用戶體驗(yàn)。

本文從 RTC 系統(tǒng)的音頻弱網(wǎng)效果、弱網(wǎng)對抗的諸多技術(shù)以及 RTC 系統(tǒng)層面進(jìn)行較為詳盡的分析，希望可以幫助大家對 RTC 系統(tǒng)的音頻弱網(wǎng)對抗技術(shù)有所了解。

?

常見音頻弱網(wǎng)卡頓現(xiàn)象

實(shí)際場景中常見的音頻弱網(wǎng)卡頓現(xiàn)象有如下表所示幾種情況：

?

RTC 系統(tǒng)音頻的抗性

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

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

?抗丟包 FEC?

前向糾錯(cuò)也叫前向糾錯(cuò)碼（Forward Error Correction，簡稱 FEC），是增加數(shù)據(jù)通信可信度的方法。FEC 利用數(shù)據(jù)進(jìn)行冗余信息的傳輸，當(dāng)傳輸中出現(xiàn)數(shù)據(jù)丟失時(shí)，將允許接收端根據(jù)已經(jīng)接收的數(shù)據(jù)恢復(fù)丟失數(shù)據(jù)。

如下圖所示，我們可以看到，發(fā)送端將數(shù)據(jù)包根據(jù)冗余度參數(shù)進(jìn)行分組 (block)，對分組數(shù)據(jù)增加冗余。接收端在收齊分組后，即可恢復(fù)丟失數(shù)據(jù)（條件是丟失不超過冗余包數(shù)）。因?yàn)榻邮斩艘却?FEC 分組到齊，所以存在 FEC 恢復(fù)算法上的延時(shí)， FecDelay = Block 個(gè)數(shù) * 幀長。

圖1 發(fā)送端和接收端的 FEC 處理示意圖

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

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

下面簡單介紹一下 Reed Solomon 算法的數(shù)學(xué)背景。

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

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

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

• 利用高斯消元法(Gaussian elimination) ，恢復(fù)損壞的數(shù)據(jù)塊 （即算冗余矩陣的逆矩陣）。

• 為了方便計(jì)算機(jī)處理，所有的運(yùn)算是在伽羅華域 Galios, GF(2^w) 的基礎(chǔ)上進(jìn)行。

?抗丟包 RED?

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

我們舉一個(gè)實(shí)際的例子：一個(gè) RTP 音頻數(shù)據(jù)包，包括一個(gè) DVI4(8KHz) 主編碼塊和一個(gè)單獨(dú)的 8KHz LPC 編碼的冗余塊，兩者長度均為 20ms。參照 RFC 2198 標(biāo)準(zhǔn)所定義，示例格式如圖3所示。

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

?抗丟包 ARQ?

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

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

圖4 發(fā)送端和接收端的 ARQ 處理示意圖

假設(shè)是隨機(jī)均勻丟包場景，重傳失敗率概率為：Pn = P(n-1)*lossrate。對于音頻來說，假設(shè)當(dāng)重傳失敗概率 Pn<1% 時(shí)，認(rèn)為重傳成功，那么 n 就是重傳成功所需的次數(shù)（截?cái)喽M(jìn)制指數(shù)退避算法）。

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

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

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

• 假設(shè) 50% 丟包：重傳一次失敗 50%*50%=25%，2次：25*50% = 12.5%，4次: 3.125%，6次：0.78%。

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

• 請求重傳模塊記錄并緩存所有重傳數(shù)據(jù)包的重傳成功所消耗的時(shí)間，并將重傳延時(shí) Arq Delay 告知 JitterBuffer 模塊，提高了數(shù)據(jù)的緩沖等待時(shí)長的高可控性，參見(6)。

• 接收端通過 ARQ 請求，在數(shù)據(jù)緩沖隊(duì)列的數(shù)據(jù)幀被播放之前，當(dāng)還未重傳成功的數(shù)據(jù)幀在已經(jīng)達(dá)到播放時(shí)間時(shí)，接收端通過 ACK 通知取消請求重傳，減少無用請求，參見(5)

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

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

ARQ 策略在使用中的難點(diǎn)是合理把握 NACK 請求的時(shí)機(jī)和間隔以及重傳包的碼率控制，防止誤請求、多請求和多重傳，尤其在抖動(dòng)場景下需要格外關(guān)注。

?抗抖動(dòng)?

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

圖6 RTC 系統(tǒng)的抗抖動(dòng)模塊原理示意圖

抗抖動(dòng)模塊重要的組成部分之一是網(wǎng)絡(luò)抖動(dòng)的預(yù)測。抗抖動(dòng)模塊根據(jù)網(wǎng)絡(luò)抖動(dòng)的預(yù)測結(jié)果自適應(yīng)調(diào)節(jié)Jitterbuffer長度，以達(dá)到抗抖動(dòng)的目的，并能夠在網(wǎng)絡(luò)無抖動(dòng)的時(shí)候保證低延時(shí)。抗抖動(dòng)模塊的抖動(dòng)預(yù)測模塊原理如圖7和8所示。

Jitterbuffer 模塊的網(wǎng)絡(luò)延時(shí)估計(jì)是以 IAT（inter arrival time）為基礎(chǔ)的。IAT 的含義是相鄰包到達(dá)時(shí)間間隔。通話時(shí)間越長，包間隔 IAT 的概率分布越穩(wěn)定。觀察周期內(nèi) IAT 的整體概率分布之和近似為1。一般采用 95% 作為滿足統(tǒng)計(jì)概率的閾值，計(jì)算出 Jitterbuffer 的目標(biāo)值大小。

圖7 抗抖動(dòng)模塊的抖動(dòng)預(yù)測原理1

圖8 抗抖動(dòng)模塊的抖動(dòng)預(yù)測原理2

抖動(dòng)預(yù)測之后，需要對 buffer 中音頻數(shù)據(jù)進(jìn)行調(diào)節(jié)，常用的做法是進(jìn)行加減速播放。在需要拉伸 jitterbuffer 的時(shí)候進(jìn)行慢放操作，在需要壓縮 jitterbuffer 的時(shí)候進(jìn)行快放操作。

語音時(shí)長修正（Time Scale Modification, TSM）是一種通過擴(kuò)展或者壓縮語音長度，從而改變語音速度的技術(shù)。在進(jìn)行時(shí)域壓縮或者擴(kuò)展的同時(shí)，還應(yīng)盡量保證語音信號的基音頻率及音色—即變長不變調(diào)。

Wsola（波形形似同步疊加法）是一種基于語音信號準(zhǔn)周期特性，進(jìn)而插入基因周期整數(shù)倍的信號來實(shí)現(xiàn)波形長度變化的算法。?

?

RTC 系統(tǒng)音頻的編解碼

在介紹了 RED、ARQ 和抗抖動(dòng)等弱網(wǎng)對抗技術(shù)之后，我們再介紹一下基于音頻編解碼器實(shí)現(xiàn)的弱網(wǎng)對抗技術(shù)。

如下圖，說明了各種編解碼器的質(zhì)量與碼率的關(guān)系：

圖9 音頻編碼器碼率和質(zhì)量對比圖

圖中綠色線條代表的是無專利要求且開源的編解碼器，其中 G.711 和 G.722 是 ITU 早期應(yīng)用于電信網(wǎng)絡(luò)的語音編碼標(biāo)準(zhǔn)，相應(yīng)只支持窄帶和寬帶頻率范圍，碼率相對固定，壓縮率較低。藍(lán)色線條代表的是無專利要求但是閉源的編解碼器，相比 G.711 和 G.722，它們支持的頻帶更廣。最后，紅色線條代表的是有專利要求并且閉源的編解碼器，其中 AAC 和 MP3 是 Fraunhofer 主導(dǎo)制定的音樂編解碼器標(biāo)準(zhǔn)，廣泛應(yīng)用在數(shù)字音樂領(lǐng)域。

圖10 則說明了各種編碼器的編碼延遲與碼率的關(guān)系：

圖10 音頻編碼器碼率和編碼延時(shí)對比圖

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

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

• 支持動(dòng)態(tài)碼率

• 在同等碼率水平（高于 8kbps），其質(zhì)量高于其他音頻編碼器

• 其編碼延遲低于其他音頻編碼器

?帶內(nèi) FEC?

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

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

具體到 Opus 編碼器內(nèi)部實(shí)現(xiàn)，inband FEC 是通過 LBRR（Low Bitrate Redundant）幀實(shí)現(xiàn)的。LBRR 幀包含了前一個(gè)音頻幀的信息，和當(dāng)前幀一起打包編碼。圖12是 LBRR 幀的編碼代碼。

圖12 Opus 帶內(nèi) low bitrate redundant(LBRR)

?PLC?

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

PLC（Packet Loss Concealment）丟包補(bǔ)償是 Opus 編解碼器中的一個(gè)可選項(xiàng)，在弱網(wǎng)傳輸場景下應(yīng)該開啟這個(gè)特征。

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

圖13 Opus PLC 官方介紹

?

總結(jié)

最后，我們總結(jié)一下音頻 RTC 系統(tǒng)整體的結(jié)構(gòu)，從系統(tǒng)角度分析一下，如圖14所示。

圖14 音頻 RTC 系統(tǒng)

今天分享了音頻 RTC 系統(tǒng)的弱網(wǎng)對抗技術(shù)與實(shí)踐，總結(jié)值得我們思考的幾個(gè)方面：

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

• RTC 系統(tǒng)的任意一個(gè)環(huán)節(jié)出問題，最終呈現(xiàn)給用戶的就是不足的音頻體驗(yàn)；

• RTC 系統(tǒng)中各個(gè)模塊組成一個(gè)有機(jī)整體，如何有效適應(yīng)復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，將各個(gè)模塊弱網(wǎng)對抗的能力有機(jī)結(jié)合，從而發(fā)揮最大的作用，是一個(gè)頗具挑戰(zhàn)的課題，值得我們不斷探索。

以上，就是本次分享的全部內(nèi)容，本次分享的視頻內(nèi)容，可以點(diǎn)擊“閱讀原文”或者掃碼進(jìn)行觀看。

?作者介紹?

崔承宗，網(wǎng)易云信資深音視頻引擎開發(fā)專家，10余年音視頻引擎開發(fā)經(jīng)驗(yàn)，對 WebRTC 引擎、音視頻會(huì)議系統(tǒng)、視頻編解碼技術(shù)有一定研究和實(shí)踐經(jīng)驗(yàn)。

?延伸閱讀?

• 云信技術(shù)系列課｜淺談AWS Serverless開發(fā)與應(yīng)用

• 云信技術(shù)系列課回顧視頻｜視頻直播關(guān)鍵技術(shù)和趨勢

?

與50位技術(shù)專家面對面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。