在?RTC 2019 第五屆實(shí)時(shí)互聯(lián)網(wǎng)大會(huì)的編解碼技術(shù)專場上，聲網(wǎng)開源了自研抗丟包音頻編解碼器Agora SOLO。
目前，編解碼器的源代碼已經(jīng)開源在 Github 上：https://github.com/AgoraIO-Community/Solo
這個(gè)開源項(xiàng)目兼容 WebRTC，可集成于多種場景下的實(shí)時(shí)音視頻應(yīng)用中，比如在線課堂、直播社交、游戲語音開黑、IoT 等。在分析它的特性之前，首先要講一下它名字中的一個(gè)關(guān)鍵詞，丟包。
丟包是什么？
盡管很多人開始使用 WebRTC 了，但是其中有不少人都對(duì)「丟包」的概念不是很熟悉。所以，首先我們要解釋一下。由于 SOLO 是音頻編解碼器，我們接下來講的場景，主要是指其中的實(shí)時(shí)音頻部分。
我們現(xiàn)在的互聯(lián)網(wǎng)生活中有各種各樣的實(shí)時(shí)音視頻互動(dòng)場景，比如：
- 泛娛樂社交：直播連麥、跨直播間 PK、游戲語音開黑等
- 在線教育：一對(duì)一教學(xué)、雙師課堂、大班課、在線音樂教室等
- 其它創(chuàng)新場景，包括 VR、機(jī)器人等
這些場景都需要通過網(wǎng)絡(luò)進(jìn)行實(shí)時(shí)傳輸。如果我們將互聯(lián)網(wǎng)看作為高速公路，那么音頻數(shù)據(jù)是一輛輛車。丟包就是有的車無法在有效時(shí)間內(nèi)無法達(dá)到終點(diǎn)，甚至可能永遠(yuǎn)也到不了終點(diǎn)。假如我們的一百輛車?yán)镉形遢v車沒能到達(dá)終點(diǎn)，我們這次車隊(duì)傳輸?shù)摹皝G包率”就是5%。是的，互聯(lián)網(wǎng)傳輸也一樣，它并不是百分百可靠的，總有數(shù)據(jù)無法按時(shí)傳輸?shù)侥康牡亍?/p>
如果丟包率大，會(huì)造成什么后果呢？
如果丟包比較嚴(yán)重，微信電話、視頻聊天或語音連麥的時(shí)候，你聽到的對(duì)方的聲音可能音質(zhì)很差，甚至是斷斷續(xù)續(xù)的，或者干脆沒有聲音。而這種情況在任何網(wǎng)絡(luò)下都可能出現(xiàn)。不論你是通過 Wi-Fi、4G 還是 5G，都可能因?yàn)檫M(jìn)入地下車庫、進(jìn)入電梯、信號(hào)覆蓋不良、網(wǎng)絡(luò)帶寬受限等原因，遇到這些實(shí)時(shí)音頻體驗(yàn)問題。所以，這就需要抗丟包策略，來保障音頻體驗(yàn)。
我們曾在一篇內(nèi)容中詳細(xì)講過傳統(tǒng)的抗丟包策略，在這里我們不贅述。然而，傳統(tǒng)的抗丟包策略不是會(huì)浪費(fèi)帶寬，就是會(huì)影響音頻質(zhì)量，所以我們結(jié)合信源和信道編碼的特點(diǎn)，利用充分包交換網(wǎng)絡(luò)的特性，基于此，研發(fā)出了抗丟包音頻編解碼器——Agora SOLO（以下簡稱“SOLO”）。
SOLO 是什么？
SOLO 是由聲網(wǎng)Agora自主研發(fā)的一款面向不穩(wěn)定網(wǎng)絡(luò)的音頻編解碼器。
更重要的是，SOLO 編解碼器兼容WebRTC。如果開發(fā)者正在基于 WebRTC 開發(fā)自己的應(yīng)用，可將 SOLO 集成到其中。
要知道，WebRTC 默認(rèn)使用的是 Opus 作為編解碼器，而 Silk 與 Opus 有千絲萬縷的聯(lián)系，我們曾經(jīng)在RTC 專欄的一篇投稿中講過。而 SOLO 則是以 Silk 為基礎(chǔ)，融合了帶寬擴(kuò)展(BWE)和多描述編碼(MDC)等技術(shù)，使其能在較低復(fù)雜度下?lián)碛腥蹙W(wǎng)對(duì)抗能力。也就是說，在 SOLO 的幫助下， WebRTC 應(yīng)用可以更好地應(yīng)對(duì)不穩(wěn)定的網(wǎng)絡(luò)環(huán)境，對(duì)音頻質(zhì)量與體驗(yàn)帶來有效的保障與提升。
根據(jù)我們此前的測試（如下圖），一個(gè)中文的女聲序列在不同編解碼器下的 MOS 分比較。第一列是不同的丟包率，后面各列是不同編解碼器在不同丟包率下的分?jǐn)?shù)。可以看到在丟包率25%時(shí)，SOLO 的 MOS 分比其它編解碼器有所提高。當(dāng)然，我們還在此前的內(nèi)容中公開過更多跑分的細(xì)節(jié)。
利用 SOLO，可以不再關(guān)心網(wǎng)絡(luò)丟包狀態(tài)，因?yàn)樗鼤?huì)默認(rèn)發(fā)兩個(gè)包。如果只收到一個(gè)就是有限失真，收到兩個(gè)就是高質(zhì)量的恢復(fù)。
下面，我們看一下 SOLO 編解碼器的架構(gòu)。
SOLO的抗丟包策略與傳統(tǒng)方法不同。從通信原理來說，信源編碼是盡可能去追求高壓縮比，去冗余。而信道編碼是追求強(qiáng)糾錯(cuò)，靠加冗余來實(shí)現(xiàn)糾錯(cuò)。SOLO 就是把加冗余和減冗余結(jié)合起來，不重要的地方減冗余，重要的地方加冗余。在傳輸過程中，它會(huì)將一個(gè)包拆分為兩個(gè)進(jìn)行傳輸，如果對(duì)端收到其中一個(gè)，則解碼恢復(fù)出一個(gè)有限失真的信號(hào)；如果對(duì)端收到兩個(gè)包，則可解碼恢復(fù)出一個(gè)高質(zhì)量的信號(hào)。即 SOLO 不需要等待對(duì)當(dāng)前網(wǎng)絡(luò)丟包狀態(tài)的統(tǒng)計(jì)，只需要直接把抗丟包做到編解碼內(nèi)部。好處有三點(diǎn)：1.可實(shí)現(xiàn)更低延時(shí)；2.可實(shí)現(xiàn)更高質(zhì)量，當(dāng)收到一個(gè)包時(shí)質(zhì)量達(dá)到的普通編解碼器水平，收到兩個(gè)包達(dá)到高質(zhì)量編解碼水平；3. 可面向多人環(huán)境。
SOLO 關(guān)鍵技術(shù)
一、帶寬擴(kuò)展
SOLO 使用帶寬擴(kuò)展的主要原因是希望減少計(jì)算復(fù)雜度，在 Silk WB 模式中，16khz 的信號(hào)都會(huì)進(jìn)入后續(xù)處理模塊，而對(duì)于語音來說，8khz 以上的信息是非常少的，這部分信息進(jìn)入到后續(xù)處理模塊，會(huì)帶來一定的計(jì)算資源浪費(fèi)。MDC 因?yàn)橐腩~外分析模塊處理多條碼流，又會(huì)引入額外的復(fù)雜度，這是 MDC 在近些年來落地不順暢的重要原因之一。為了減少復(fù)雜度，我們在編碼寬帶信號(hào)前，將其分為 0-8k 的窄帶信息和 8-16k 的高頻信息。只有窄帶信息會(huì)進(jìn)入到后續(xù)正常分析、編碼流程中，這樣后續(xù)的計(jì)算量就減少了一半，同時(shí)得益于帶寬擴(kuò)展算法，整體質(zhì)量不會(huì)有明顯下降。高頻信息部分，SOLO 使用獨(dú)立的分析與編碼模塊，默認(rèn)將高頻信息壓縮成 1.6kbps 的碼流。這部分高頻信息可以在解碼器內(nèi)結(jié)合低頻信號(hào)恢復(fù)出高頻信號(hào)。
二、結(jié)合 delay-decision 的 MDC
在 Silk 中，delay-decision 模塊是一個(gè)滯后計(jì)算編碼誤差的模塊，它可以從多個(gè)候選碼流中選擇誤差最小的碼流作為編碼輸出，一定程度上來說，它使得標(biāo)量量化擁有了矢量量化的性能。SOLO 利用 delay-decision 模塊，實(shí)現(xiàn)了多描述碼流的分析與構(gòu)建。SOLO 的MDC主要作用于濾波器輸出的殘差信號(hào)， SOLO 會(huì)根據(jù)當(dāng)前信號(hào)狀態(tài)，對(duì)殘差信號(hào)做多增益控制:計(jì)算出 MD 增益 a(0<a<1)，將 a 作用于奇數(shù)子幀，并將(1-a)作用于偶數(shù)子幀以產(chǎn)生兩段互補(bǔ)的殘差信號(hào)，這里記作 residual 1 和 residual 2。
隨后，這兩段殘差信號(hào)會(huì)進(jìn)入到新的 delay-decision 模塊中，每個(gè)殘差信號(hào)使用不同的抖動(dòng)和量化方法，一共可以產(chǎn)生 8 種不同的備選狀態(tài)，兩兩組合起來共有 64 種備選合成狀態(tài)，新的 delay-decision 模塊會(huì)對(duì)每個(gè)殘差信號(hào)的獨(dú)立誤差和兩個(gè)殘差信號(hào)的合成誤差進(jìn)行加權(quán)求和，決定出最佳的兩個(gè)殘差信號(hào)進(jìn)入到編碼模塊。
三、輸出碼流組包
SOLO 默認(rèn)配置為每次輸入 40ms(2 幀)，輸出兩段互補(bǔ)的多描述碼流，解碼器接收到任一段碼流，即可解碼出 40ms 的信號(hào)。為了方便接收端區(qū)分碼流的順序，碼流第一個(gè)字節(jié)的右數(shù)第 4 個(gè) bit 是碼流順序標(biāo)志位，第一段碼流標(biāo)志位的值是 0，第二段碼流標(biāo)志位的值是 1。接收端在進(jìn)行碼流處理時(shí)，可依據(jù)此標(biāo)志位進(jìn)行碼流順序判斷。
SOLO 已在 Github 開源，請點(diǎn)擊這里跳轉(zhuǎn) Github。當(dāng)然，如果你對(duì)于SOLO 有任何疑問，歡迎在?RTC 開發(fā)者社區(qū)中討論。
