本文分享了聲網(wǎng)Agora 首席音頻工匠高澤華在 RTC 2018 實(shí)時互聯(lián)網(wǎng)大會上，以《SOLO X?：兼容 WebRTC 標(biāo)準(zhǔn)的抗丟包語音編碼器》為題的演講。主要介紹了聲網(wǎng)推出的抗丟包語音編碼器 Agora SOLO? 的算法特點(diǎn)，以及第二代編解碼器 Agora SOLO X? 的新特性與測試效果。以下為演講實(shí)錄。

去年，我們在 RTC 大會上分享了自主研發(fā)的抗丟包編解碼方案 Agora SOLO? ，主要是面向抗丟包網(wǎng)絡(luò)，解決實(shí)時通信傳輸 last mile 的問題。

1

關(guān)于Agora SOLO?

有時，大家對丟包問題會有一些誤解。很多人認(rèn)為隨著 4G 的普及和 5G 的建設(shè)，是不是丟包問題變得不重要了？我認(rèn)為并不是這樣，因?yàn)樵诂F(xiàn)有網(wǎng)絡(luò)條件下，不論是 server 到 server，還是 sever 到 last mile 都存在著大量的丟包問題。

我們談到丟包就涉及到丟包的概念，到底什么叫做丟包？其實(shí)任何沒有按時到達(dá)的包都是丟包。如果把一個包的延時拉到足夠大，一般來說，我們可以通過無數(shù)次重傳來解決丟包問題。如果這個包沒有在規(guī)定的時間到達(dá)，都算丟包。而且，丟包也不一定是網(wǎng)絡(luò)原因?qū)е拢袝r候是由于系統(tǒng)的調(diào)度等原因造成。

舉個例子。通常，Android 系統(tǒng)上播放線程、解碼線程和收包線程都可以不是一個線程。Android 并不是特別實(shí)時的操作系統(tǒng)。一旦系統(tǒng)比較忙的時候，就容易產(chǎn)生收包線程和解碼線程的沖突，導(dǎo)致丟包產(chǎn)生。而這種丟包是由于系統(tǒng)產(chǎn)生的。甚至在解碼時，解碼器完成解碼后交給播放器播放，其中的 buffer 也會導(dǎo)致卡頓。

丟包也與帶寬限制相關(guān)。如果帶寬足夠大，可以通過無數(shù)次重傳來實(shí)現(xiàn)抗丟包效果。但如果帶寬很有限，就不能完全依靠無限制的重傳來實(shí)現(xiàn)抗丟包效果。

比如說，曾經(jīng)聯(lián)通做過這樣的事情，流量包月，但每個月的帶寬只能在 128kbps，滿足你對網(wǎng)頁和音視頻的基本需求。在這種服務(wù)下，如果你開一些高性能或者大碼率的信源通訊的時候就會產(chǎn)生帶寬擁塞，帶寬擁塞首先導(dǎo)致延時增加，下一步就會產(chǎn)生丟包。所以，實(shí)際上帶寬和丟包也相關(guān)。

由于我們聲網(wǎng)在全球布網(wǎng)，非洲、東南亞、中東和印度的網(wǎng)絡(luò)狀況與中國的網(wǎng)絡(luò)狀況相差還比較遠(yuǎn)。即使在中國的網(wǎng)絡(luò)環(huán)境下，上海和偏遠(yuǎn)地區(qū)的網(wǎng)絡(luò)狀況也是不一樣的。所以，并不是以后上了 5G 就不存在丟包問題了，相反，我認(rèn)為隨著網(wǎng)絡(luò)的差異化會導(dǎo)致丟包的問題變得越來越普遍。

舉一個例子，描述一下什么情況會產(chǎn)生丟包？如上圖所示為典型的丟包模型，device 1 與 device 2、device 3、device 4 進(jìn)行通信。比如，device 1，把 packet 1、packet 2、packet 3 一起發(fā)給 device 2，packet 1、packet 2、packet 3 丟了一個包是 packet 2。在這個時間窗口計(jì)算丟包率時，當(dāng)前的丟包率是 33%。此時 device 2 會給 device 1 發(fā)回一個回傳控制，即 loss info，loss info 帶上丟包率是 33% 的信息。根據(jù)這個信息，device 1 會重新對 device 2 進(jìn)行抗丟包的處理，發(fā)兩個 packet 4 和兩個 packet 5。那么，當(dāng)丟了一個 packet 4 時，還有一個 packet 4 可以起到抗丟包的效果。也就是說，在整個系統(tǒng)中，在第一個時間窗口，packet 1、packet 2、packet 3，在這 3 個包內(nèi)算丟包率，再把丟包率回傳到 device 1，由 device 1 根據(jù)丟包率的信息，去發(fā)送抗丟包的冗余。

在其中，我們會發(fā)現(xiàn)幾個問題。第一是時間窗口問題。如果按照 3 個時間窗口來算，丟包率是 33%。如果按照 4 個時間窗口算，丟包率是 25%。如果按照 2 個時間窗口算，丟包率是 50%。這就產(chǎn)生一個問題，即丟包率算的其實(shí)沒有那么準(zhǔn)。

第二，device 2 接收到 device 1 發(fā)送的包之后，會回傳一個 loss info 給 device 1。一般來講，loss info 中會加入一些 FEC 的控制，保證它不會被丟。但實(shí)際上 loss info 的包仍可能會丟失。

我們假設(shè)上述情況中 loss info 沒有丟包，device 1 發(fā)送冗余的包給 device 2，譬如發(fā)送兩個 packet 4 和兩個 packet 5。由于此時的丟包率是 33%。那么 packet 4 丟掉之后，對于 packet 4 來說，起到了抗丟包的效果，但是對于 packet 5 來說，發(fā)的兩個 packet 5 并沒有起到抗丟包的效果，這對網(wǎng)絡(luò)帶寬是浪費(fèi)的。

再假設(shè)前面窗口也取準(zhǔn)了，loss info 也沒有丟，packet 4、packet 5 也都取得了抗丟包的效果，還是會存在一個問題。在回傳的信道中已經(jīng)有很長的 RTT 在里面，發(fā)過去一個包，device 2 進(jìn)行估算，估算后，再發(fā)送一個 loss info 回到 device 1。如果 RTT 太長，發(fā)包的過程中還是會不斷出現(xiàn)丟包。也就是在長 RTT 的情況下，這種抗丟包方案的效果是比較有限，或者可以說存在一些缺陷。

我們還可以假設(shè)以上問題都不存在。在多人通話中，每個設(shè)備接收端的網(wǎng)絡(luò)環(huán)境不同，假設(shè) device 1 與 device 2 之間是 3G 或有損的 Wi-Fi 環(huán)境，而 device 3、device 4 分別使用 4G、5G。那么，device 1 在處理loss info 時應(yīng)該采取什么策略呢？如果都加入 FEC 的話，就意味著浪費(fèi)了 device 3 和 device 4 的帶寬，但如果不想浪費(fèi)帶寬，沒有 FEC ，就意味著無法實(shí)現(xiàn)對 device 2 的抗丟包效果。

所以在多人環(huán)境下，網(wǎng)絡(luò)帶寬的差異化是做網(wǎng)絡(luò)策略時要考慮的重要因素。同時，還有一些人為或成本因素需要我們在做網(wǎng)絡(luò)策略時進(jìn)行綜合考慮。例如，在中國與印度之間進(jìn)行實(shí)時通信時，其中一個 server 在印度當(dāng)?shù)兀梢灾苯优c中國的 server 進(jìn)行連接。但印度的通信成本較高，會產(chǎn)生一定的資費(fèi)。這時我們可以選擇通過新加坡的 server 繞個遠(yuǎn)，但這個過程又會產(chǎn)生一些丟包問題。

2

Agora SOLO? 的優(yōu)勢在哪兒？

在多人環(huán)境下，傳統(tǒng)的抗丟包策略無法很好解決這類問題，所以聲網(wǎng)在去年 10 月份推出了一個新的編碼器叫 Agora SOLO?。

一段音頻信號通過 Agora SOLO? 處理后，會生成兩個成對的包 packet 1 和 packet 2 ，它們?yōu)橥粠⑶一パa(bǔ)。即我收到一個 packet 1 的時候，我可以解碼出一個 8kbps 的窄帶音頻信號，如果我收到一個 packet 2，也可以解碼出一個 8kbps 的窄帶音頻信號，但如果我同時收到一個packet1 和一個packet 2，我就可以恢復(fù)出一個 16kbps 的寬帶高質(zhì)量音頻信號。

一定程度上講，這個編解碼器可以解決剛才提到的 FEC 遇到的所有抗丟包的策略問題。

通常，編解碼器做的事情是壓縮、去冗余，而抗丟包從一定程度上講是信道處理的擴(kuò)大化。抗丟包是一種糾錯算法的擴(kuò)展，通過加冗余實(shí)現(xiàn)抗丟包。而對于 Agora SOLO? 來說，是把去冗余和加冗余進(jìn)行結(jié)合，對重點(diǎn)信息加冗余，對非重點(diǎn)信息則更多的去冗余，以達(dá)到在信道和信源的聯(lián)合編碼的效果。

我們強(qiáng)調(diào)了在編碼器上加一定的冗余去抗丟包，實(shí)際上就會帶來一些編碼效率的降低。但這種情況下，我們可以通過增加一些新的算法，減少編碼效率的降低。并且，和原始的 codec 編碼效率相比，從結(jié)果上看還要更好一些。

上圖是我們用 ITU NTT 的中文測試序列跑的測試結(jié)果。稍微介紹一下，ITU 的 NTT 是標(biāo)準(zhǔn)的編解碼器測試序列，里面有 26 國語言，這里只拿出了中文部分的測試結(jié)果。那么橫坐標(biāo)內(nèi)的 PESQ 是窄帶編碼器的客觀測試標(biāo)準(zhǔn)，最后一列，PESQ-WB 是寬帶編解碼的客觀測試標(biāo)準(zhǔn)，滿分是 5 分，通常打到 4 分就是完美了。后面有我們這個編碼器與一些傳統(tǒng)編碼器在 PESQ 分?jǐn)?shù)的對比。

我們可以看到，是只收到 8kbps 的 packet 1， PESQ 的 MOS 分是 3.52 分。如果只收到 packet2，MOS 分是 3.51 分。如果 packet1 和 packet2 都收到，在16kbps 時，MOS 分是 3.95 分。以上是窄帶的分?jǐn)?shù)。寬帶下的 PESQ 的 MOS 分是 3.582 分。

用新的編碼器后，我們再看一下它的效果。此時就不需要再考慮是否加 loss info，我們可以直接從 device 1 給所有的 device 2、device 3、device 4 發(fā) packet 1、packet 1’、packet 2、packet 2’、packet 3、packet 3’的包。

為什么可以這樣做？因?yàn)閷?shí)際上，如果 packet 1 或者 packet 1’ 丟包，不會有太大影響，你仍然可以恢復(fù)出一個有限的 8kbps 質(zhì)量的音頻數(shù)據(jù)。如果沒有丟包，收到了 packet 1、packet 1'，就可以恢復(fù)出 16kbps 的音頻數(shù)據(jù)，其中并沒有任何的冗余信息。這種算法不像原來的 FEC，兩個包完全相等，或者一大一小，那會造成帶寬浪費(fèi)。這種算法不會造成帶寬浪費(fèi)，那么你就無需考慮以下問題：

第一，延時問題；

第二，回傳 loss info 的丟包問題；

第三，多人通信中，每個網(wǎng)絡(luò)帶寬不一致的問題。

總體來說，這個編碼器被我稱為接近完美的抗丟包編解碼，因?yàn)闆]有完美的編解碼器。

Agora SOLO? 有如下四個特點(diǎn)：

第一，更低延時。無需回傳信道丟包信息，默認(rèn)發(fā)送多倍數(shù)據(jù)；

第二，更高質(zhì)量。收到一個包質(zhì)量可達(dá)到普通編解碼器水平，收到兩個包質(zhì)量即可達(dá)到高質(zhì)量編解碼的水平；

第三，面向多人環(huán)境；

第四，簡化策略。無需策略調(diào)整，不擔(dān)心策略顆粒度問題。

所以從抗丟包的四種方法（FEC、PLC、ARC、ARQ）來看，需要想盡各種辦法去做 balance。但有了這種方法后，你無需考慮太多，直接調(diào)用即可。另外在有限的成本下，如果同時使用一條高質(zhì)量的高成本的服務(wù)器的帶寬和一條低成本相對有丟包下的帶寬時，你可以發(fā)兩條流，分別是 packet 1 和 packet 1’，這樣可以起到更好的效果。

如上圖所示，是我們做的 Agora SOLO? 和其他編碼器的對比。從圖中我們可以很快發(fā)現(xiàn)ILBC 和 AMR-NB 的 MOS 分比較低，這是由于它們倆是上個時代的編碼器，因此屬于正常現(xiàn)象。

SILK 和 Opus 的 MOS 分比較高，但我們會發(fā)現(xiàn) SILK+FEC20 時，基礎(chǔ) MOS 分會下降得非常厲害，因?yàn)槟靡徊糠謳捜プ鋈哂嗑蜁?dǎo)致基礎(chǔ) MOS 分下降。

而 Opus+FEC20 時，實(shí)際上編不出在丟包 5% 時的碼率，因?yàn)榇a率控制的設(shè)計(jì)相對比較保守。但我們可以看到它加 FEC20 后，基礎(chǔ) MOS 分在下降。

而 Agora SOLO? 的基礎(chǔ) MOS 分和 SILK、Opus 幾乎一樣，下降在 0.2 之內(nèi)。而它在抗丟包時，一旦發(fā)生丟包，幾乎沒有 MOS 分下降。在丟包 5%、10%、15%、20% 時，它的 MOS 分維持在一個相對穩(wěn)定的情況，和競品比有時候可以達(dá)到 1 分的差距。

做過通信 MOS 分競品比較的人應(yīng)該知道，高 0.3-0.5 分已經(jīng)是非常困難，高 1 分幾乎是不可能。以 20% 為例，Agora SOLO? 的 MOS 分是 3.2，而 SILK 卻只有 2.2 和 2.3，雖然加上 FEC20 后是 3.0，但加上 FEC 后 SILK 的基礎(chǔ) MOS 分會比較低。

這是 ITU NTT 的中文測試第一條序列——女聲。女聲相對來說比較難編，因?yàn)橹袊苏f話有四聲問題，比其他語言更復(fù)雜。女聲的高頻信息比男聲更豐富，所以編起來也會更難。

由圖可知，SILK16 的 MOS 分是 3.5，SILK16+FEC 編不出來，Opus16 的 MOS 分是 3.5，Opus16+20FEC 的 MOS 分是 3.3，Opus20+20FEC 的 MOS 分是 2.8。雖然碼率更高了，但由于帶寬原因，給 FEC 的碼率更高，它的內(nèi)核碼率反而更低，所以它的基礎(chǔ) MOS 分變得很低。

而 Agora SOLO? 的 基礎(chǔ) MOS 分是 3.5，在不丟包的情況下它和 Opus16 和 SILK16 的 MOS 分基本一致。在丟包的情況下，以 20% 為例，它的 MOS 分是 2.5，比其他都高，這就是 Agora SOLO?。

3

Agora SOLO? 的模擬測試結(jié)果

我們不僅做了線下 ITU 的網(wǎng)損測試，還做了線上的模擬測試。如上圖所示，我們用兩臺 iPhone 去做模擬丟包的測試，device A 經(jīng)過 Wi-Fi、內(nèi)網(wǎng) VOS 和 Wi-Fi，去和 device B 通信。

這是我們的測試結(jié)果。紅色是丟包率，綠色是丟幀率。從圖中我們可以看到，丟包率原本是 50% 左右，經(jīng)過 Agora SOLO? 之后，它的丟幀率只剩 20%。NOVA 是我們的另一個編碼器，它的丟包率和丟幀率都是 50%，沒有做任何的 FEC。

當(dāng)采用一包兩幀策略做抗丟包的時候，在 20% 的丟包率下，Agora SOLO? 基本沒有丟幀的產(chǎn)生。而傳統(tǒng)的編碼器下，丟幀率還是有一定的損失。

4

兼容 WebRTC 標(biāo)準(zhǔn)的抗丟包語音編碼器SOLO X?

過去一年里，我們把 Agora SOLO? 編碼器的抗丟包部分移植到了 OPUS 上，我們給這個技術(shù)起了一個新的名字叫分組譜互補(bǔ)技術(shù)，并開發(fā)了一個新的編碼器叫SOLO X?。

SOLO X?算法和 SOLO? 是一樣的，那我們直接看結(jié)果上的差異。

16kbps 時，我們可以看到 SOLO X?的 MOS 分會下降到 3.2。它的抗丟包的效果在 20% 的時候是 2.4，和 Agora SOLO? 差不多，比 Opus20 和 Opus16 都要好。

如果是 20kbps 時，它的 MOS 分是 3.46。在丟包 20% 時，它的 MOS 分是 2.6 ，還是比 Opus16+20FEC、Opus20+20FEC 的效果好，基礎(chǔ) MOS 分也高。

它的優(yōu)勢主要是和 OPUS 結(jié)合后，可以與 OPUS 互相兼容。用聲網(wǎng) Native 的 SDK 和 WebRTC 的 SDK 進(jìn)行互通時，如果它支持 SOLO X? 編碼器，它就可以解出兩條更高質(zhì)量的流。而為了做到兼容，會有一些質(zhì)量損失，導(dǎo)致SOLO X? 在 16kbps 的 MOS 分比 SOLO? 要下降一些，這也是我們后期優(yōu)化的主要方向。

對于 8kHz 來看，為了起到兼容的效果，它的基礎(chǔ) MOS 分也有下降，但是它的抗丟包效果沒有明顯下降。

圖：SOLO X? 在 ITU NTT 的跑分結(jié)果

和 WebRTC 做兼容后，我們對 WebRTC 的互通做了測試。 googDecodingPLC 的意義是加了網(wǎng)損后，當(dāng)外邊沒有收到包時，會調(diào)用 googDecodingPLC 函數(shù)去解碼，做后端的抗丟包補(bǔ)償。圖中右側(cè)縱軸的單位是幀，即這段時間內(nèi)補(bǔ)償了多少幀來做抗丟包。如果我們實(shí)現(xiàn)了抗丟包的效果，則不用調(diào)大量后端 PLC 做補(bǔ)償。

從上圖數(shù)據(jù)可以看到，在只使用 OPUS 編碼器時，在 20% 和 40% 的丟包模擬下，可以看到 5 分鐘以內(nèi)補(bǔ)償幀數(shù)分別在 6 千次和 11 千次左右。用SOLO X? 時，20% 丟包的情況下，補(bǔ)償幀只有 1K 多一點(diǎn)。40% 丟包時，丟包補(bǔ)償幀只有 4K 左右，可以看到明顯下降，這意味著已經(jīng)有更多的包到達(dá)解碼端，不需要調(diào)用 PLC 做補(bǔ)償。

5

SOLO X? 和 WebRTC 互通中的數(shù)據(jù)表現(xiàn)

如上圖所示，是我們在兼容模式和非兼容模式下的 PESQ-MOS 分。前面給的數(shù)據(jù)都是兼容 Opus 編碼器的 MOS 分，而非兼容模式下 PESQ-MOS 分可以做的更高。

實(shí)際上這張圖也是 PESQ-WB 的 MOS 分，理論上，我們應(yīng)該用 POLQA 去比分，那么在 48kHz，48kbps 和 32kHz，32kps 去比，MOS 分的差異和影響對比會更大。因?yàn)閷Ω哳l的權(quán)重越高，一旦有損失就會導(dǎo)致分比較低。這也是為什么幾乎相同的對比策略和解碼輸出， PESQ-WB 的分比 PESQ 的分要低的原因。

在非兼容模式下，它的 MOS 分會遠(yuǎn)遠(yuǎn)高于兼容模式。后期我們會針對兼容模式進(jìn)行優(yōu)化，我覺得是有機(jī)會達(dá)到接近非兼容模式時的效果的。

6

Agora SOLO? 的下一步

2017 年，我們花了兩年時間把 SOLO? 的編碼器做了出來，今年做 SOLO X? 目的是與 OPUS 互通，目前主要做 Voice 這一塊，計(jì)劃 2019 年推出針對音樂的編碼器，相信效果會更突出，因?yàn)橐魳吩趯?shí)際產(chǎn)生中都是使用 128k 或者 196K 的碼率，這種碼率下做 FEC 的代價會非常非常高。

最后我想說，對創(chuàng)業(yè)公司來說花大力氣做編解碼是很吃虧的事情。因?yàn)樽鼍幋a器很累，也很苦，普通公司通常不會去做。所以我很感謝聲網(wǎng)給我這個機(jī)會，也感謝 Tony 的鼓勵。坦白講，無數(shù)的不眠之夜，整夜整夜的失眠才做出了 Agora SOLO? 和 SOLO X?。