「好未來」馮權成：實時音視訊在教育場景下的成熟應用

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

此次分享的主要內容包含四個部分：

· 直播中臺產品全景介紹

· TalRTC整體架構

· 高可用及弱網對抗策略

· 針對教育場景的特殊優化

全場圍繞如何使用技術手段最大限度保障老師和學生上課的音視訊質量，可謂乾貨滿滿。

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

整個直播中臺價值定位

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

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

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

直播中臺支持的前臺業務有大班、培優小組課、網校1V1等等，覆蓋了大班、小班、1V1等課堂形式。此外還支持了內部的IM辦公軟體音視訊通話、在線會議等應用場景。

直播中臺的音視訊能力整體架構

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

RTC的錄制會把文件上傳到點播雲進行處理；CDN直播配有RTMP錄制，同樣也會把文件上傳到點播雲長進行處理，點播雲對視訊進行二次加工，剪輯、裁剪、拼接、截圖、水印或者轉碼等其他相幹媒體的處理能力，便於學生課後觀看回放復習或者教學內容的二次推廣。

直播中臺RTC能力整體架構

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

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

為了應對量及突發時達到快速彈性伸縮的目的，我們在此基礎上構建了一個可視化管理後臺，能夠高效的通過可視化頁面的方式快速擴容，目前能夠實現分鐘級擴容/下線上百臺機器，針對線上用量做精細化管理，保障線上穩定可用的同時做到精細化成本管理，降低業務成本。

直播中臺產品全景圖

直播中臺的產品全景圖從底層的RTC服務端到RTC的客戶端，到中間的調度管理、負載均衡、房間管理、後臺管理、雲控相幹以及引擎切換相幹的系統。最上層是對外提供標準化產品服務的官網和開發者中心，方便前臺的業務高效、便捷使用我們的產品和服務，減少內部對接的成本，提高效率。

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

全鏈路質量監控，技術支持接到前臺業務反饋線上有問題後，通過全鏈路監控系統快速定位問題。日志埋點模塊基於埋點日志，做日志分析，大數據的處理，給前面這些服務質量保障系統提供數據支撐。

TalRTC整體架構

馮權成績好未來RTC整體架構進行了介紹，大概分為三層。

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

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

最右邊是分布式緩存系統，緩存業務服務器相幹的數據，如業務服務器的資源情況、可用服務器的狀態、健康度等，調度服務器根據上述資訊進行調度。後臺管理系統就是我們前面提到的服務質量支撐管理系統，這裡不再贅述。

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

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

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

高可用及弱網對抗策略

1 節點分配策略

RTN在跟客戶端分配媒體節點時，會根據三個資訊做節點的分配。第一，是地區；第二，運營商；第三，大數據的分析。

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

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

2 路由策略

路由策略會根據3個資訊來做路由，第一，路徑最短；第二，延遲最低；第三，丟包最少。

基於上述三個資訊，選擇出可用路由，經過負載均衡，選出最佳路由節點，同時選一個作為備用路由節點，當最佳路由節點不可用時，客戶端可以自動做路由的切換，保障用戶無感的情況下，完成切換工作，從而實現高可用地保障用戶體驗。

3 單點&同運營商、多點&跨運營商調度

RTN的調度系統目前有多種調度方式，支持單點、多點、同運營商、跨運營商等調度方式。

單點和同運營商調度比較簡單，客戶端向調度服務器請求媒體節點，調度服務器向客戶端分配同地區、同運營商的媒體節點。

跨地區、跨運營商的調度相對龐雜一點，如北京移動的學生要跟上海電信的老師進行1V1通話，調度服務器會分別給北京移動的學生分配北京移動的媒體節點、給上海電信的老師分配上海電信的媒體節點，北京移動媒體節點和上海電信媒體節點之間通過上海多線媒體節點進行轉發。

跨運營商及地區的情況下，首先根據客戶端所屬的運營商來給他分配最近區域同運營商的媒體節點，再通過多線節點做級聯轉發。

4 業務異常恢復

客戶端首先向調度服務器請求最優媒體節點，業務服務器的心跳服務，會定期上報媒體服務器的心跳，如：服務器可用資源、水位、服務器健康度、負載情況、丟包、延遲等資訊，調度服務器根據這些資訊來做調度。

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

5 媒體節點異常恢復

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

接下來我們針對不同場景分析一下異常恢復邏輯：

首先，先看一下單線媒體節點異常恢復邏輯。電信用戶A和用戶B進行1V1的音視訊通話，開始時電信用戶A連接電信節點1，電信用戶B連接電信節點2，電信節點1和電信節點2建立起級聯連接，在雙方通話過程中電信節點1機房突然出現網路故障，此時會自動啟動節點切換邏輯，電信用戶A 的客戶端會自動切換到備用節點電信節點3並與其建立連接，電信節點2和電信節點3之間建立級聯連接，保障平滑切換鏈路，整個切換過程終端用戶無感知。

接下來再看一下多線媒體節點異常恢復邏輯，多線的邏輯也是類似的，假設電信用戶A和聯通用戶B進行1V1的音視訊通話，由於跨運營商，所以需要三線節點3做轉發或中轉。假設三線節點3所在的機房網路故障，電信節點1和聯通節點2會自動切換到備用的三線節點4，與三線節點4重新建立連接，從而保證雙方音視訊通話不受影響。

6 SDK弱網對抗策略

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

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

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

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

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

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

針對教育場景的特殊優化

第一，優先拉「老師流」策略

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

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

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

第二，推拉流的回退策略

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

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

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

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

然而，傳統的3A算法存在一些問題，比如對對非線性回聲清除不乾淨、對非平穩突發噪聲抑制能力差。針對當前的業務痛點，直播中臺與集團AI研究院合作，將AI算法與實時音視訊的技術結合起來，創新性的將AI算法用於音頻3A優化中，顯著改善了傳統音頻3A算法的不足。

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

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