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