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

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

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

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

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

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

我們一起回顧一下本次分享的過(guò)程：

整個(gè)直播中臺(tái)價(jià)值定位

盡管我們名叫為直播中臺(tái)，但我們的音視頻能力不僅只是直播，也包含了點(diǎn)播，因?yàn)橛兄辈バ枨螅蜁?huì)有支持回放的點(diǎn)播需求。

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

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

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

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

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

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

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

好未來(lái)RTC整體能力是基于自研UDP私有協(xié)議和標(biāo)準(zhǔn)WebRTC協(xié)議搭建的，從而實(shí)現(xiàn)私有RTC與WebRTC相互打通，WebRTC作為私有RTC的一個(gè)補(bǔ)充。

整個(gè)直播中臺(tái)RTC的能力架構(gòu)，是建設(shè)在IaaS層計(jì)算資源的基礎(chǔ)上，目前的策略使用的是云主機(jī)加線(xiàn)下IDC機(jī)房的組網(wǎng)方式，使用IDC的機(jī)房的原因是網(wǎng)網(wǎng)絡(luò)質(zhì)量、線(xiàn)路質(zhì)量有保障，這部分資源作為兜底資源，而云主機(jī)主要是為了應(yīng)對(duì)快速?gòu)椥陨炜s，例如當(dāng)線(xiàn)上的用量有突發(fā)需要快速擴(kuò)容時(shí)可以選擇云主機(jī)，當(dāng)線(xiàn)上用量下降時(shí)快速縮容云主機(jī)。

為了應(yīng)對(duì)量及突發(fā)時(shí)達(dá)到快速?gòu)椥陨炜s的目的，我們?cè)诖嘶A(chǔ)上構(gòu)建了一個(gè)可視化管理后臺(tái)，能夠高效的通過(guò)可視化頁(yè)面的方式快速擴(kuò)容，目前能夠?qū)崿F(xiàn)分鐘級(jí)擴(kuò)容/下線(xiàn)上百臺(tái)機(jī)器，針對(duì)線(xiàn)上用量做精細(xì)化管理，保障線(xiàn)上穩(wěn)定可用的同時(shí)做到精細(xì)化成本管理，降低業(yè)務(wù)成本。

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

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

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

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

TalRTC整體架構(gòu)

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

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

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

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

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

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

最右是信令模塊、日志采集模塊，以及本地錄制、推流到CDN的模塊、拉流器等模塊。拉流器是RTMP拉流器，因?yàn)槲覀兊腟DK提供兩種模塊組合，一種提供方式是純RTC模塊，另外一種方式RTMP模塊+RTC模塊。

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

1 節(jié)點(diǎn)分配策略

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

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

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

2 路由策略

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

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

3 單點(diǎn)&同運(yùn)營(yíng)商、多點(diǎn)&跨運(yùn)營(yíng)商調(diào)度

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

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

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

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

4 業(yè)務(wù)異常恢復(fù)

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

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

5 媒體節(jié)點(diǎn)異常恢復(fù)

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

接下來(lái)我們針對(duì)不同場(chǎng)景分析一下異常恢復(fù)邏輯：

首先，先看一下單線(xiàn)媒體節(jié)點(diǎn)異常恢復(fù)邏輯。電信用戶(hù)A和用戶(hù)B進(jìn)行1V1的音視頻通話(huà)，開(kāi)始時(shí)電信用戶(hù)A連接電信節(jié)點(diǎn)1，電信用戶(hù)B連接電信節(jié)點(diǎn)2，電信節(jié)點(diǎn)1和電信節(jié)點(diǎn)2建立起級(jí)聯(lián)連接，在雙方通話(huà)過(guò)程中電信節(jié)點(diǎn)1機(jī)房突然出現(xiàn)網(wǎng)絡(luò)故障，此時(shí)會(huì)自動(dòng)啟動(dòng)節(jié)點(diǎn)切換邏輯，電信用戶(hù)A 的客戶(hù)端會(huì)自動(dòng)切換到備用節(jié)點(diǎn)電信節(jié)點(diǎn)3并與其建立連接，電信節(jié)點(diǎn)2和電信節(jié)點(diǎn)3之間建立級(jí)聯(lián)連接，保障平滑切換鏈路，整個(gè)切換過(guò)程終端用戶(hù)無(wú)感知。

接下來(lái)再看一下多線(xiàn)媒體節(jié)點(diǎn)異常恢復(fù)邏輯，多線(xiàn)的邏輯也是類(lèi)似的，假設(shè)電信用戶(hù)A和聯(lián)通用戶(hù)B進(jìn)行1V1的音視頻通話(huà)，由于跨運(yùn)營(yíng)商，所以需要三線(xiàn)節(jié)點(diǎn)3做轉(zhuǎn)發(fā)或中轉(zhuǎn)。假設(shè)三線(xiàn)節(jié)點(diǎn)3所在的機(jī)房網(wǎng)絡(luò)故障，電信節(jié)點(diǎn)1和聯(lián)通節(jié)點(diǎn)2會(huì)自動(dòng)切換到備用的三線(xiàn)節(jié)點(diǎn)4，與三線(xiàn)節(jié)點(diǎn)4重新建立連接，從而保證雙方音視頻通話(huà)不受影響。

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

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

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

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

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

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

AVsync模塊主要負(fù)責(zé)音畫(huà)同步，保證音視頻通話(huà)的體驗(yàn)。

針對(duì)教育場(chǎng)景的特殊優(yōu)化

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

教育場(chǎng)景下無(wú)論大班課還是小班課，學(xué)生上課的時(shí)候最關(guān)心的肯定是老師的流，其他學(xué)生的動(dòng)作，學(xué)生本人不關(guān)心或者關(guān)心程度很低，所以，老師的那路流需要重點(diǎn)保障。

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

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

第二，推拉流的回退策略

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

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

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

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

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

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

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