一場突如其來的疫情，讓數以億計的白領只能居家辦公，雲視頻會議系統突然成爲最重要的辦公軟件。騰訊會議在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中的音頻流控、音頻網絡抗性、網絡擁塞控制、以及相關功能設計和開發工作。