亞太內(nèi)容分發(fā)大會暨CDN峰會一直致力于推動CDN產(chǎn)業(yè)深度融合發(fā)展和市場普及，現(xiàn)已成為亞太地區(qū)影響力最大的內(nèi)容分發(fā)網(wǎng)絡盛會。十年來，在以阿里云、網(wǎng)宿科技、騰訊云等亞太CDN產(chǎn)業(yè)聯(lián)盟成員孜孜不輟的努力下，CDN產(chǎn)業(yè)已經(jīng)成為基礎性設施網(wǎng)絡，以堅定的基石之姿，支撐起中國成為世界最大的互聯(lián)網(wǎng)市場。

隨著全球數(shù)字化、“一帶一路”戰(zhàn)略的推進，亞太內(nèi)容分大會暨CDN峰會的影響力正在逐漸向全球延伸，同時也將中國智造CDN及產(chǎn)業(yè)鏈推廣向全球每一個角落。

2021年6月9日，「亞太內(nèi)容分發(fā)大會暨CDN峰會」在北京舉行，好未來直播中臺產(chǎn)品負責人馮權(quán)成出席大會的論壇「互動直播論壇」，并發(fā)表題為「實時音視頻在教育場景下的成熟應用」的主題演講，向業(yè)界介紹了好未來在RTC（Real Time Communication，實時通信）領域所取得的的技術(shù)成果和在教育場景下的成熟應用。本次大會上，好未來榮膺亞太內(nèi)容分發(fā)大會RTC技術(shù)創(chuàng)新獎。

此次分享的主要內(nèi)容包含四個部分：

· 直播中臺產(chǎn)品全景介紹
· TalRTC整體架構(gòu)
· 高可用及弱網(wǎng)對抗策略
· 針對教育場景的特殊優(yōu)化

全場圍繞如何使用技術(shù)手段最大限度保障老師和學生上課的音視頻質(zhì)量，可謂干貨滿滿。

我們一起回顧一下本次分享的過程：

整個直播中臺價值定位

盡管我們名叫為直播中臺，但我們的音視頻能力不僅只是直播，也包含了點播，因為有直播需求，就會有支持回放的點播需求。

直播中臺的定位是在集團后臺的支撐下，向前臺的業(yè)務提供音視頻的能力，如自研RTC、RTMP直播、點播等音視頻能力。

同時好未來通過適配層封裝自研及其他廠商的方式，向前臺提供音視頻產(chǎn)品能力，這主要是出于災備、價格、技術(shù)之間相互PK、相互學習等的考慮。

直播中臺支持的前臺業(yè)務有大班、培優(yōu)小組課、網(wǎng)校1V1等等，覆蓋了大班、小班、1V1等課堂形式。此外還支持了內(nèi)部的IM辦公軟件音視頻通話、在線會議等應用場景。

直播中臺的音視頻能力整體架構(gòu)

圍繞RTC這一核心產(chǎn)品，衍生出了全場景的音視頻產(chǎn)品矩陣，比如可以通過RTC的媒體服務做轉(zhuǎn)推，推流到CDN，我們搭建了支持標準CDN直播協(xié)議的直播云。

RTC的錄制會把文件上傳到點播云進行處理；CDN直播配有RTMP錄制，同樣也會把文件上傳到點播云上進行處理，點播云對視頻進行二次加工，剪輯、裁剪、拼接、截圖、水印或者轉(zhuǎn)碼等其他相關媒體的處理能力，便于學生課后觀看回放復習或者教學內(nèi)容的二次推廣。

直播中臺RTC能力整體架構(gòu)

好未來RTC整體能力是基于自研UDP私有協(xié)議和標準WebRTC協(xié)議搭建的，從而實現(xiàn)私有RTC與WebRTC相互打通，WebRTC作為私有RTC的一個補充。

整個直播中臺RTC的能力架構(gòu)，是建設在IaaS層計算資源的基礎上，目前的策略使用的是云主機加線下IDC機房的組網(wǎng)方式，使用IDC的機房的原因是網(wǎng)網(wǎng)絡質(zhì)量、線路質(zhì)量有保障，這部分資源作為兜底資源，而云主機主要是為了應對快速彈性伸縮，例如當線上的用量有突發(fā)需要快速擴容時可以選擇云主機，當線上用量下降時快速縮容云主機。

為了應對量及突發(fā)時達到快速彈性伸縮的目的，我們在此基礎上構(gòu)建了一個可視化管理后臺，能夠高效的通過可視化頁面的方式快速擴容，目前能夠?qū)崿F(xiàn)分鐘級擴容/下線上百臺機器，針對線上用量做精細化管理，保障線上穩(wěn)定可用的同時做到精細化成本管理，降低業(yè)務成本。

直播中臺產(chǎn)品全景圖

直播中臺的產(chǎn)品全景圖從底層的RTC服務端到RTC的客戶端，到中間的調(diào)度管理、負載均衡、房間管理、后臺管理、云控相關以及引擎切換相關的系統(tǒng)。最上層是對外提供標準化產(chǎn)品服務的官網(wǎng)和開發(fā)者中心，方便前臺的業(yè)務高效、便捷使用我們的產(chǎn)品和服務，減少內(nèi)部對接的成本，提高效率。

右側(cè)是一套服務支撐以及保障系統(tǒng)，比如駕駛艙管理系統(tǒng)，主要負責實現(xiàn)彈性擴容、引擎切換、云控配置下發(fā)等功能；其中需要重點談一下云控配置下發(fā)功能，主要實現(xiàn)調(diào)度策略及權(quán)重的配置下發(fā)、以及部分新功能需要云控灰度下發(fā)等。告警系統(tǒng)是全鏈路的監(jiān)控系統(tǒng)，主要監(jiān)控音視頻的質(zhì)量、五大指標（入會成功率、延時、卡頓、音畫同步、端上性能開銷）和服務器資源水位監(jiān)控，通過可視化的管理頁面，實現(xiàn)快速的針對異常情況進行提前干預和保障。

全鏈路質(zhì)量監(jiān)控，技術(shù)支持接到前臺業(yè)務反饋線上有問題后，通過全鏈路監(jiān)控系統(tǒng)快速定位問題。日志埋點模塊基于埋點日志，做日志分析，大數(shù)據(jù)的處理，給前面這些服務質(zhì)量保障系統(tǒng)提供數(shù)據(jù)支撐。

TalRTC整體架構(gòu)

馮權(quán)成就好未來RTC整體架構(gòu)進行了介紹，大概分為三層。

第一層，SDK終端接入，終端SDK通過DNS解析到負載均衡服務器集群，之后負載均衡服務會給終端SDK分配一臺調(diào)度服務器（IPLocation），調(diào)度服務器會告訴客戶端去連接哪臺媒體服務器，客戶端和媒體服務器建立起連接后，開始信令交互（SignalGW）,然后開始音視頻數(shù)據(jù)的傳輸。

媒體服務中SignalGW主要負責包括入會退會或者相關信令的通知，Record負責錄制服務，Audio負責音頻的轉(zhuǎn)發(fā)，AudioMix負責音頻混流，Video負責視頻的轉(zhuǎn)發(fā)，VideoMix負責視頻混流， LocalLog負責本地日志落盤。Convert負責轉(zhuǎn)推到CDN，將RTC轉(zhuǎn)成RTMP推流給CDN進行大規(guī)模分發(fā)，從而解決需要高并發(fā)場景的需求，例如在線大班課，需要千萬級并發(fā)同時在線觀看。

最右邊是分布式緩存系統(tǒng)，緩存業(yè)務服務器相關的數(shù)據(jù)，如業(yè)務服務器的資源情況、可用服務器的狀態(tài)、健康度等，調(diào)度服務器根據(jù)上述信息進行調(diào)度。后臺管理系統(tǒng)就是我們前面提到的服務質(zhì)量支撐管理系統(tǒng)，這里不再贅述。

整個SDK終端接入流程如上圖，支持域名+IP的調(diào)度方式，當域名解析不通時走IP方式分配服務器。SLB的服務器會給終端分配調(diào)度服務器，調(diào)度服務器根據(jù)服務器的信息、資源水位情況、健康度情況（實時探測，服務器自身負載，以及鏈路的丟包、延遲）給終端分配最優(yōu)媒體服務器。

SDK架構(gòu)，最上層是API層，將音視頻能力通過API的形式暴露給業(yè)務層調(diào)用；API層之下有房間信息、用戶信息以及配置信息。最重要的是音頻引擎和視頻引擎，視頻引擎包含了視頻設備管理、視頻的處理、輸入外部視頻源（桌面共享、視頻自采集等）、編解碼器、媒體傳輸通道的管理、netEQ（JitterBuffer+解碼+信號處理）。音頻引擎與之類似，不再贅述。

最右是信令模塊、日志采集模塊，以及本地錄制、推流到CDN的模塊、拉流器等模塊。拉流器是RTMP拉流器，因為我們的SDK提供兩種模塊組合，一種提供方式是純RTC模塊，另外一種方式RTMP模塊+RTC模塊。

高可用及弱網(wǎng)對抗策略

1 節(jié)點分配策略

RTN在跟客戶端分配媒體節(jié)點時，會根據(jù)三個信息做節(jié)點的分配。第一，是地域；第二，運營商；第三，大數(shù)據(jù)的分析。

其中大數(shù)據(jù)分析會實時探測服務器鏈路間的丟包、延遲，得出最優(yōu)鏈路。調(diào)度服務器根據(jù)上述三類信息找到可用服務器后，以負載均衡的方式，把請求均勻得調(diào)度到不同的服務器上，會分配就近接入節(jié)點（最優(yōu)節(jié)點）、備用節(jié)點、兜底節(jié)點，當最優(yōu)節(jié)點異常時，客戶端可以自動切換到備用節(jié)點，保證用戶端無感知。

這里的就近接入不僅是距離上的就近，更主要是基于延時以及基于丟包來計算，延時最低、丟包最少的就是最近的。兜底的節(jié)點的設置是出于災備的考慮，一般情況下不會用到，只有在最優(yōu)節(jié)點和備用節(jié)點均不可用時才會用到。

2 路由策略

路由策略會根據(jù)3個信息來做路由，第一，路徑最短；第二，延遲最低；第三，丟包最少。

基于上述三個信息，選擇出可用路由，經(jīng)過負載均衡，選出最佳路由節(jié)點，同時選一個作為備用路由節(jié)點，當最佳路由節(jié)點不可用時，客戶端可以自動做路由的切換，保障用戶無感的情況下，完成切換工作，從而實現(xiàn)高可用地保障用戶體驗。

3 單點&同運營商、多點&跨運營商調(diào)度

RTN的調(diào)度系統(tǒng)目前有多種調(diào)度方式，支持單點、多點、同運營商、跨運營商等調(diào)度方式。

單點和同運營商調(diào)度比較簡單，客戶端向調(diào)度服務器請求媒體節(jié)點，調(diào)度服務器向客戶端分配同地區(qū)、同運營商的媒體節(jié)點。

跨地區(qū)、跨運營商的調(diào)度相對復雜一點，如北京移動的學生要跟上海電信的老師進行1V1通話，調(diào)度服務器會分別給北京移動的學生分配北京移動的媒體節(jié)點、給上海電信的老師分配上海電信的媒體節(jié)點，北京移動媒體節(jié)點和上海電信媒體節(jié)點之間通過上海多線媒體節(jié)點進行轉(zhuǎn)發(fā)。

跨運營商及地區(qū)的情況下，首先根據(jù)客戶端所屬的運營商來給他分配最近區(qū)域同運營商的媒體節(jié)點，再通過多線節(jié)點做級聯(lián)轉(zhuǎn)發(fā)。

4 業(yè)務異?；謴?/p>

客戶端首先向調(diào)度服務器請求最優(yōu)媒體節(jié)點，業(yè)務服務器的心跳服務，會定期上報媒體服務器的心跳，如：服務器可用資源、水位、服務器健康度、負載情況、丟包、延遲等信息，調(diào)度服務器根據(jù)這些信息來做調(diào)度。

高可用的手段大致分為三種，第一種是支持斷網(wǎng)重聯(lián)的機制，客戶端斷網(wǎng)，網(wǎng)絡恢復以后自動重聯(lián)。第二種是SDK支持切換服務器，SDK通過調(diào)度服務器獲取主節(jié)點和備用節(jié)點，當主節(jié)點不可用時可自動切換到備用節(jié)點，從而保障終端用戶無感知，不會影響老師和學生的上課體驗。第三種是兼容TCP和UDP，就TCP而言，弱網(wǎng)的情況下連接的成功率、連接的到達率會受到影響，有些服務會通過UDP的方式去做通知或廣播，提高弱網(wǎng)下抗丟包的能力。

5 媒體節(jié)點異常恢復

媒體服務支持功能模塊的進程守護機制，保障功能模塊不會假死或發(fā)生其他問題，支持故障自愈邏輯。之前提到的節(jié)點之間的切換，其實就是一種故障自愈的邏輯。

接下來我們針對不同場景分析一下異?；謴瓦壿嫞?/p>

首先，先看一下單線媒體節(jié)點異?；謴瓦壿?。電信用戶A和用戶B進行1V1的音視頻通話，開始時電信用戶A連接電信節(jié)點1，電信用戶B連接電信節(jié)點2，電信節(jié)點1和電信節(jié)點2建立起級聯(lián)連接，在雙方通話過程中電信節(jié)點1機房突然出現(xiàn)網(wǎng)絡故障，此時會自動啟動節(jié)點切換邏輯，電信用戶A 的客戶端會自動切換到備用節(jié)點電信節(jié)點3并與其建立連接，電信節(jié)點2和電信節(jié)點3之間建立級聯(lián)連接，保障平滑切換鏈路，整個切換過程終端用戶無感知。

接下來再看一下多線媒體節(jié)點異?；謴瓦壿嫞嗑€的邏輯也是類似的，假設電信用戶A和聯(lián)通用戶B進行1V1的音視頻通話，由于跨運營商，所以需要三線節(jié)點3做轉(zhuǎn)發(fā)或中轉(zhuǎn)。假設三線節(jié)點3所在的機房網(wǎng)絡故障，電信節(jié)點1和聯(lián)通節(jié)點2會自動切換到備用的三線節(jié)點4，與三線節(jié)點4重新建立連接，從而保證雙方音視頻通話不受影響。

6 SDK弱網(wǎng)對抗策略

SDK目前支持SVC分層編碼，支持兩種分層邏輯。

第一種邏輯是傳統(tǒng)意義上的SVC，支持時域分層，共分為3層，其中基礎層幀率最低（5-6fps），中間層幀率居中（10fps）,最上層幀率最高（15fps）；每一層均能被獨立解碼播放，因此即使上層丟失了，之下的層級還能夠被正常解碼播放，媒體服務器的「下行狀態(tài)統(tǒng)計決策控制器」可以根據(jù)接收端的網(wǎng)絡評估情況做相關決策，通知SVC過濾器給接收端轉(zhuǎn)發(fā)與之網(wǎng)絡情況匹配的媒體流，從而降低卡頓率。

另外一種分層編碼邏輯是大小流的邏輯，大流和小流通過一路流，在編碼時一次性編碼了兩種分辨率。同樣的，媒體服務器根據(jù)接收端的網(wǎng)絡評估情況做決策，決定給接收端轉(zhuǎn)發(fā)大流還是小流，通過媒體服務器的SVC過濾器進行轉(zhuǎn)發(fā)；當網(wǎng)絡質(zhì)量正常時轉(zhuǎn)發(fā)大流，比較差的時候轉(zhuǎn)發(fā)小流。這兩種分層編碼邏輯由「SVC Controller」控制采用哪種邏輯，下邊分程編碼及RTP/RTCP協(xié)議的打包，接下來經(jīng)過NACK重傳和FEC前向糾錯，最后經(jīng)過「Pacer Sender」平滑發(fā)送，保證在網(wǎng)絡抖動比較厲害的時候，能夠勻速地發(fā)送數(shù)據(jù)。

如果橫坐標表示時間，縱坐標表示發(fā)送的碼率，畫出來一條線應該是趨近于水平線，保證發(fā)送碼率是恒定的，接收端才能流暢拉流播放。 媒體服務器中有一個比較重要的模塊就是「下行狀態(tài)統(tǒng)計決策控制器」，該模塊會根據(jù)接收端REMB模塊評估的帶寬情況來決策，通知SVC過濾器給接收端轉(zhuǎn)發(fā)適合接收端網(wǎng)絡條件的媒體流。當接收端帶寬資源過剩時，向其轉(zhuǎn)發(fā)高幀率、高分辨率的流；反之則會向其轉(zhuǎn)發(fā)低幀率、低分辨率的流。

此外，接收端還有一個弱網(wǎng)對抗模塊JitterBuffer,該模塊為接收端緩沖區(qū)，負責對數(shù)據(jù)包的丟失、延遲、亂序等情況進行處理，配合NACK重傳，從而實現(xiàn)抗丟包，降低弱網(wǎng)環(huán)境下的卡頓率。

AVsync模塊主要負責音畫同步，保證音視頻通話的體驗。

針對教育場景的特殊優(yōu)化

第一，優(yōu)先拉“老師流”策略

教育場景下無論大班課還是小班課，學生上課的時候最關心的肯定是老師的流，其他學生的動作，學生本人不關心或者關心程度很低，所以，老師的那路流需要重點保障。

優(yōu)先拉老師流的架構(gòu)如上圖所示，為了作為對比，我們先說一下之前沒有優(yōu)先拉老師流策略的架構(gòu)，右側(cè)這個多路媒體資源控制器是沒有的，因此每一路流都是獨立的，N路流的帶寬評估是獨立評估，當學生端的帶寬資源有瓶頸時很難保障學生拉所有流都不卡。

有了統(tǒng)一帶寬評估策略，把多路流消化的帶寬做統(tǒng)一評估，從流1到流N所有消耗的帶寬，由右側(cè)這個多路媒體資源控制器去做統(tǒng)一評估，得出接收端帶寬資源最大能夠拉多大碼率的流，如果帶寬不足以拉所有流的話，就優(yōu)先保障老師的流，最大限度保障學生的上課體驗。

第二，推拉流的回退策略

在一些弱網(wǎng)的場景下，學生要拉多方的流，或者說即便只拉一方的流，音頻和視頻兩路流都要拉的話，在極端弱網(wǎng)情況下是很難保障流暢性的。TalRTC的回退策略是當網(wǎng)絡比較差的時候，接收端的REMB負責帶寬評估以后，會將評估數(shù)據(jù)發(fā)送給流媒體服務器，如果認為當前學生端的網(wǎng)絡情況不能滿足拉視頻大流時，會通知回退控制器，回退控制器又通知轉(zhuǎn)發(fā)過濾器，先回退到只轉(zhuǎn)發(fā)小流，如果接收端的網(wǎng)絡條件還是不滿足拉視頻小流，再回退到純音頻。

這樣能夠保障在極端弱網(wǎng)情況下，學生即使不能流暢看老師的視頻，至少還能夠聽到老師的聲音，不會錯過重要的知識點，最大限度地保障了學生的上課質(zhì)量。

第三，基于AI的音頻3A算法—AI_AEC。

大家都知道，音頻前處理的3A算法是實時通信里很重要的一種技術(shù)，音頻3A算法保證了實時互動時的音頻質(zhì)量：語音清晰、沒有噪音、沒有回聲、聲音大小合適。

然而，傳統(tǒng)的3A算法存在一些問題，比如對對非線性回聲消除不干凈、對非平穩(wěn)突發(fā)噪聲抑制能力差。針對當前的業(yè)務痛點，直播中臺與集團AI研究院合作，將AI算法與實時音視頻的技術(shù)結(jié)合起來，創(chuàng)新性的將AI算法用于音頻3A優(yōu)化中，顯著改善了傳統(tǒng)音頻3A算法的不足。

基于AI算法實現(xiàn)的噪聲抑制，目前主要支持一些特定場景的噪聲抑制，例如老師或者學生在家上課的時候，環(huán)境中其他人發(fā)出的咳嗽聲、開關門聲、敲鍵盤聲、或者臨街環(huán)境有汽車鳴笛聲等，對于這類非平穩(wěn)的突發(fā)的噪聲用傳統(tǒng)的降躁算法是很難消除干凈的，而基于特定場景訓練的AI模型就能夠徹底將噪聲消除干凈。

好的，今天的分享到此結(jié)束，感謝大家的聆聽；