去年，我們在 RTC 大會上分享了自主研發(fā)的抗丟包編解碼方案 Agora SOLO ，主要是面向抗丟包網(wǎng)絡，解決實時通信傳輸 last mile 的問題。
1、關于Agora SOLO
有時，大家對丟包問題會有一些誤解。很多人認為隨著 4G 的普及和 5G 的建設，是不是丟包問題變得不重要了？我認為并不是這樣，因為在現(xiàn)有網(wǎng)絡條件下，不論是 server 到 server，還是 sever 到 last mile 都存在著大量的丟包問題。
我們談到丟包就涉及到丟包的概念，到底什么叫做丟包？其實任何沒有按時到達的包都是丟包。如果把一個包的延時拉到足夠大，一般來說，我們可以通過無數(shù)次重傳來解決丟包問題。如果這個包沒有在規(guī)定的時間到達，都算丟包。而且，丟包也不一定是網(wǎng)絡原因?qū)е拢袝r候是由于系統(tǒng)的調(diào)度等原因造成。
舉個例子。通常，Android 系統(tǒng)上播放線程、解碼線程和收包線程都可以不是一個線程。Android 并不是特別實時的操作系統(tǒng)。一旦系統(tǒng)比較忙的時候，就容易產(chǎn)生收包線程和解碼線程的沖突，導致丟包產(chǎn)生。而這種丟包是由于系統(tǒng)產(chǎn)生的。甚至在解碼時，解碼器完成解碼后交給播放器播放，其中的 buffer 也會導致卡頓。
丟包也與帶寬限制相關。如果帶寬足夠大，可以通過無數(shù)次重傳來實現(xiàn)抗丟包效果。但如果帶寬很有限，就不能完全依靠無限制的重傳來實現(xiàn)抗丟包效果。
比如說，曾經(jīng)聯(lián)通做過這樣的事情，流量包月，但每個月的帶寬只能在 128kbps，滿足你對網(wǎng)頁和音視頻的基本需求。在這種服務下，如果你開一些高性能或者大碼率的信源通訊的時候就會產(chǎn)生帶寬擁塞，帶寬擁塞首先導致延時增加，下一步就會產(chǎn)生丟包。所以，實際上帶寬和丟包也相關。
由于我們聲網(wǎng)在全球布網(wǎng)，非洲、東南亞、中東和印度的網(wǎng)絡狀況與中國的網(wǎng)絡狀況相差還比較遠。即使在中國的網(wǎng)絡環(huán)境下，上海和偏遠地區(qū)的網(wǎng)絡狀況也是不一樣的。所以，并不是以后上了 5G 就不存在丟包問題了，相反，我認為隨著網(wǎng)絡的差異化會導致丟包的問題變得越來越普遍。
舉一個例子，描述一下什么情況會產(chǎn)生丟包？如上圖所示為典型的丟包模型，device 1 與 device 2、device 3、device 4 進行通信。比如，device 1，把 packet 1、packet 2、packet 3 一起發(fā)給 device 2，packet 1、packet 2、packet 3 丟了一個包是 packet 2。在這個時間窗口計算丟包率時，當前的丟包率是 33%。此時 device 2 會給 device 1 發(fā)回一個回傳控制，即 loss info，loss info 帶上丟包率是 33% 的信息。根據(jù)這個信息，device 1 會重新對 device 2 進行抗丟包的處理，發(fā)兩個 packet 4 和兩個 packet 5。那么，當丟了一個 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)生一個問題，即丟包率算的其實沒有那么準。
第二，device 2 接收到 device 1 發(fā)送的包之后，會回傳一個 loss info 給 device 1。一般來講，loss info 中會加入一些 FEC 的控制，保證它不會被丟。但實際上 loss info 的包仍可能會丟失。
我們假設上述情況中 loss info 沒有丟包，device 1 發(fā)送冗余的包給 device 2，譬如發(fā)送兩個 packet 4 和兩個 packet 5。由于此時的丟包率是 33%。那么 packet 4 丟掉之后，對于 packet 4 來說，起到了抗丟包的效果，但是對于 packet 5 來說，發(fā)的兩個 packet 5 并沒有起到抗丟包的效果，這對網(wǎng)絡帶寬是浪費的。
再假設前面窗口也取準了，loss info 也沒有丟，packet 4、packet 5 也都取得了抗丟包的效果，還是會存在一個問題。在回傳的信道中已經(jīng)有很長的 RTT 在里面，發(fā)過去一個包，device 2 進行估算，估算后，再發(fā)送一個 loss info 回到 device 1。如果 RTT 太長，發(fā)包的過程中還是會不斷出現(xiàn)丟包。也就是在長 RTT 的情況下，這種抗丟包方案的效果是比較有限，或者可以說存在一些缺陷。
我們還可以假設以上問題都不存在。在多人通話中，每個設備接收端的網(wǎng)絡環(huán)境不同，假設 device 1 與 device 2 之間是 3G 或有損的 Wi-Fi 環(huán)境，而 device 3、device 4 分別使用 4G、5G。那么，device 1 在處理 loss info 時應該采取什么策略呢？如果都加入 FEC 的話，就意味著浪費了 device 3 和 device 4 的帶寬，但如果不想浪費帶寬，沒有 FEC ，就意味著無法實現(xiàn)對 device 2 的抗丟包效果。
所以在多人環(huán)境下，網(wǎng)絡帶寬的差異化是做網(wǎng)絡策略時要考慮的重要因素。同時，還有一些人為或成本因素需要我們在做網(wǎng)絡策略時進行綜合考慮。例如，在中國與印度之間進行實時通信時，其中一個 server 在印度當?shù)�，可以直接與中國的 server 進行連接。但印度的通信成本較高，會產(chǎn)生一定的資費。這時我們可以選擇通過新加坡的 server 繞個遠，但這個過程又會產(chǎn)生一些丟包問題。
2、Agora SOLO 的優(yōu)勢在哪兒？
在多人環(huán)境下，傳統(tǒng)的抗丟包策略無法很好解決這類問題，所以聲網(wǎng)在去年 10 月份推出了一個新的編碼器叫 Agora SOLO 。
一段音頻信號通過 Agora SOLO 處理后，會生成兩個成對的包 packet 1 和 packet 2 ，它們?yōu)橥粠�，并且互補。即我收到一個 packet 1 的時候，我可以解碼出一個 8kbps 的窄帶音頻信號，如果我收到一個 packet 2，也可以解碼出一個 8kbps 的窄帶音頻信號，但如果我同時收到一個 packet 1 和一個 packet 2，我就可以恢復出一個 16kbps 的寬帶高質(zhì)量音頻信號。
一定程度上講，這個編解碼器可以解決剛才提到的 FEC 遇到的所有抗丟包的策略問題。
通常，編解碼器做的事情是壓縮、去冗余，而抗丟包從一定程度上講是信道處理的擴大化�？箒G包是一種糾錯算法的擴展，通過加冗余實現(xiàn)抗丟包。而對于 Agora SOLO 來說，是把去冗余和加冗余進行結(jié)合，對重點信息加冗余，對非重點信息則更多的去冗余，以達到在信道和信源的聯(lián)合編碼的效果。
我們強調(diào)了在編碼器上加一定的冗余去抗丟包，實際上就會帶來一些編碼效率的降低。但這種情況下，我們可以通過增加一些新的算法，減少編碼效率的降低。并且，和原始的 codec 編碼效率相比，從結(jié)果上看還要更好一些。
上圖是我們用 ITU NTT 的中文測試序列跑的測試結(jié)果。稍微介紹一下，ITU 的 NTT 是標準的編解碼器測試序列，里面有 26 國語言，這里只拿出了中文部分的測試結(jié)果。那么橫坐標內(nèi)的 PESQ 是窄帶編碼器的客觀測試標準，最后一列，PESQ-WB 是寬帶編解碼的客觀測試標準，滿分是 5 分，通常打到 4 分就是完美了。后面有我們這個編碼器與一些傳統(tǒng)編碼器在 PESQ 分數(shù)的對比。
我們可以看到，是只收到 8kbps 的 packet 1， PESQ 的 MOS 分是 3.52 分。如果只收到 packet 2，MOS 分是 3.51 分。如果 packet 1 和 packet 2 都收到，在16kbps 時，MOS 分是 3.95 分。以上是窄帶的分數(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’的包。
為什么可以這樣做？因為實際上，如果 packet 1 或者 packet 1’ 丟包，不會有太大影響，你仍然可以恢復出一個有限的 8kbps 質(zhì)量的音頻數(shù)據(jù)。如果沒有丟包，收到了 packet 1、packet 1'，就可以恢復出 16kbps 的音頻數(shù)據(jù)，其中并沒有任何的冗余信息。這種算法不像原來的 FEC，兩個包完全相等，或者一大一小，那會造成帶寬浪費。這種算法不會造成帶寬浪費，那么你就無需考慮以下問題：
- 第一，延時問題；
- 第二，回傳 loss info 的丟包問題；
- 第三，多人通信中，每個網(wǎng)絡帶寬不一致的問題。
總體來說，這個編碼器被我稱為接近完美的抗丟包編解碼，因為沒有完美的編解碼器。
Agora SOLO 有如下四個特點：
- 第一，更低延時。無需回傳信道丟包信息，默認發(fā)送多倍數(shù)據(jù)；
- 第二，更高質(zhì)量。收到一個包質(zhì)量可達到普通編解碼器水平，收到兩個包質(zhì)量即可達到高質(zhì)量編解碼的水平；
- 第三，面向多人環(huán)境；
- 第四，簡化策略。無需策略調(diào)整，不擔心策略顆粒度問題。
所以從抗丟包的四種方法（FEC、PLC、ARC、ARQ）來看，需要想盡各種辦法去做 balance。但有了這種方法后，你無需考慮太多，直接調(diào)用即可。另外在有限的成本下，如果同時使用一條高質(zhì)量的高成本的服務器的帶寬和一條低成本相對有丟包下的帶寬時，你可以發(fā)兩條流，分別是 packet 1 和 packet 1’，這樣可以起到更好的效果。
如上圖所示，是我們做的 Agora SOLO 和其他編碼器的對比。從圖中我們可以很快發(fā)現(xiàn) ILBC 和 AMR-NB 的 MOS 分比較低，這是由于它們倆是上個時代的編碼器，因此屬于正常現(xiàn)象。
SILK 和 Opus 的 MOS 分比較高，但我們會發(fā)現(xiàn) SILK+FEC20 時，基礎 MOS 分會下降得非常厲害，因為拿一部分帶寬去做冗余就會導致基礎 MOS 分下降。
而 Opus+FEC20 時，實際上編不出在丟包 5% 時的碼率，因為碼率控制的設計相對比較保守。但我們可以看到它加 FEC20 后，基礎 MOS 分在下降。
而 Agora SOLO 的基礎 MOS 分和 SILK、Opus 幾乎一樣，下降在 0.2 之內(nèi)。而它在抗丟包時，一旦發(fā)生丟包，幾乎沒有 MOS 分下降。在丟包 5%、10%、15%、20% 時，它的 MOS 分維持在一個相對穩(wěn)定的情況，和競品比有時候可以達到 1 分的差距。
做過通信 MOS 分競品比較的人應該知道，高 0.3-0.5 分已經(jīng)是非常困難，高 1 分幾乎是不可能。以 20% 為例，Agora SOLO 的 MOS 分是 3.2，而 SILK 卻只有 2.2 和 2.3，雖然加上 FEC20 后是 3.0，但加上 FEC 后 SILK 的基礎 MOS 分會比較低。
這是 ITU NTT 的中文測試第一條序列——女聲。女聲相對來說比較難編，因為中國人說話有四聲問題，比其他語言更復雜。女聲的高頻信息比男聲更豐富，所以編起來也會更難。
由圖可知，SILK16 的 MOS 分是 3.5，SILK16+FEC 編不出來，Opus16 的 MOS 分是 3.5，Opus16+20FEC 的 MOS 分是 3.3，Opus20+20FEC 的 MOS 分是 2.8。雖然碼率更高了，但由于帶寬原因，給 FEC 的碼率更高，它的內(nèi)核碼率反而更低，所以它的基礎 MOS 分變得很低。
而 Agora SOLO 的 基礎 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。
當采用一包兩幀策略做抗丟包的時候，在 20% 的丟包率下，Agora SOLO 基本沒有丟幀的產(chǎn)生。而傳統(tǒng)的編碼器下，丟幀率還是有一定的損失。
4、兼容 WebRTC 標準的抗丟包語音編碼器 SOLO X
過去一年里，我們把 Agora SOLO 編碼器的抗丟包部分移植到了 OPUS 上，我們給這個技術起了一個新的名字叫分組譜互補技術，并開發(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 的效果好，基礎 MOS 分也高。
它的優(yōu)勢主要是和 OPUS 結(jié)合后，可以與 OPUS 互相兼容。用聲網(wǎng) Native 的 SDK 和 WebRTC 的 SDK 進行互通時，如果它支持 SOLO X 編碼器，它就可以解出兩條更高質(zhì)量的流。而為了做到兼容，會有一些質(zhì)量損失，導致 SOLO X 在 16kbps 的 MOS 分比 SOLO 要下降一些，這也是我們后期優(yōu)化的主要方向。
對于 8kHz 來看，為了起到兼容的效果，它的基礎 MOS 分也有下降，但是它的抗丟包效果沒有明顯下降。
圖：SOLO X 在 ITU NTT 的跑分結(jié)果
和 WebRTC 做兼容后，我們對 WebRTC 的互通做了測試。 googDecodingPLC 的意義是加了網(wǎng)損后，當外邊沒有收到包時，會調(diào)用 googDecodingPLC 函數(shù)去解碼，做后端的抗丟包補償。圖中右側(cè)縱軸的單位是幀，即這段時間內(nèi)補償了多少幀來做抗丟包。如果我們實現(xiàn)了抗丟包的效果，則不用調(diào)大量后端 PLC 做補償。
從上圖數(shù)據(jù)可以看到，在只使用 OPUS 編碼器時，在 20% 和 40% 的丟包模擬下，可以看到 5 分鐘以內(nèi)補償幀數(shù)分別在 6 千次和 11 千次左右。用 SOLO X 時，20% 丟包的情況下，補償幀只有 1K 多一點。40% 丟包時，丟包補償幀只有 4K 左右，可以看到明顯下降，這意味著已經(jīng)有更多的包到達解碼端，不需要調(diào)用 PLC 做補償。
5、SOLO X 和 WebRTC 互通中的數(shù)據(jù)表現(xiàn)
如上圖所示，是我們在兼容模式和非兼容模式下的 PESQ-MOS 分。前面給的數(shù)據(jù)都是兼容 Opus 編碼器的 MOS 分，而非兼容模式下 PESQ-MOS 分可以做的更高。
實際上這張圖也是 PESQ-WB 的 MOS 分，理論上，我們應該用 POLQA 去比分，那么在 48kHz，48kbps 和 32kHz，32kps 去比，MOS 分的差異和影響對比會更大。因為對高頻的權(quán)重越高，一旦有損失就會導致分比較低。這也是為什么幾乎相同的對比策略和解碼輸出， PESQ-WB 的分比 PESQ 的分要低的原因。
在非兼容模式下，它的 MOS 分會遠遠高于兼容模式。后期我們會針對兼容模式進行優(yōu)化，我覺得是有機會達到接近非兼容模式時的效果的。
6、Agora SOLO 的下一步
2017 年，我們花了兩年時間把 SOLO 的編碼器做了出來，今年做 SOLO X 目的是與 OPUS 互通，目前主要做 Voice 這一塊，計劃 2019 年推出針對音樂的編碼器，相信效果會更突出，因為音樂在實際產(chǎn)生中都是使用 128k 或者 196K 的碼率，這種碼率下做 FEC 的代價會非常非常高。
最后我想說，對創(chuàng)業(yè)公司來說花大力氣做編解碼是很吃虧的事情。因為做編碼器很累，也很苦，普通公司通常不會去做。所以我很感謝聲網(wǎng)給我這個機會，也感謝 Tony 的鼓勵。坦白講，無數(shù)的不眠之夜，整夜整夜的失眠才做出了 Agora SOLO 和 SOLO X 。
掃碼觀看演講視頻回顧
�。ㄓ^看澤華演講請空降02:32分）
瀏覽演講 PDF 及更多資料
文章已于2018-09-28修改
