一場突如其來的疫情，讓數(shù)以億計的白領只能居家辦公，云視頻會議系統(tǒng)突然成為最重要的辦公軟件。騰訊會議在 2019 年 12 月 25 日正式上線后，短短兩個月時間內(nèi)積累千萬日活。除了時機，騰訊會議產(chǎn)品又為什么能脫穎而出呢？產(chǎn)品力是個不得不提的因素，騰訊多媒體實驗室高級研究員王曉海在【騰訊技術開放日·云視頻會議專場】中，對騰訊會議在復雜網(wǎng)絡情況下如何保證高清音質(zhì)進行了分享。
VoIP 和 PSTN 的前世今生
PSTN(Public Switch Telephone Network 公共交換電話網(wǎng)) 從貝爾發(fā)明電話起就已經(jīng)存在了，通過這張網(wǎng)連接全世界所有的電話機，發(fā)展到今天的 PSTN 骨干網(wǎng)基本上都已經(jīng)數(shù)字化了，但是在一些集團電話或者偏遠地區(qū)，PBX（Private Branch Exchange 用戶交換機）接入的可能還是一些模擬電信號接入的傳統(tǒng)電話。PSTN 可以通俗理解成傳統(tǒng)電話和者蜂窩電話 (Public Land Mobile Network 公共路基移動網(wǎng)) 的總和。
VoIP 是基于 IP（Internet Protocol）的語音傳輸，可以理解為經(jīng)過互聯(lián)網(wǎng)傳輸?shù)耐ㄔ?，也有部分通過電信運營商的傳統(tǒng)電話網(wǎng)絡進行傳輸。VoIP 網(wǎng)絡通話是電腦或者移動終端之間的互通，比較典型的 QQ 或者微信，以及蘋果設備之間的 FaceTime。VoIP 比較便宜，這是因為 VoIP 不過是一種互聯(lián)網(wǎng)應用，那么這個流量用戶來看視頻，還是用來做語音視頻通話，實際上資費是一樣的。
那么為什么 VoIP 服務有些要收錢，有些卻免費？這是因為 VoIP 服務不僅能夠溝通 VoIP 用戶，還可以和電話用戶通話，比如使用傳統(tǒng)固話 PSTN，以及無線手機蜂窩網(wǎng)絡 (PLMN)2,3,4,5G 的用戶，對于這部分通話，VoIP 服務商必須要給固話網(wǎng)絡運營商以及無線通訊運營商支付通話費用，這部分的收回就會轉(zhuǎn)到 VoIP 用戶頭上，而網(wǎng)絡 VoIP 用戶之間的通話可以是免費的。
有好多 PSTN 網(wǎng)絡或者集團電話網(wǎng)絡，它本身是有質(zhì)量保證的。但是 VoIP 電話，一般是走公網(wǎng)的，它發(fā)出去或者接到的最后一公里電路是沒有保障的，同時因為各種原因會丟包或者抖動，會讓端到端通話質(zhì)量受損。我們所關注的工作重點，就是圖一右側(cè)密密麻麻的這些內(nèi)容，實際集中在 QoS，也就是 Quality of Service（服務質(zhì)量），包含網(wǎng)絡傳輸?shù)囊幌盗蟹招枨?，比如帶寬、延時、抖動、丟包等。
VoIP 的發(fā)展進化史
Webex1995 年誕生，是業(yè)界最早的一款 VoIP 產(chǎn)品。到了 1999 年 GIPS 誕生，它為業(yè)界提供了廣泛的引擎，對整個 VoIP 影響巨大，在 2003、2004 年，GIPS 向 Skype 和 Webex，以及 QQ 提供了它的 GIPS 音頻引擎，2011 年 GIPS 被谷歌收購，該項目開始開源，即為大家所熟知的 WebRtc 開源項目。
2011 年這個時間點很重要，因為 WebRtc 的開源，促使業(yè)界諸多音視頻通訊領域的頭部玩家開始躁動，同年 Skype 被微軟收購，ZOOM 創(chuàng)立，它的創(chuàng)始人就是 Webex 出來的。2011 年騰訊也開始自研音頻引擎，騰訊在國內(nèi)召集了一批音頻及通信領域的從業(yè)者開發(fā)了第一代引擎 TRAE（Tencent Realtime Audio Engine），并且同年騰訊把自研的 TRAE 引擎上線換掉 GIPS，TRAE 音頻引擎正式作為 QQ 音頻引擎為幾億 QQ 用戶服務。
2014 年騰訊“新一代語音視頻通信引擎 Sharp 系統(tǒng)”獲得公司技術突破金獎，Skype 在國際長途通話市場市占率達到 40%，總通話量達到 2000 多億分鐘。2015 年騰訊“音視頻融合通訊項目”獲得公司技術突破金獎，騰訊從 2016 年開始的向外界提供了 OpenSDK 能力，對內(nèi)對外服務了眾多音視頻通話類的產(chǎn)品，其中 2017 年獲得騰訊內(nèi)部產(chǎn)品最高獎—名品堂的“全民 K 歌”也是使用 OpenSDK 的基礎音視頻處理及通訊能力，這種互聯(lián)互通的能力為后來的發(fā)展奠定了堅實基礎。
其實騰訊的音視頻引擎又可以分為三個小代際。第一代就是 QQ 用的，2011 年 TRAE 引擎，第二代是 2016 年開始向外界開放的 OpenSDK 引擎，到 2017 年騰訊開發(fā)了 XCast 引擎，這算作第三代，在最新的 XCast 引擎之上，誕生出今天的“騰訊會議”。
2019 年 12 月 25 號騰訊會議上線，2020 年 3 月 6 日騰訊會議已經(jīng)登頂 App Store 免費軟件 NO.1，到今天不過兩個多月，3 月份日活達一千萬，成績還是比較難得的。ZOOM 人數(shù)日活突破一千萬是 2014 年 6 月份，當時的 ZOOM 是用了 3 年時間。
VoIP 音頻系統(tǒng)的主要構(gòu)成
VoIP 從發(fā)送端到接收端大概有哪些模塊呢？我今天著重講 網(wǎng)絡的流量控制、擁塞控制，包括丟包、抗網(wǎng)絡抖動的一些邏輯，以及他們怎么樣融合才能更好提升服務質(zhì)量。核心是 QoS 的概念。
QoS（Quality of Services）概念當時在 IETF（The Internet Engineering Task Force 國際互聯(lián)網(wǎng)工程任務組）提出的時候，只專注于純網(wǎng)絡范疇的指標，比如丟包、延遲、抖動、帶寬等。進入新世紀以后，行業(yè)對 VoIP 或者融合通信的理解有變化，進入寬帶時代以后對指標會有更高期許和更高要求，比如說音頻采集，本來采集信源不好，再經(jīng)過壓縮、傳輸、解碼，可能最終效果不好。如果從 QoE（Quality of Experience）環(huán)節(jié)來看，端到端不限于采集模擬接口出來的聲音，甚至包括人的講話環(huán)境和聽音環(huán)境影響，用戶感受到的音頻質(zhì)量，是整個體系反饋出來的診斷。
QoS 沒有太多秘密，無非就是抗丟包，抗抖動，網(wǎng)絡擁塞控制等等，ARC（Adaptive Rate Control）可以看做一個中央指揮官，它只能去指揮整合這些方式、手段，最終保證音頻質(zhì)量是良好的改動。所以說到這塊，QoS 一般套路就類似于一個全家桶，無非這六種模塊的合理有機組合，接下來會對這幾塊深入講一下。
騰訊會議是如何保證服務質(zhì)量的？
1、騰訊會議的“流控”：ARC
先看 ARC，ARC 在騰訊會議的概念就是“流控”，流控能干什么？
是三個大的層面，首先它是一個配置系統(tǒng)，無論雙人或多人通話，系統(tǒng)所需要的基礎配置參數(shù)，還有在什么場景下需要什么樣的參數(shù)。通過這個云端的參數(shù)配置及開關配置，系統(tǒng)擁有了基本的云端可控手段。
然后動態(tài)控制是中間的這塊，流控是把源端到目標端的傳輸行為，發(fā)出來數(shù)據(jù)想讓對方解碼，會存在動態(tài)的能力交換的要求。此外，系統(tǒng)如果發(fā)生了抖動，或者丟包的情況，我們會動態(tài)的去控制相應的模塊去處理這些情況。所以能力交換，或者動態(tài)下發(fā)的能力，實際上是動態(tài)控制的第二層次水平。
最高層的能力，是聰明靈活自適應的能力，就是對 ARC 的指揮能力的更進一步的要求，丟包的時候怎樣去抗丟包，抖動的時候怎么樣去抗抖動，去動態(tài)控制，但是這些抗丟包、抗抖動的方法有可能會占用過多的網(wǎng)絡帶寬、或者以犧牲端到端延時為代價的、于是當網(wǎng)絡發(fā)現(xiàn)了比如帶寬不足，或者網(wǎng)絡用戶本身終端連接路由器質(zhì)量有問題，甚至出現(xiàn)網(wǎng)絡趨于擁塞的情況，這種情況怎么去把它及時挽救回來，這個配置是對 ARC 更高層次的要求，涉及到網(wǎng)絡擁塞控制（Congestion Control）這個核心命題上來了。
2、“流控”在騰訊內(nèi)部的演進過程
一開始是都寫死的參數(shù)，比如解碼器參數(shù)、音頻前處理 3A 開關等、抗丟包和抗抖動參數(shù)也基本是固定的，效果肯定不好。后來我們 在系統(tǒng)增加了流控策略，根據(jù)客戶端動態(tài)上報，動態(tài)去算 QoS 的參數(shù)下發(fā)。進化到多人通話以后，特別帶寬預測是比較大的挑戰(zhàn)，比如上行應該怎么算，下行是接收多交流又該怎么算，因為發(fā)送行為不一樣，原來那種用一個算法對不同流進行預測，肯定不能用。
后來，我們還做了服務器混音。首先可以減少下行用戶的流量，其次多路混音成一路，也可以對融合通信發(fā)揮基礎作用。在對外提供 OpenSDK 的時代，因為對外用戶的需求很不一樣，因為應用場景的差別，有的用戶需要不通類型 Codec，有的用戶需要關掉 3A 處理，有的用戶不需要那么大流量，有的用戶更加在乎質(zhì)量而不在乎流量，所以云端的 Spear 可配置參數(shù)的流控策略可以滿足我們企業(yè)內(nèi)部應用，包括外部用戶的差異化需求。
騰訊會議對于擁塞控制的做法
接下來我們看比較核心的擁塞控制（Congestion Control）。其實擁塞控制在實時 RTC（Real Time Communication）音視頻通訊領域應用中是必不可少的模塊，WebRtc 在開源以后分別向社區(qū)貢獻了 GCC1 和 GCC2 版本，當然這塊不是說 linux 系統(tǒng)下編譯器的那個 GCC。
GCC1（google Congestion Control ver.1）是一個基于接收端的算法，根據(jù)每家系統(tǒng)的軟件架構(gòu)的不同，它部署的位置也不一樣。GCC1 核心算法是通過實時監(jiān)控端到端延時的變化量（Jitter），從而判斷當前這個網(wǎng)絡是否趨于達到網(wǎng)絡擁塞的情況。
我們首先看端到端延時這個基礎概念，端到端延時由三部分組成：一個是傳輸延時，跟數(shù)據(jù)包大小及鏈路寬有關；第二個是隊列延時，即數(shù)據(jù)包在路由器的隊列中通過的時長；第三個傳播延時，一般傳播延時跟傳輸介質(zhì)有關。
實際上在 GCC1 或者 GCC2 里面，它真正進入系統(tǒng)、進入計算的這個變量不是端到端延時，而是其變化量即 Jitter；Jitter=(TR(i)- TR(i-1))- (TS(i)- TS(i-1)) 包括前后兩個數(shù)據(jù)包的接收時間戳之差再減去前后兩個包發(fā)送時間戳之差，算法輸入的是一個 Jitter，GCC1 通過 Kalman 自適應濾波器去除噪點，通過網(wǎng)絡傳輸也好，通過整個鏈路傳輸過程也好，實際上這種延時的變化值 Jitter 是一種符合高斯分布的特征，當我們把噪點去掉以后就可以得出它的 Jitter 趨勢。GCC1 算法將濾波后的 Jitter 值與動態(tài)閾值進行相應的狀態(tài)判斷，從而得出當前的網(wǎng)絡是否趨于擁塞或者處于正常，與此同時還通過實時接收到的流量和預測算法給出當前一個合理的帶寬預測值。
后來 GCC2 又更新了，是基于發(fā)端的，它的數(shù)據(jù)處理源還是 Jitter，就剛才說那個 Jitter，它是一個什么概念呢？自變量就是 Jitter，應變量是什么呢？應變量是它的歷史平均值。所以它對自變量和應變量做了一個最小二乘法的一元線性回歸，相當于去觀察當前的 Jitter 值相比較歷史平均值有怎樣的發(fā)展趨勢，被稱作 TrendLine 算法。GCC 算法它在發(fā)送端也好還是在接收端也好，帶來了工作上的靈活性，而 GCC1 中絕對值的閾值比較變成了 GCC2 中趨勢線的判斷，算法的準確性上有提高。而從及時性上來說，我們在 QQ 時代使用 GCC1 算法是，SDK 的架構(gòu)還是有私有協(xié)議的，比如說反饋機制都是基于兩秒的機制，在最新重構(gòu)的第三代 xCast SDK 上上，完全兼容了標準協(xié)議，RTP 算法核心有準確度的提升，反饋上 RTCP 時機和及時性也有提升，所以“騰訊會議”相關的算法控制會遠遠老一代的 SDK 產(chǎn)品更加及時和準確。
FEC 如何把丟失的數(shù)據(jù)包恢復？
FEC（Forward Error Correction）實際上沒有太多新意，這塊無非就是利用其基本的特性。比如分組劃分，接收端恢復不受數(shù)據(jù)包順序影響等特征。舉個例子：如果是分組是 4，那么在網(wǎng)絡傳輸過程中任意丟掉一個，在接收端任意收到任何順序的 4 個屬于本分組的數(shù)據(jù)包，那就可以把丟失的包恢復。
那么它到底是怎么工作的呢？FEC 目前一般采用了 Reed Solomon 算法，Reed Solomon 算法的核心思想包含三個部分：
- 利用范德蒙德（Vandermonde）矩陣 F，通過 FEC 控制參數(shù)生成冗余矩陣。冗余矩陣的上半部分是一個單位矩陣，分組數(shù)據(jù)矩陣和這部分計算完以后還是原來的數(shù)據(jù)，接下來這部分數(shù)據(jù)則是實際用來產(chǎn)生冗余數(shù)據(jù)的矩陣。圖示相當于 4+2 的原始數(shù)據(jù)生成 2 個冗余數(shù)據(jù)，ENCODING 就是這樣范德蒙德矩陣與原始數(shù)據(jù)相乘，分組的原始數(shù)據(jù)相當于數(shù)據(jù)源，根據(jù) FEC 編碼參數(shù)額外生成的數(shù)據(jù)包就是冗余數(shù)據(jù)。
- 利用高斯消元法（Gaussian elimination）恢復損壞的數(shù)據(jù)，即算冗余矩陣的逆矩陣。使用逆矩陣與接收端湊齊分組的數(shù)據(jù)矩陣進行行列式乘法計算，從而恢復丟失的數(shù)據(jù)包。
- 為了方便計算機處理，所有的運算是在伽羅華域（GalIOS）的基礎上進行。伽羅華域的特點是大小為 n 的集合，其上的任何四則運算的結(jié)果仍在集合中。伽羅華域上的加減法實際上等同于異或 Xor 運算，伽羅華域上的乘除法則通過查表計算非?？?。
比如，傳輸過程中它可能會丟掉，比如 4+2 是 6 個包，任何順序的 2 個包，還剩下 4 個包，就會去計算它的逆矩陣，這個逆矩陣去乘以接收端收到的任何順序的，但是數(shù)量上湊夠分組長度 4 個的數(shù)據(jù)包，通過矩陣算法可以恢復丟失的數(shù)據(jù)包。
從原理來講很簡單的，我們今天要講 FEC，它在實際落地過程中還有一些技巧。比如在算法實際落地的時候，怎么樣去評價 FEC 算法的效果，首先會有量化數(shù)據(jù)，比如基于一個統(tǒng)計算法，F(xiàn)EC 的恢復率是多少？加不加常態(tài) FEC？多少倍的冗余公式去加這個 FEC？最終的效果什么樣的？這些都需要強大的基于大盤數(shù)據(jù)的分析和 ABTest 運維能力才能逐步獲取到的最佳值。比如，在一開始的版本，在沒有加常態(tài)的 FEC 下，動態(tài) FEC 恢復其實不到 90%。到再加常態(tài) FEC，F(xiàn)EC 恢復率可以爬升至 95%，網(wǎng)絡經(jīng)常有小的丟包，那么指望系統(tǒng)、流控或者任何反饋機制，實際上不靠譜的，寧可去添加一些常態(tài)的 FEC 冗余。此外，對于實際的網(wǎng)絡，突發(fā)的丟包是經(jīng)常發(fā)生的，F(xiàn)EC 參數(shù)的設定也有融入控制論的相關思想，除了動態(tài)計算和下發(fā) FEC 參數(shù)，還要考慮參數(shù)在一段時間的有效性，比如我們對 FEC 參數(shù)增加的緩降控制窗口邏輯，又進一步將 FEC 恢復率提升至最高的 99% 左右。
右上角是大盤的數(shù)據(jù)，可以發(fā)現(xiàn) FEC 整體會有明顯攀升，這里就是常態(tài) FEC 的一個效果。另外對于在這里的分組長度的確定，分組要兼顧整個系統(tǒng)延遲，以及你的系統(tǒng)規(guī)格要兼顧怎樣的邊界和指標，如果不通過大數(shù)據(jù)運營，你永遠不知道分組多少是合適的。通過前面講的大數(shù)據(jù) ABTest 運營方式把數(shù)據(jù)放在真實用戶的全網(wǎng)進行驗證，找到合適分組、冗余倍率公式、控制相關的策略。下面這兩張圖就可以看到最終的結(jié)果，看似還是很不錯的，F(xiàn)EC 恢復率從 95% 恢復到高的接近 99%。
網(wǎng)絡是有突發(fā)丟包的，可能時不時的來一下，或者丟包前后有一些持續(xù)的小丟包。FEC 控制策略上的拖尾時間窗口的方式，可以 Cover 住這一類連續(xù)丟包。
如何做音頻 ARQ 抗抖動處理
ARQ 也是一個比較成熟的技術，我們在做的過程中也是踩過一些坑的，所以今天也非常愿意跟大家分享。
如果這塊做不好的話，實際上會有副作用，寧可不要這功能。在 QQ 時代，一個典型例子是應用層有個邏輯，在基于 RTT 小于多少毫秒的基礎情況下，給音頻數(shù)據(jù)包進行重傳，主觀上認為只要是把丟包重新傳回來，這個效果肯定是好的，至于底層的 TRAE 音頻引擎怎么處理，實際上不太關心。但這個是不夠的，這就是今天講的紅箭頭 5 和 6 比較細節(jié)的地方，重傳算法主要關注的是對于缺失的數(shù)據(jù)包重傳間隔以及最大重傳次數(shù)，但是數(shù)據(jù)包重傳回來的時候，這個包怎么合理利用它。同時，播放器則是按照時間軸不停播放的，數(shù)據(jù)沒有來，是否還不停地要呢？這塊有一個正反饋和負反饋的過程。
另外如果僅僅是重傳數(shù)據(jù)包，沒有記錄或者管理數(shù)據(jù)包從第一次到最后重傳了多少次，這個包重傳成功總共消耗了多少時間，這個環(huán)節(jié)是非常有價值的，包括許多開源算法包括 WebRtc 這一塊的邏輯也是沒有做的。通過對重傳數(shù)據(jù)包所消耗的時間管理，可以精細化的去控制接下來我們會講的 Jitter Buffer 之前的配合，比如我們有了這個重傳消耗時長，我們就可以知道讓 Jitter Buffer 未來的一段時間等待多久，另外對于已經(jīng)解碼成功的數(shù)據(jù)隨著時間軸實時的在播放，如果時間軸播放到了某些缺失的數(shù)據(jù)包應該出現(xiàn)的地方，某些數(shù)據(jù)包再重傳回來也不要了，這時候也要及時去更新重傳列表，這也是重傳效率的問題。
怎么樣去精細化升級算法，做了兩方面的工作。一般重傳兩個關鍵因素，一個是重傳次數(shù)，再一個是重傳間隔。重傳間隔首先不能小于 RTT，一般都是 1 點幾倍率的 RTT 時間間隔要一次包，在一個 RTT 時間去等它，如果不來再去要。然后還會考慮一個基于：“截斷二進制指數(shù)退避“的算法概念。比如說 20%，理論上重傳幾次就夠了，30%、40%、50% 甚至 80% 重傳幾次，如果超過這個次數(shù)的上限，再結(jié)合比如說帶寬預測狀態(tài)或者 RTT 值的情況，及時中止這種行為，這種行為可以避免系統(tǒng)本身因為算法本身不合理造成的流量雪崩。
音頻的抗抖動處理
接下來就是抗抖動。抖動怎么理解呢？有些網(wǎng)絡情況下不太容易發(fā)生，在網(wǎng)絡擁塞 Congestion Control 那塊，我們在介紹 GCC1 和 GCC 算法的時候解釋了 Jitter 的計算方法，以及它出現(xiàn)的一些原因。在使用 Wifi 網(wǎng)絡的情況下經(jīng)常有五六百毫秒抖動非常正常，所以如果對抗網(wǎng)絡抖動也是一個非常關鍵的功能。從 GIPS 開源之前，NetEQ（Net equalizer）就被作為引擎內(nèi)部的王牌特性，被用來對抗各種情況網(wǎng)絡抗延時控制，以及抗擊抖動的最佳算法實踐。它開源以后，大家基于此的技術進行追蹤、優(yōu)化都是受益匪淺的。
看左上角這個網(wǎng)絡真實來包的情況，右下角則是期望通過抗抖處理送給解碼器均勻的數(shù)據(jù)包，理想的包是這樣順序且均勻間隔的數(shù)據(jù)包，但現(xiàn)實總是不美好的，來的包總是非常不均勻，甚至幾百毫秒沒有數(shù)據(jù)，然后接下來突發(fā)幾秒數(shù)據(jù)一起到來。這個 Jitter Buffer 的作用就是，盡量去維持合適的數(shù)據(jù)包水位，這個水位也最終會影響到整個系統(tǒng)的端到端延時，水位太低或者太高都是不行的，太高的話我們及時把這個降下來，太低我們要及時把它調(diào)整到認為合理的一個位置。合理的水位可以對抗網(wǎng)絡突發(fā)，播放端則因為 Jitter Buffer 能夠保持合理水位，擁有穩(wěn)定持續(xù)的數(shù)據(jù)源用來播放，這對于用戶最終聽到完整和高質(zhì)量的聲音都是非常有幫助的。
Jitter Buffer 通過監(jiān)測什么變量去看抖動行為呢？剛才我們在網(wǎng)絡擁塞控制那張講的 Jitter 的計算，需要發(fā)送端時間戳和接收端時間戳去計算。而這里它只是通過相鄰兩個包到達時間的間隔，最終這個 IAT（Inter Arrival Time）的概念去表征這個時間間隔，他表示端到端前后兩個數(shù)據(jù)包到達的時間間隔，這個 IAT 時間間隔歸一化為包個數(shù)，對一定時間區(qū)間內(nèi)的 IAT 數(shù)據(jù)做一個概率分布，它是滿足正態(tài)分布的趨勢，我們?nèi)∷菨M足 95% 的概率分布作為置信區(qū)間，選取其中的最大 IAT 來估算當前網(wǎng)絡的大延時。
剛才講的網(wǎng)絡延時估計與跟蹤，相當于它在對網(wǎng)絡包進行合理緩存，保證數(shù)據(jù)的完整性。那么怎么樣把已經(jīng)收到的數(shù)據(jù)包延時壓下來，或者讓數(shù)據(jù)包水位不夠的時候，把這個時間軸拉長？其實這里面也是一個 Waveform Similarty 的算法，我們叫 Wsola，它兼顧 PCM 數(shù)據(jù)在幅度上，頻率上、以及相位上的延續(xù)性算法，效果還是不錯的。這個算法是一種基于拓展壓縮語音長度，是一個變長不變調(diào)的技術，它是基于 Pitch 基音周期進行相似波形疊加的一個算法。
音頻編解碼器的抗丟包能力
Codec 編解碼器專題一般會去講解碼器的歷史或音質(zhì)對比，我們今天從網(wǎng)絡抗性的角度重點是看它的帶內(nèi)抗丟包能力，或者 Codec 層面能夠給抗丟包帶來一些什么收益。
Codec 層面不能指望完全無損的把二進制包恢復，那它的優(yōu)勢就哪里？
它的優(yōu)勢在于可以節(jié)省包頭，不管是以前的私有協(xié)議還是現(xiàn)在的 RTP 協(xié)議，用于傳輸?shù)?IP，UDP 協(xié)議字段是節(jié)省不了的，信道編碼的方法比如帶外 FEC，或者重傳 ARQ 都是對完整數(shù)據(jù)包進行恢復或者請求重傳，這里面的數(shù)據(jù)包頭占用了許多流量。而所以在 Codec 中的帶內(nèi) FEC 里面的實現(xiàn)算法里面，一般來說它可以攜帶 t-1 幀的數(shù)據(jù)，而這個 t-1 幀的數(shù)據(jù)包可以用一個低碼率的參數(shù)進行編碼，在接收端收到這個攜帶 t-1 幀的數(shù)據(jù)包，則可以解碼重建出來 t-1 這一幀質(zhì)量稍遜一點的數(shù)據(jù)。
講到這里就是大家也有個疑問，比如說 silk 也是 t-1，然后它的抗丟包特性大概 15%，而最最新版本的 Opus1.3.1 大家可以聽一下不同丟包率場景下他的表現(xiàn)，Opus 在內(nèi)它為什么最后 30% 呢？
這個圖就是剛才說的全家桶算法里面使用的抗丟包算法基本都包括在里面了，我們所使用的一些方法在這個合集里面只是占其中一小部分。PLC 就是 Packet Loss Concealment，丟包恢復算法它的內(nèi)涵還是比較豐富的。畫一個樹狀圖，把整個合集集中起來發(fā)現(xiàn)它有兩大陣營，一個是基于發(fā)端的，一個是基于收端的。基于發(fā)端的有被動式和主動式，重傳類的就是主動式，前向糾錯的就是被動式。
至于重傳為什么給它送到發(fā)端？以我的理解，在接收端不管是 Ack, Go-N Ack 或者是 NACK 方式，都是接收端的反饋，真正要發(fā)包還是在發(fā)送端的，所以還是基于發(fā)端。
基于發(fā)端的另外一個大類就是 FEC。前面講的 FEC 工程實踐和原理就是所里德—羅門算法，這種算法還有很多類似的，比如噴泉碼，比如 RLNC。這個 RLNC 有個比較好的特性，可以支持重建碼，比如在網(wǎng)絡比較好的情況下，我現(xiàn)在收聽上百人千人，針對不同的下行用戶，再根據(jù)下行信道的參數(shù)進行重新編碼，不至于像用噴泉、RS 或異或只能保持原狀。另外，其中信源相關的 FEC 就是上一頁講的 Codec 層面的帶內(nèi) FEC。
基于接收端有很多方法，比如插入式方法，比如在接收端，那么插入靜音、白噪音，或者干脆把前面一個包復制一下，就不管它的相關性和銜接，這樣效果不太好。而且它的補償效果也就是 20 毫秒頂天了，在銜接不好的情況下還容易產(chǎn)生金屬音。
另外一大類就是內(nèi)插式的方法，比如波形相似法，還有基音周期復制法，還有就是波形伸縮法。到這塊，所有的方法就能很好地解決幅度連續(xù)、頻率連續(xù)、相位連續(xù)的特征，所以它的效果總體來說還是不錯的。
另外基于接收端的，它有一類再生補償方法。比如時域數(shù)據(jù)傳輸本身挺大的，如果在變換域的話，它可能只需要一些變換域的參數(shù)，在接收端進行恢復。
再接下來還有一些比較偏門的技術，比如基于傳統(tǒng)的語音增強，比如自適應濾波器的一些方法，進行語音重建的方法，這里不說了。前面做選擇的方案也僅僅是使用比較多的方法，通過有機融合把它更好的控制起來，最終達到好的效果。
現(xiàn)在回答一下，剛才上一頁為什么 Silk15%、Opus 達到 30%。這是一系列基于接收端的技術，不斷升級、不斷演進、不斷優(yōu)化的效果，T-1 只是一個工程化的思想，做 T-2 可不可以，如果不再考慮算法因素 T-3 行不行？
于是就引出來實驗室目前正在重點發(fā)力的基于機器學習的方法來做 PLC，用上下文分析的方法，這就是目前的一個效果，大家可以看到這塊有四個語音的時域圖。左邊這個圖丟失了 100 毫秒數(shù)據(jù)，100 毫秒看似非常少，它是個什么概念呢，按照正常語速大概一個字是 150 毫秒，100 毫秒基本上大半個字丟了。我們通過機器學習 PLC 的種方法把它給恢復出來，而且效果還不錯。
騰訊會議為什么能取得疫情期間高速增長？
最后，疫情期間騰訊會議為什么能在短短兩個多月時間，外部用戶可以從 0 做到 1000 萬？這是有一定的有必然性的，首先“騰訊會議”產(chǎn)品是一個全平臺的應用，PC、手機、傳統(tǒng)電話、Pad、網(wǎng)頁、小程序還有專業(yè)視頻設備都可以接入的，這種互聯(lián)互通的能力本身就給廣大用戶帶來了價值。今天官微公布，騰訊會議 API 向全網(wǎng)開放了，國內(nèi)外開發(fā)者都可以接入騰訊會議的 API，去把這個市場做大。
另外也要歸功于騰訊會議的海量用戶群體，10 億微信用戶、8 億 QQ 用戶，還有 250 萬企業(yè)微信用戶，基本上覆蓋了所有的中國用戶。我記得張小龍有一句話，七個價值觀，其中之一就是說：“讓需求自然生長”。在疫情期間，“騰訊會議”的極速擴張就是一個自然生長的過程。為了助力疫情期間人與人減少接觸，全免費讓大家使用體驗，這件事情符合實際需求，就是它短期內(nèi)爆發(fā)的又一個原因。
騰訊云做 ToB 業(yè)務之后，它給騰訊內(nèi)外部的各種產(chǎn)品提供了強大的支撐力，遍布全球 130 多個國家，1300 多個的加速節(jié)點，專網(wǎng)接入，音視頻會議最低延時達到 80 毫秒，而且動態(tài)擴容能力非常強。值得一提的是，疫情期間我們發(fā)現(xiàn)有“騰訊會議”用戶量高峰的規(guī)律變化，許多人從早上六點開始工作，然后 6 點半一撥，7 點一撥高峰，后來發(fā)現(xiàn)是各地的醫(yī)生護士在線溝通進度，向大家說一聲辛苦了。
QA
Q： Opus 能達到 30% 的抗性的結(jié)論是怎么得到的？請問音頻編碼帶內(nèi)如何，包括和帶外如何結(jié)合進行優(yōu)化？
A：對于網(wǎng)絡抗性或弱網(wǎng)的抗性，為了總量保證音頻質(zhì)量，我們提供了一攬子結(jié)合方案。比如 Opus 的帶內(nèi)抗性，它是從工程化角度做的一個概念，是發(fā)端數(shù)據(jù)包內(nèi)編碼攜帶前一幀質(zhì)量稍差的一幀壓縮數(shù)據(jù)，并且結(jié)合接收端的不斷升級的 PLC 算法。這個 Opus 帶內(nèi)抗性是編解碼器原生提供的抗丟包能力，通過專業(yè)的思伯倫設備測試在 30% 丟包率的場景下可以達到 3.0 分以上的效果，這是一個客觀的數(shù)據(jù)。
第二個問題是個好問題，就像剛才講的，怎么樣把各個手段優(yōu)點結(jié)合發(fā)揮出來。有一句俗話說，甘蔗沒有兩頭甜，我們就要做到怎么讓它兩頭都甜，而且還要在系統(tǒng)里配合良好，有機運轉(zhuǎn)。
我舉個例子，F(xiàn)EC 的算法落地，在照顧正常網(wǎng)絡的情況下，同時還能自適應去 Cover 突發(fā)小丟包網(wǎng)絡，我們會做一些假定，比如就認為在通話過程一定會有突發(fā)狀況、各種各樣的丟包。那么我們會預設一部分的帶外 FEC，帶外的優(yōu)點和缺點也是很明確的，最大缺點就是費流量。Codec 技術發(fā)展到今天得到了長足進步，我們就可以用帶內(nèi) FEC 做這方面的抗丟包。
至于重傳這塊怎么結(jié)合？首先要有對這個產(chǎn)品的定位，比如騰訊會議它的定位是實時交流產(chǎn)品，一定要保延時，同時應對復雜網(wǎng)絡，各種各樣的復雜網(wǎng)絡。
怎么做到低延時還抗大丟包，帶外 FEC 的最大特點就是說費流量，但是它可以延時做得非常低，它的延時受限于分組延時，重傳的話效率非常高，但又受到網(wǎng)絡 RTT 的影響。
我概括成一句，正常網(wǎng)絡用帶內(nèi)去加常態(tài)，在系統(tǒng)邊界上限要求抗超大丟包而且還要考慮延時的時候，使用帶外 FEC 算法那，但是對于帶外 FEC 的使用要配合控制精準的網(wǎng)絡擁塞算法，即做到能收能放。此外，重傳 ARQ 對于的突發(fā)丟包，會有比較好的效果，另外對于綜合抗丟包能力也是一種很好的補充。通過這三種有機結(jié)合，基本上會有比較好的結(jié)果。
Q: 關于語音激勵是怎么實現(xiàn)的？現(xiàn)在的架構(gòu)是 SFU 還是 MCU，是自源的還是開源的？
A：我們目前是自研的方案，是混合的，SFU 和 MCU 對于語音能力來說，我們的系統(tǒng)在混音服務器是可以根據(jù)用戶的需要可配置的，我們可以做到 Server 端全混音，也可以客戶端混音。當然既然支持融合通信，不然我們多路數(shù)據(jù)輸出一路給 PSTN，一定是經(jīng)過 MCU 的。
語音激勵是怎么實現(xiàn)的，實際上是 MCU 本身的一個基礎的語音選路能力，選路信息再由 MCU 同步到客戶端就 OK 了。
Q:FEC 碼的信息量與音頻信息量的比例是怎樣的?
A: 這塊還是關于系統(tǒng)邊界的問題，一般是說產(chǎn)品的規(guī)格。從 QQ 技術交流一直到 2019 年、2020 年， 21 年的積淀，在不同時代基于當時的網(wǎng)絡情況和市場需求，當時的定位，產(chǎn)品規(guī)格都是不一樣的。
現(xiàn)在問一個具體的信息量比的具體數(shù)字，它的意義不是太大，這跟產(chǎn)品規(guī)格也有關系。如果有一個強大的 ARC 去統(tǒng)籌、去控制，結(jié)合今天講的全家桶工具，那么做任何類型的實時音視頻類產(chǎn)品，只要定好規(guī)則，基本上就是可以實現(xiàn)，而且做得效果還不錯。
講師簡介
王曉海，騰訊多媒體實驗室高級研究員。王曉海于 2011 年加入騰訊，曾參與開發(fā) QQ 音頻 TRAE 引擎、OpenSDK 引擎、GME 游戲語音引擎、以及騰訊會議 XCast 引擎。加入騰訊前，王曉海于 2006 年進入中科院軟件所嵌入式軟件開發(fā)中心 (Casky 中科開元)，擁有豐富的嵌入式多媒體開發(fā)、音頻編解碼、音效處理算法及優(yōu)化經(jīng)驗。2011 年加入騰訊后，參與開發(fā)了騰訊第一代自研音頻引擎 TRAE(Tencent Realtime Audio Engine)，深耕音頻 + 網(wǎng)絡算法方向，負責實時音頻 SDK 中的音頻流控、音頻網(wǎng)絡抗性、網(wǎng)絡擁塞控制、以及相關功能設計和開發(fā)工作。
