本次分享我們邀請到了來自騰訊云實時音視頻TRTC后臺的研發負責人薛笛，他向我們分享了騰訊云TRTC在架構升級和產品實踐中的經驗。仔細講解了混音引擎最初的制造源、在整個優化過程中發現的問題以及解決方法，為后來做騰訊會議和云呼叫中心打下了一個良好的基礎。
文 / 薛笛
整理 / LiveVideoStack
大家好，我是來自騰訊云實時音視頻TRTC后臺的研發負責人薛笛。很榮幸今天能和大家分享騰訊云TRTC在架構升級和產品實踐中的經驗。
我們團隊之前服務的對象是QQ音視頻產品，它分為三個形態：雙人、多人和群視頻秀。前兩者比較偏向于實時通話，而群視頻秀比較像視頻直播。在這幾個產品中，最常用、體量最大的是雙人視頻通話，在規模上比多人場景和群視頻秀加起來還多一個數量級，微信現在也差不多也是這樣的。
01 音視頻產品形態
1.1 雙人音視頻
從架構角度來看，雙人音視頻系統比較簡單和清晰。紅色點代表房間信令服務，房間信令服務主要功能是管理房間信息、實現能力協商和上下行聯動的質量調控，比如當下行通道發生擁塞的時候，上行的碼率、分辨率也會隨之下降。
傳輸通道層面，我們的策略是優先選擇直連，在跨地區和跨運營商的情況下，我們會選擇單中轉或雙中轉通道，在策略上盡量保持直連和中轉通道同時存在，當其中一個通道質量不好的時候，系統會自動把流量切到另一個通道上。
1.2 多人音視頻
多人視頻通話的產品形態是整個房間不超過50個人，大盤平均房間人數大約4.x個人，房間里面最多滿足一個大視頻和三個小視頻（四個畫面）。根據這個限定條件，我們在架構上采用了典型的SFU小房間設計。
上圖中紅色點代表房間信令服務，主要用于房間管理和狀態信息同步。房間管理主要包括用戶列表的管理，比如哪些用戶開了視頻/音頻、我觀看了誰以及誰觀看了我，這些都以房間管理的信息為準，然后房間信令服務會把這些信息同步給媒體傳輸服務用來做數據分發。
房間服務還有一個作用就是房間級的能力協商和質量調控，比如房間里一開始所有人都支持H.265編碼，當某一時刻進來一個只支持H.264編碼的用戶，那么房間內所有的上行主播就必須將H.265切成H.264 。還有一種情況，當房間內有一定比例下行通道質量差的人，就會導致上行房間質量降級。
在傳輸層面上，我們采用單層的分布式媒體傳輸網絡，我們全部選擇中轉方式，不區分雙人和多人，采用Full-Mesh的傳輸機制，把數據全推過去，比如在一個節點上的人沒有全都看另外兩個人的視頻，但是還是會把視頻推給他們。
02 混音引擎
當時我們的產品還有一個特點——開視頻的比例不高，反而純音頻房間非常活躍。我印象比較深刻的一個案例，一款熱門游戲新出皮膚之后，語音房間的人數就會暴漲，這也是因為很多玩家使用QQ多人語音來開黑。基于這種現象以及成本考慮，我們開發了一個混音引擎。當房間人數超過成本線，我們就會把流都轉到混音引擎，由混音引擎根據音量選路、混音重新編碼后，再把流推到下行的媒體平臺。它的架構已經不是典型的SFU，而很像MCU ，雖然當時的出發點在于成本節約，但這為我們后來做騰訊會議和云呼叫中心打下了良好的基礎。
03 深度優化的云PaaS服務——TRTC
騰訊云實時音視頻產品-TRTC，是在QQ多人音視頻平臺的基礎上，針對To B場景深度優化改造之后推出的云PaaS服務。首先它提供了全平臺SDK，這個SDK繼承了QQ海量服務過程中，所針對的機型、硬件、系統層面的兼容和經驗配置，它在各個平臺上都有比較穩定的表現。其次這個SDK已經被集成到微信中，目前微信視頻號直播、微信群直播和企業微信都用了TRTC-SDK和后臺服務。外部客戶也可以通過小程序的live-pusher和live-player兩個標簽來實現小程序和原生應用之間的高質量互通。在媒體的處理方面，我們和騰訊云多媒體實驗室、騰訊會議天籟實驗室以及QQ和微信都保持非常緊密的合作。在騰訊會議、QQ和微信里應用比較成熟的技術也都會被引入到TRTC中。
3.1 TRTC視頻優化實踐
在視頻方面，我們采用時域分層編碼來應對下行限帶寬場景。一般直播產品在處理下行限帶寬場景時，通常采用轉碼的方式——將原始碼流轉碼出多種規格的流（原始流、高清、標清），根據不同網絡質量切換不同的流。但RTC由于延時和成本考慮，一般不做房間內轉碼，所以我們需要在編碼時把GOP內的幀序列進行分層，帶寬超了的時候，選擇丟棄一些增強層的幀、保留基礎層的幀，同時對基礎層的幀增加額外的冗余保護，以此來保障用戶觀看體驗。
另一個經常和時域分層編碼搭配使用的是RPS跨幀參考。RPS的策略是只有被接收端ACK確認過的幀才作為參考幀，這是通過犧牲一定畫質來保障流暢性的策略。為了盡量減小畫質損失，我們還設計了多種不同的參考模型來適配不同的網絡情況。比如網絡質量很好的時候，我們預測后面2-3幀大概率能收到，此時就不完全參照ACK模式，編碼器在GOP的小分組內依然就近參考，從而保障清晰度；當網絡質量下降時，我們會根據網絡情況切換不同檔位的模型，減少就近參考的數量；當網絡持續變差的時候，我們才會嚴格按照ACK確認執行。
在編碼效率方面，我們在編碼之前會進行一定程度的濾波和降噪處理，這樣編碼的壓縮率會有很好的提升，也能比較好的提升帶寬。在資源有限的情況下，我們還會采用ROI把有限的碼率傾斜到用戶更感興趣的區域。
3.2 TRTC音頻優化實踐
我們在音頻處理中引入了騰訊會議的前處理和基于信源的抗性增強策略。比如開會中常見的敲鍵盤的聲音、或者不那么常見的雨點打在窗戶玻璃上的聲音都可以很好的消除掉。
此外，我們自研的cPLC——基于上下文的丟包補償技術，它可以把120ms以內的連續丟包恢復出來。以及我們自研的cFEC也比OPUS原生的帶內FEC恢復效果更好，這樣在正常網絡下，不用加很多帶外FEC就能應對一些突發丟包的場景。
當然，這些技術點如果單獨拆開使用，是形不成戰斗力的。我們必須要把編解碼、信源和信道的抗性、帶寬預測、擁塞控制和媒體傳輸有機結合起來，才能保證通話低延時高質量的通話效果，這也是RTC與標準直播最大的區別之一和它的魅力所在。
3.3 基于云端的智能化調控
在調控方面，我們開發了一個基于云端的控制引擎。把控制系統放在云端的好處是可以減少終端版本的兼容性問題，并且比較方便進行算法AB-Test的效果驗證。
第二點是在運營過程中，我們通過BadCase分析積累大量的規則，這樣對場景的識別更加準確，讓調控更有針對性。
與此同時，我們在規則模型中提煉出豐富的配置參數，針對不同客戶需求進行調優。比如有的通話產品客戶希望流暢優先，而有的直播客戶需要清晰優先模式，這些需求都可以通過調整配置來實現。
此外，我們在不斷改進算法。在BBR出來的時候，我們參考了BBR帶寬預測的方式，對超大規模房間的調控也做了適配。
04 TRTC架構演進之路
4.1 系統瓶頸與場景需求升級
說到規模問題，最開始講到的多人音視頻通話系統是基于小房間的SFU架構，在房間人數變多的時候會有一個系統瓶頸。首先是調控的計算和狀態信息的同步，這兩個是落在一臺機的一個進程上完成的，當人數非常多的時候，運算量也越來越大，瓶頸就非常明顯。
第二點，媒體傳輸采用單層分發結構，當房間人數越來越大，節點越來越多的時候，帶寬就會產生很明顯的瓶頸。
最后，為了減少內網穿越，接入調度采用了聚合分配的策略，同房間、同運營商、同地區的用戶會優先分到同一臺機器上，分滿了再分下一臺。當房間人數很多，短時間內一起進房的時候，服務的數據上報和狀態同步可能更新不及時，導致節點超分。
但隨著RTC技術場景的拓展，很多客戶有10萬人大房間的需求，如教育場景大班、超級小班課，大的語聊房以及電商直播帶貨等，所以針對客戶需求對原始架構做了升級改造。
4.2 Set改造
首先我們對大集群做了Set改造——按國家、地區、運營商分解為固定大小的Set，Set內自動選擇擴散代理，按流的粒度技進行收斂，緩解上行節點的媒體分發壓力。絕大部分Set通過內網互聯，這樣針對某些海外偏遠國家或國內邊緣節點，它們和其它節點互通只需要一跳即可回到內網。
4.3 內網傳輸
內網傳輸部分是通過騰訊云的云聯網來實現的，騰訊云目前已經在全球開放27個地理區域、61個可用區，內網專線有多條鏈路可切換，帶寬儲備充足。
在騰訊會議做高級別會議匯報的時候也經常做切換演練，幾條專線可以互相切，實際應用下來內網質量整體比較穩定。
4.4 房間管理
在房間管理部分，我們從原來的集中式管理升級為分布式房間管理和信令通道， RoomSvc只保存用戶列表和視頻用戶列表的基本信息，極大減輕控制系統的負擔。由于原來采用的是集中式架構，瓶頸非常明顯，在新架構下，我們對房間按訂閱關系進行了拆解，在內部集群做了一層收斂，這樣運算量就會非常少，從而實現了房間規模的擴展。
RoomSvc所有信息可動態擴展并快速恢復。比如核心節點宕機，這個核心節點的信息在其他的節點中都有，只需要換一臺機器，并把原來的信息搬到這臺機器上，就可以得到完整信息。再比如Set中有一個小的節點宕機，但媒體節點里的信息是完整的，換一個新的機器，將數據重新構建，那么這個房間就可以重新構建出來。
在新的架構下，我們保守估計單房間可支持100萬人，且具備高可用、高可擴展，高可靠等特點。
4.5 實踐落地成果
這套架構在去年疫情期前期發揮了重要作用，騰訊會議和騰訊課堂在疫情初期，每天同時在線人數都呈現翻倍上漲的現象，依靠這套架構，我們7天擴容100萬核心，同時撐住了這兩大產品千萬級用戶同時在線、億級用戶使用。
大規模的視頻會議現在變得越來越常見，比如騰訊會議從300方到企業版2000方，不久還會提供更大規模的會議產品形態。有些機構的大班課/超級小班課現在開始嘗試使用RTC代替標準直播來提升上課體驗，大房間場景未來也會越來越多。
05 TRTC技術優化實踐——RTC平臺媒體處理子系統
5.1 媒體處理子系統優點與問題
最后向大家探討關于RTC平臺的媒體處理子系統。RTC的媒體處理子系統——比如錄制、鑒黃、播片、混流轉推等，本質上是一個旁路系統，現在業界通用的做法是讓一個linux sdk機器人模擬進房，把流拉到服務器本地，做出處理之后再轉旁路出去。
Linux sdk機器人模擬進房不會影響兩個房間的主業務流程。媒體處理子系統需求變更通常不需要動核心系統，且可以實現非常靈活復雜的業務邏輯，比如需要做白板和視頻的對齊、K歌的場景下可以把音頻和時間戳精確對齊，通過這樣的模式可以實現復雜度的隔離。
但我們在做騰訊會議和呼叫中心的時候遇到兩個難題。騰訊會議的場景需要打電話，最初的想法是用機器人進到房間之后把流拉回來，并轉成g.711、g.729放到PSTN網絡中就可以了。由于播放IVR是全房廣播或是針對一個人單獨廣播，所以IVR需要排他式的播放，在SFU的轉發架構下不太容易做精確控制，不管是對新進的控制、還是媒體的識別都是比較復雜、難以控制的。
此外，語音錄制的情況下，金融行業的客戶是不能接受在錄制過程中有多錄或是少錄幾個字的情況的，就像在念身份證號時少幾位數字是絕對不可以的。但是系統中如果是采用機器人的方式去做，由于是兩個系統的整合，系統之間會出現抖動、延遲，就導致錄了不該錄的內容或者該錄的沒錄下來，這些情況對于較為苛刻的用戶是絕對不可以接受的。
5.2 混音引擎解決問題
由于上述問題，我們采用了混音引擎，通過混音引擎將流做集中式的處理，既節省帶寬、又方便實現IVR和錄制功能，打通TRTC與PSTN電話系統，實現融合通信能力。
我們還與騰訊會議合作，做了PSTN窄帶語音頻域超分擴展和線路雜音檢測和消除，進一步提升通話質量，PSTN的融合通信能力是TRTC的特色功能，廣泛應用于客服、呼叫中心和會議場景等。
06 展望未來
雖然疫情在客觀上推動了實時音視頻行業的發展，但RTC仍然處在爆發前夜。目前比如社交、云游戲、遠程實時控制、合唱等RTC重要場景雖然已經有落地應用，但體驗都無法達到最佳，或者存在各種各樣的限制。未來隨著網絡基礎設施和終端軟硬件能力的提升，端到端平均延遲能達到50-80ms，RTC產品的體驗也將會有質的提升，場景和應用也會迸發出更多活力。
以上是我今天的分享，謝謝大家。
-the cover from creativeboom.com
