本次分享我們邀請到了來自騰訊云實時音視頻TRTC后臺的研發(fā)負(fù)責(zé)人薛笛，他向我們分享了騰訊云TRTC在架構(gòu)升級和產(chǎn)品實踐中的經(jīng)驗。仔細講解了混音引擎最初的制造源、在整個優(yōu)化過程中發(fā)現(xiàn)的問題以及解決方法，為后來做騰訊會議和云呼叫中心打下了一個良好的基礎(chǔ)。

文 / 薛笛

整理 / LiveVideoStack

大家好，我是來自騰訊云實時音視頻TRTC后臺的研發(fā)負(fù)責(zé)人薛笛。很榮幸今天能和大家分享騰訊云TRTC在架構(gòu)升級和產(chǎn)品實踐中的經(jīng)驗。

我們團隊之前服務(wù)的對象是QQ音視頻產(chǎn)品，它分為三個形態(tài)：雙人、多人和群視頻秀。前兩者比較偏向于實時通話，而群視頻秀比較像視頻直播。在這幾個產(chǎn)品中，最常用、體量最大的是雙人視頻通話，在規(guī)模上比多人場景和群視頻秀加起來還多一個數(shù)量級，微信現(xiàn)在也差不多也是這樣的。

01

音視頻產(chǎn)品形態(tài)

1.1 雙人音視頻

從架構(gòu)角度來看，雙人音視頻系統(tǒng)比較簡單和清晰。紅色點代表房間信令服務(wù)，房間信令服務(wù)主要功能是管理房間信息、實現(xiàn)能力協(xié)商和上下行聯(lián)動的質(zhì)量調(diào)控，比如當(dāng)下行通道發(fā)生擁塞的時候，上行的碼率、分辨率也會隨之下降。

傳輸通道層面，我們的策略是優(yōu)先選擇直連，在跨地區(qū)和跨運營商的情況下，我們會選擇單中轉(zhuǎn)或雙中轉(zhuǎn)通道，在策略上盡量保持直連和中轉(zhuǎn)通道同時存在，當(dāng)其中一個通道質(zhì)量不好的時候，系統(tǒng)會自動把流量切到另一個通道上。

1.2 多人音視頻

多人視頻通話的產(chǎn)品形態(tài)是整個房間不超過50個人，大盤平均房間人數(shù)大約4.x個人，房間里面最多滿足一個大視頻和三個小視頻（四個畫面）。根據(jù)這個限定條件，我們在架構(gòu)上采用了典型的SFU小房間設(shè)計。

上圖中紅色點代表房間信令服務(wù)，主要用于房間管理和狀態(tài)信息同步。房間管理主要包括用戶列表的管理，比如哪些用戶開了視頻/音頻、我觀看了誰以及誰觀看了我，這些都以房間管理的信息為準(zhǔn)，然后房間信令服務(wù)會把這些信息同步給媒體傳輸服務(wù)用來做數(shù)據(jù)分發(fā)。

房間服務(wù)還有一個作用就是房間級的能力協(xié)商和質(zhì)量調(diào)控，比如房間里一開始所有人都支持H.265編碼，當(dāng)某一時刻進來一個只支持H.264編碼的用戶，那么房間內(nèi)所有的上行主播就必須將H.265切成H.264 。還有一種情況，當(dāng)房間內(nèi)有一定比例下行通道質(zhì)量差的人，就會導(dǎo)致上行房間質(zhì)量降級。

在傳輸層面上，我們采用單層的分布式媒體傳輸網(wǎng)絡(luò)，我們?nèi)窟x擇中轉(zhuǎn)方式，不區(qū)分雙人和多人，采用Full-Mesh的傳輸機制，把數(shù)據(jù)全推過去，比如在一個節(jié)點上的人沒有全都看另外兩個人的視頻，但是還是會把視頻推給他們。

02

混音引擎

當(dāng)時我們的產(chǎn)品還有一個特點——開視頻的比例不高，反而純音頻房間非常活躍。我印象比較深刻的一個案例，一款熱門游戲新出皮膚之后，語音房間的人數(shù)就會暴漲，這也是因為很多玩家使用QQ多人語音來開黑。基于這種現(xiàn)象以及成本考慮，我們開發(fā)了一個混音引擎。當(dāng)房間人數(shù)超過成本線，我們就會把流都轉(zhuǎn)到混音引擎，由混音引擎根據(jù)音量選路、混音重新編碼后，再把流推到下行的媒體平臺。它的架構(gòu)已經(jīng)不是典型的SFU，而很像MCU ，雖然當(dāng)時的出發(fā)點在于成本節(jié)約，但這為我們后來做騰訊會議和云呼叫中心打下了良好的基礎(chǔ)。

03

深度優(yōu)化的云PaaS服務(wù)——TRTC

騰訊云實時音視頻產(chǎn)品-TRTC，是在QQ多人音視頻平臺的基礎(chǔ)上，針對To B場景深度優(yōu)化改造之后推出的云PaaS服務(wù)。首先它提供了全平臺SDK，這個SDK繼承了QQ海量服務(wù)過程中，所針對的機型、硬件、系統(tǒng)層面的兼容和經(jīng)驗配置，它在各個平臺上都有比較穩(wěn)定的表現(xiàn)。其次這個SDK已經(jīng)被集成到微信中，目前微信視頻號直播、微信群直播和企業(yè)微信都用了TRTC-SDK和后臺服務(wù)。外部客戶也可以通過小程序的live-pusher和live-player兩個標(biāo)簽來實現(xiàn)小程序和原生應(yīng)用之間的高質(zhì)量互通。在媒體的處理方面，我們和騰訊云多媒體實驗室、騰訊會議天籟實驗室以及QQ和微信都保持非常緊密的合作。在騰訊會議、QQ和微信里應(yīng)用比較成熟的技術(shù)也都會被引入到TRTC中。

3.1 TRTC視頻優(yōu)化實踐

在視頻方面，我們采用時域分層編碼來應(yīng)對下行限帶寬場景。一般直播產(chǎn)品在處理下行限帶寬場景時，通常采用轉(zhuǎn)碼的方式——將原始碼流轉(zhuǎn)碼出多種規(guī)格的流（原始流、高清、標(biāo)清），根據(jù)不同網(wǎng)絡(luò)質(zhì)量切換不同的流。但RTC由于延時和成本考慮，一般不做房間內(nèi)轉(zhuǎn)碼，所以我們需要在編碼時把GOP內(nèi)的幀序列進行分層，帶寬超了的時候，選擇丟棄一些增強層的幀、保留基礎(chǔ)層的幀，同時對基礎(chǔ)層的幀增加額外的冗余保護，以此來保障用戶觀看體驗。

另一個經(jīng)常和時域分層編碼搭配使用的是RPS跨幀參考。RPS的策略是只有被接收端ACK確認(rèn)過的幀才作為參考幀，這是通過犧牲一定畫質(zhì)來保障流暢性的策略。為了盡量減小畫質(zhì)損失，我們還設(shè)計了多種不同的參考模型來適配不同的網(wǎng)絡(luò)情況。比如網(wǎng)絡(luò)質(zhì)量很好的時候，我們預(yù)測后面2-3幀大概率能收到，此時就不完全參照ACK模式，編碼器在GOP的小分組內(nèi)依然就近參考，從而保障清晰度；當(dāng)網(wǎng)絡(luò)質(zhì)量下降時，我們會根據(jù)網(wǎng)絡(luò)情況切換不同檔位的模型，減少就近參考的數(shù)量；當(dāng)網(wǎng)絡(luò)持續(xù)變差的時候，我們才會嚴(yán)格按照ACK確認(rèn)執(zhí)行。

在編碼效率方面，我們在編碼之前會進行一定程度的濾波和降噪處理，這樣編碼的壓縮率會有很好的提升，也能比較好的提升帶寬。在資源有限的情況下，我們還會采用ROI把有限的碼率傾斜到用戶更感興趣的區(qū)域。

3.2 TRTC音頻優(yōu)化實踐

我們在音頻處理中引入了騰訊會議的前處理和基于信源的抗性增強策略。比如開會中常見的敲鍵盤的聲音、或者不那么常見的雨點打在窗戶玻璃上的聲音都可以很好的消除掉。

此外，我們自研的cPLC——基于上下文的丟包補償技術(shù)，它可以把120ms以內(nèi)的連續(xù)丟包恢復(fù)出來。以及我們自研的cFEC也比OPUS原生的帶內(nèi)FEC恢復(fù)效果更好，這樣在正常網(wǎng)絡(luò)下，不用加很多帶外FEC就能應(yīng)對一些突發(fā)丟包的場景。

當(dāng)然，這些技術(shù)點如果單獨拆開使用，是形不成戰(zhàn)斗力的。我們必須要把編解碼、信源和信道的抗性、帶寬預(yù)測、擁塞控制和媒體傳輸有機結(jié)合起來，才能保證通話低延時高質(zhì)量的通話效果，這也是RTC與標(biāo)準(zhǔn)直播最大的區(qū)別之一和它的魅力所在。

3.3 基于云端的智能化調(diào)控

在調(diào)控方面，我們開發(fā)了一個基于云端的控制引擎。把控制系統(tǒng)放在云端的好處是可以減少終端版本的兼容性問題，并且比較方便進行算法AB-Test的效果驗證。

第二點是在運營過程中，我們通過BadCase分析積累大量的規(guī)則，這樣對場景的識別更加準(zhǔn)確，讓調(diào)控更有針對性。

與此同時，我們在規(guī)則模型中提煉出豐富的配置參數(shù)，針對不同客戶需求進行調(diào)優(yōu)。比如有的通話產(chǎn)品客戶希望流暢優(yōu)先，而有的直播客戶需要清晰優(yōu)先模式，這些需求都可以通過調(diào)整配置來實現(xiàn)。

此外，我們在不斷改進算法。在BBR出來的時候，我們參考了BBR帶寬預(yù)測的方式，對超大規(guī)模房間的調(diào)控也做了適配。

04

TRTC架構(gòu)演進之路

4.1 系統(tǒng)瓶頸與場景需求升級

???

說到規(guī)模問題，最開始講到的多人音視頻通話系統(tǒng)是基于小房間的SFU架構(gòu)，在房間人數(shù)變多的時候會有一個系統(tǒng)瓶頸。首先是調(diào)控的計算和狀態(tài)信息的同步，這兩個是落在一臺機的一個進程上完成的，當(dāng)人數(shù)非常多的時候，運算量也越來越大，瓶頸就非常明顯。

第二點，媒體傳輸采用單層分發(fā)結(jié)構(gòu)，當(dāng)房間人數(shù)越來越大，節(jié)點越來越多的時候，帶寬就會產(chǎn)生很明顯的瓶頸。

最后，為了減少內(nèi)網(wǎng)穿越，接入調(diào)度采用了聚合分配的策略，同房間、同運營商、同地區(qū)的用戶會優(yōu)先分到同一臺機器上，分滿了再分下一臺。當(dāng)房間人數(shù)很多，短時間內(nèi)一起進房的時候，服務(wù)的數(shù)據(jù)上報和狀態(tài)同步可能更新不及時，導(dǎo)致節(jié)點超分。

但隨著RTC技術(shù)場景的拓展，很多客戶有10萬人大房間的需求，如教育場景大班、超級小班課，大的語聊房以及電商直播帶貨等，所以針對客戶需求對原始架構(gòu)做了升級改造。

4.2 Set改造

首先我們對大集群做了Set改造——按國家、地區(qū)、運營商分解為固定大小的Set，Set內(nèi)自動選擇擴散代理，按流的粒度技進行收斂，緩解上行節(jié)點的媒體分發(fā)壓力。絕大部分Set通過內(nèi)網(wǎng)互聯(lián)，這樣針對某些海外偏遠國家或國內(nèi)邊緣節(jié)點，它們和其它節(jié)點互通只需要一跳即可回到內(nèi)網(wǎng)。

4.3 內(nèi)網(wǎng)傳輸

內(nèi)網(wǎng)傳輸部分是通過騰訊云的云聯(lián)網(wǎng)來實現(xiàn)的，騰訊云目前已經(jīng)在全球開放27個地理區(qū)域、61個可用區(qū)，內(nèi)網(wǎng)專線有多條鏈路可切換，帶寬儲備充足。

在騰訊會議做高級別會議匯報的時候也經(jīng)常做切換演練，幾條專線可以互相切，實際應(yīng)用下來內(nèi)網(wǎng)質(zhì)量整體比較穩(wěn)定。

4.4 房間管理

在房間管理部分，我們從原來的集中式管理升級為分布式房間管理和信令通道， RoomSvc只保存用戶列表和視頻用戶列表的基本信息，極大減輕控制系統(tǒng)的負(fù)擔(dān)。由于原來采用的是集中式架構(gòu)，瓶頸非常明顯，在新架構(gòu)下，我們對房間按訂閱關(guān)系進行了拆解，在內(nèi)部集群做了一層收斂，這樣運算量就會非常少，從而實現(xiàn)了房間規(guī)模的擴展。

RoomSvc所有信息可動態(tài)擴展并快速恢復(fù)。比如核心節(jié)點宕機，這個核心節(jié)點的信息在其他的節(jié)點中都有，只需要換一臺機器，并把原來的信息搬到這臺機器上，就可以得到完整信息。再比如Set中有一個小的節(jié)點宕機，但媒體節(jié)點里的信息是完整的，換一個新的機器，將數(shù)據(jù)重新構(gòu)建，那么這個房間就可以重新構(gòu)建出來。

在新的架構(gòu)下，我們保守估計單房間可支持100萬人，且具備高可用、高可擴展，高可靠等特點。

4.5 實踐落地成果

這套架構(gòu)在去年疫情期前期發(fā)揮了重要作用，騰訊會議和騰訊課堂在疫情初期，每天同時在線人數(shù)都呈現(xiàn)翻倍上漲的現(xiàn)象，依靠這套架構(gòu)，我們7天擴容100萬核心，同時撐住了這兩大產(chǎn)品千萬級用戶同時在線、億級用戶使用。

大規(guī)模的視頻會議現(xiàn)在變得越來越常見，比如騰訊會議從300方到企業(yè)版2000方，不久還會提供更大規(guī)模的會議產(chǎn)品形態(tài)。有些機構(gòu)的大班課/超級小班課現(xiàn)在開始嘗試使用RTC代替標(biāo)準(zhǔn)直播來提升上課體驗，大房間場景未來也會越來越多。

05

TRTC技術(shù)優(yōu)化實踐

——RTC平臺媒體處理子系統(tǒng)

5.1?媒體處理子系統(tǒng)優(yōu)點與問題

最后向大家探討關(guān)于RTC平臺的媒體處理子系統(tǒng)。RTC的媒體處理子系統(tǒng)——比如錄制、鑒黃、播片、混流轉(zhuǎn)推等，本質(zhì)上是一個旁路系統(tǒng)，現(xiàn)在業(yè)界通用的做法是讓一個linux sdk機器人模擬進房，把流拉到服務(wù)器本地，做出處理之后再轉(zhuǎn)旁路出去。

Linux sdk機器人模擬進房不會影響兩個房間的主業(yè)務(wù)流程。媒體處理子系統(tǒng)需求變更通常不需要動核心系統(tǒng)，且可以實現(xiàn)非常靈活復(fù)雜的業(yè)務(wù)邏輯，比如需要做白板和視頻的對齊、K歌的場景下可以把音頻和時間戳精確對齊，通過這樣的模式可以實現(xiàn)復(fù)雜度的隔離。

但我們在做騰訊會議和呼叫中心的時候遇到兩個難題。騰訊會議的場景需要打電話，最初的想法是用機器人進到房間之后把流拉回來，并轉(zhuǎn)成g.711、g.729放到PSTN網(wǎng)絡(luò)中就可以了。由于播放IVR是全房廣播或是針對一個人單獨廣播，所以IVR需要排他式的播放，在SFU的轉(zhuǎn)發(fā)架構(gòu)下不太容易做精確控制，不管是對新進的控制、還是媒體的識別都是比較復(fù)雜、難以控制的。

此外，語音錄制的情況下，金融行業(yè)的客戶是不能接受在錄制過程中有多錄或是少錄幾個字的情況的，就像在念身份證號時少幾位數(shù)字是絕對不可以的。但是系統(tǒng)中如果是采用機器人的方式去做，由于是兩個系統(tǒng)的整合，系統(tǒng)之間會出現(xiàn)抖動、延遲，就導(dǎo)致錄了不該錄的內(nèi)容或者該錄的沒錄下來，這些情況對于較為苛刻的用戶是絕對不可以接受的。

5.2 混音引擎解決問題

由于上述問題，我們采用了混音引擎，通過混音引擎將流做集中式的處理，既節(jié)省帶寬、又方便實現(xiàn)IVR和錄制功能，打通TRTC與PSTN電話系統(tǒng)，實現(xiàn)融合通信能力。

我們還與騰訊會議合作，做了PSTN窄帶語音頻域超分?jǐn)U展和線路雜音檢測和消除，進一步提升通話質(zhì)量，PSTN的融合通信能力是TRTC的特色功能，廣泛應(yīng)用于客服、呼叫中心和會議場景等。

06

展望未來

雖然疫情在客觀上推動了實時音視頻行業(yè)的發(fā)展，但RTC仍然處在爆發(fā)前夜。目前比如社交、云游戲、遠程實時控制、合唱等RTC重要場景雖然已經(jīng)有落地應(yīng)用，但體驗都無法達到最佳，或者存在各種各樣的限制。未來隨著網(wǎng)絡(luò)基礎(chǔ)設(shè)施和終端軟硬件能力的提升，端到端平均延遲能達到50-80ms，RTC產(chǎn)品的體驗也將會有質(zhì)的提升，場景和應(yīng)用也會迸發(fā)出更多活力。

以上是我今天的分享，謝謝大家。

- The cover from?creativeboom.com

講師招募?LiveVideoStackCon 2021 北京站

LiveVideoStackCon 2021 北京站（9月3-4日）正在面向社會公開招募講師，歡迎通過?speaker@livevideostack.com?提交個人及議題資料，無論你的公司大小，title高低，老鳥還是菜鳥，只要你的內(nèi)容對技術(shù)人有幫助，其他都是次要的，我們將會在24小時內(nèi)給予反饋。

總結(jié)

以上是生活随笔為你收集整理的实时音视频技术的演进与应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。