導讀：?5G 與 AI 技術(shù)推動音視頻技術(shù)持續(xù)演進，RTC 技術(shù)在多個行業(yè)得到了充分應(yīng)用，但各行業(yè)的業(yè)務(wù)有著不同的需求，因此就需要構(gòu)建一套 RTC 融合通信服務(wù)系統(tǒng)，為產(chǎn)品的創(chuàng)新提供堅實的基礎(chǔ)。本次分享將重點分享：網(wǎng)易云信 RTC 融合通信服務(wù)架構(gòu)，并結(jié)合近期熱門的娛樂社交與在線教育場景，從解決各業(yè)務(wù)場景痛點和難點切入，為大家講解 RTC 融合通信的核心技術(shù)和最佳實踐。

文｜吳桐

網(wǎng)易云信流媒體首席架構(gòu)師

背景

?RTC 行業(yè)2021年整體發(fā)展?

這兩年 RTC 行業(yè)的迅猛發(fā)展，不管是在泛娛樂行業(yè)的云游戲、音樂、社交、語聊、直播和短視頻，還是在在線教育，都能看到增長曲線是非常可觀的。從技術(shù)發(fā)展方向上來說，RTC、直播和 VOIP 通信越來越往融合一體化方案架構(gòu)上發(fā)展，各平臺也逐步推出?All in One 的解決方案，這方面的內(nèi)容我會在今天分享的第二部分詳細展開；娛樂社交和在線教育的 RTC 技術(shù)不斷創(chuàng)新，針對各類垂直領(lǐng)域也涌現(xiàn)出很多的音視頻技術(shù)的創(chuàng)新方案，這些創(chuàng)新方案會在今天分享的第三、四部分重點闡述；我相信隨著音視頻相關(guān)需求的日益增加，未來音視頻行業(yè)還將持續(xù)高速的增長，也有著無限的機會等著音視頻行業(yè)的從業(yè)人員，有機會當然也會有挑戰(zhàn)。

?RTC 融合通信后端服務(wù)挑戰(zhàn)?

• 在融合通信系統(tǒng)里，需要接入各種類型的客戶端，各客戶端的協(xié)議也非常多樣，包括私有協(xié)議，以及各類標準協(xié)議，比如：WebRTC、RTMP、SIP、PSTN 和 RTSP 等等；為了解決協(xié)議接入的問題，融合通信服務(wù)端必須具備很強的協(xié)議兼容能力。

• 隨著 All in One 的推行，融合通信服務(wù)端需要承載的并發(fā)也越來越大，包括單頻道的百萬并發(fā)，以及晚高峰的的流量蜂擁，這就要求我們的系統(tǒng)具備很好的彈性擴縮容能力。

• 隨著全球化用戶接入，還需要面對全球范圍內(nèi)復雜多變的網(wǎng)絡(luò)情況，包括小運營商，偏遠地區(qū)和非洲等國家的 2.5G 和 3G 網(wǎng)絡(luò)，以及更為復雜的跨國通話的網(wǎng)絡(luò)問題。
  

RTC 融合通信服務(wù)架構(gòu)

?多協(xié)議融合通信 RTC 系統(tǒng)?

首先我們從全局的維度來看看云信是怎么做的多協(xié)議融合通信 RTC 系統(tǒng)的，整個架構(gòu)的中間，是我們的流媒體傳輸與處理服務(wù)器，其中包括了邊緣媒體接入系統(tǒng)、實時傳輸網(wǎng)系統(tǒng)、流媒體處理服務(wù)系統(tǒng)以及直播點播服務(wù)系統(tǒng)。在新一代的音視頻融合通信系統(tǒng)中，我們除了云信 SDK 以外還支持了多種協(xié)議客戶端的接入，在邊緣媒體接入服務(wù)模塊中，我們的邊緣媒體服務(wù)器既支持云信 SDK 的接入，也直接支持了標準 Web 端使用 WebRTC 接入；另外我們自研了 SIP 網(wǎng)關(guān)服務(wù)器，實現(xiàn)了 SIP、PSTN 的接入；我們使用通用媒體網(wǎng)關(guān)實現(xiàn)了標準 RTMP 推流工具、小程序、RTSP 監(jiān)控攝像頭的接入。

在邊緣媒體服務(wù)系統(tǒng)收到各協(xié)議客戶端的媒體數(shù)據(jù)包以后，會再通過我們實時傳輸網(wǎng)的邊緣節(jié)點和路由節(jié)點進行全球的實時媒體數(shù)據(jù)分發(fā)，保證端到端的最優(yōu)體驗。同時利用流媒體處理服務(wù)的通用 MCU 和轉(zhuǎn)碼服務(wù)器，可以將媒體流混合以后通過旁路轉(zhuǎn)推到我們的互動直播服務(wù)器，再通過我們直播的融合 CDN 系統(tǒng)進行分發(fā)；還可以在云端進行錄制后，存儲到云信的點播服務(wù)系統(tǒng)中。

在流媒體傳輸與處理服務(wù)系統(tǒng)的左側(cè)是我們的全局流媒體控制服務(wù)，它包括了：頻道與流管理服務(wù)，統(tǒng)一媒體調(diào)度服務(wù)和實時傳輸網(wǎng)調(diào)度服務(wù)，他是整個音視頻融合通信系統(tǒng)的大腦，由它來動態(tài)控制整個系統(tǒng)的運轉(zhuǎn)。

在最右側(cè)，是我們的大數(shù)據(jù)與配置服務(wù)系統(tǒng)，它包括了我們的全局大數(shù)據(jù)分析和挖掘系統(tǒng)，負責全鏈路各個采集的數(shù)據(jù)處理、告警和質(zhì)量透明，并利用大數(shù)據(jù)挖掘的結(jié)果指導全鏈路各模塊算法和策略的制定，另一個是我們智能全局配置管理和下發(fā)服務(wù)，它負責對我們各類云端參數(shù)的下發(fā)，包括 QoS 參數(shù)，音視頻編解碼參數(shù)以及 A/B test 的相關(guān)開關(guān)。

我們對新一代音視頻融合系統(tǒng)架構(gòu)做個總結(jié)，首先新版音視頻融合通信系統(tǒng)是一個混合了實時媒體邊緣服務(wù)器、實時傳輸網(wǎng)以及融合 CDN 的一個多協(xié)議混合組網(wǎng)系統(tǒng)，它可以滿足用戶的各類對場景和網(wǎng)絡(luò)實時性的需求；第二，我們的媒體邊緣服務(wù)器和媒體網(wǎng)關(guān)下沉到邊緣，大大降低了用戶到第一跳接入服務(wù)的的距離，也可以更好的發(fā)揮 5G 邊緣計算的能力。

雖然我們可以靠媒體服務(wù)器級聯(lián)來實現(xiàn) RTC 服務(wù)器的高并發(fā)，但是為了降低成本和提升整個系統(tǒng)的容量上限，最大程度的提升單臺服務(wù)器并發(fā)能力還是非常重要的。

?超高并發(fā) RTC 媒體服務(wù)器?

為了提高服務(wù)器的性能，從充分利用多核 CPU 的角度上至少有兩種明確的方案（第三種就近年來以 golang 為主的協(xié)程方案）：多線程和多進程。云信先后使用了這兩種方案來實現(xiàn)云信 RTC 的媒體服務(wù)器。

單進程多線程：

首先我們來看看單進程多線程的架構(gòu)，我們采用?Reuseport+IO?讀多線程的方案來實現(xiàn)高性能的 IO 讀，這里利用了 Linux 內(nèi)核 Reuseport 的負載均衡，會根據(jù)收發(fā)四元組做負載均衡。IO 線程收到數(shù)據(jù)包以后，會將數(shù)據(jù)包投遞到后側(cè)的 Worker 多線程上進一步處理業(yè)務(wù)邏輯，信令和媒體的處理都在 Worker 多線程上。這個架構(gòu)使用多線程很好的利用了多核 CPU 的能力，整體的性能在業(yè)務(wù)邏輯不復雜的階段，還是非常不錯的。但是隨著需求的演進也面臨很多問題和挑戰(zhàn)：

1、在業(yè)務(wù)邏輯復雜以后，多線程的架構(gòu)的加鎖操作會過多，導致性能受到影響；

2、因為是單進程，而 C++程序的崩潰是一個很難不發(fā)生的問題，單進程崩潰后，影響范圍比較大；

3、多線程程序?qū)幋a要求高，特別是很多新人對代碼不熟悉時，比較容易犯錯，而多線程的問題，往往又比較隱蔽，定位和 debug 的難度也比較大。

所以隨著項目的迭代，漸漸的我們開始針對單進程多線程的架構(gòu)進一步進行了迭代。

多進程架構(gòu)：

在新的架構(gòu)中，我們采用了多進程的架構(gòu)。Master 進程作為父進程，同時也作為其它進程的守護進程，不做其它任何復雜業(yè)務(wù)，因此 Master 進程的穩(wěn)定性是比較高的。信令、媒體進程均作為 Master 進程的子進程，信令進程和媒體進程都是單進程單線程架構(gòu)，大大減少了多線程加鎖的操作；所有的媒體進程只需要和信令進程交互，媒體進程相互之間無需交互。這個架構(gòu)其實有點像 Nginx 的架構(gòu)，架構(gòu)的性能、穩(wěn)定性都比較好。目前云信在全球范圍的媒體服務(wù)器都采用這種架構(gòu)，系統(tǒng)的的穩(wěn)定性得到明顯的提高。

?WE-CAN 全球組網(wǎng)?

看完了接入?yún)f(xié)議的多樣性和海量并發(fā)的應(yīng)對方案以后，我們來解決全球范圍內(nèi)節(jié)點網(wǎng)絡(luò)互聯(lián)問題。為了解決這個問題我們把目光轉(zhuǎn)移到音視頻融合通信服務(wù)端的另一個核心系統(tǒng)——云信自研的大規(guī)模分布式實時傳輸網(wǎng)?WE-CAN。

兩個邊緣媒體服務(wù)器在需要級聯(lián)的時候，會通過實時傳輸網(wǎng)的邊緣接入節(jié)點將流量導入實時傳輸網(wǎng)。實時傳輸網(wǎng)的邊緣節(jié)點根據(jù)實時傳輸網(wǎng)調(diào)度服務(wù)的統(tǒng)一調(diào)配，通過傳輸網(wǎng)的路由節(jié)點，將數(shù)據(jù)包以最優(yōu)路徑發(fā)送到目的邊緣媒體服務(wù)器。在這個過程中實時傳輸網(wǎng)路由探測和計算服務(wù)是鏈路路由選擇且保證最優(yōu)質(zhì)量的的控制大腦。云信自研的大規(guī)模分布式實時傳輸網(wǎng)有四大特點：

1、低延遲：邊緣接入節(jié)點全球覆蓋，所以可以做到用戶接入超低延遲，質(zhì)量可以媲美專線；

2、低成本：使用邊緣計算能力，而不是核心 BGP 機房，在降低成本的同時也保證了質(zhì)量；

3、高到達：實時傳輸網(wǎng)路由節(jié)點的路徑規(guī)劃非常智能，在全球范圍內(nèi)能做到多通道備份保證數(shù)據(jù)的高可達；

4、高可靠：實時傳輸網(wǎng)支持分級服務(wù)，同時多個鏈路通道可以自動快速切換，能夠在秒級做到故障隔離，保證鏈路的穩(wěn)定可靠。另外相比同類產(chǎn)品，云信自研的大規(guī)模分布式實時傳輸網(wǎng)，支持了大規(guī)模級聯(lián)場景下的應(yīng)用層組播技術(shù)，做到流量復用；同時還借鑒媒體服務(wù)器的分段 QoS 思路，支持分段重傳和 FEC ，保證了全鏈路的網(wǎng)絡(luò)傳輸質(zhì)量。

另外相比同類產(chǎn)品，云信自研的大規(guī)模分布式實時傳輸網(wǎng)，支持了大規(guī)模級聯(lián)場景下的應(yīng)用層組播技術(shù)，做到流量復用；同時還借鑒媒體服務(wù)器的分段 QoS 思路，支持分段重傳和 FEC，保證了全鏈路的網(wǎng)絡(luò)傳輸質(zhì)量。

娛樂社交場景技術(shù)實戰(zhàn)

?ClubHouse 萬人連麥?

今年年初，由“當代鋼鐵俠”埃隆馬斯克的親自引流，為 ClubHouse 這個在線多人語音聊天的平臺引入了大批用戶，ClubHouse 由此進入了一碼難求的階段，甚至 eBay 上一個邀請碼被炒到數(shù)百美元。拋開 ClubHouse 在產(chǎn)品運營維度的相關(guān)內(nèi)容，ClubHouse 本質(zhì)上就是一個全球的語聊房，從服務(wù)端的角度來剖析它的技術(shù)難點，我認為有以下三點：全球通話、超大并發(fā)以及上麥人數(shù)不限制。其中全球通話和超大并發(fā)的技術(shù)解決方案我們在第二部分都已經(jīng)涉及這里就不再贅述。這里我們重點展開聊聊上麥人數(shù)不限制。

首先，我們先分析一下上麥人數(shù)不限制有什么技術(shù)難點，我舉個相對極端的例子，一個5000人的頻道，5000人都需要開麥說話，那么這個頻道在系統(tǒng)里面就會有5000路上行，這時候如果服務(wù)端是一個純轉(zhuǎn)發(fā)的 SFU 服務(wù)器，就需要轉(zhuǎn)發(fā)近兩千五百萬路的音頻給所有的用戶，這個轉(zhuǎn)發(fā)的量是一個特別大的壓力；同時每個用戶的客戶端收到4999個下行語音流的時候，客戶端并不會把這些所有的聲音都進行混音播放，因為在一般理解上，一個混音里有超過3人的聲音的時候，就完全聽不清了，所以一般情況下客戶端會選擇音量最大的3~5路語音進行混音后再播放出來。可以看出來這么做的性價比是特別低的，浪費了大量的下行帶寬流量。因此合理的做法是在服務(wù)端上進行語音選路，為客戶端選出合適的語音后再轉(zhuǎn)發(fā)。

在單機里面做音頻選路其實是比較簡單的，只需要在上行的 RTP 包的擴展字段里面打上這個 RTP 包 PayLoad 部分的語音的音量信息，然后在服務(wù)器收到語音包以后經(jīng)過音頻選路器，將里面的音量最高的 N 路選擇出來，當然這里也涉及歷史數(shù)據(jù)和漸入漸出等相關(guān)音頻選路算法，但是總體而言難度不大。但在一個有大規(guī)模級聯(lián)的分布式環(huán)境下來實現(xiàn)選路就有一定的難度了，首先我們能想到的一個簡單的方案就是在整個系統(tǒng)中，同一個頻道的在一個統(tǒng)一的服務(wù)上做音頻選路，這種方案在人數(shù)不超過1000人場景下是適用的，但是當人數(shù)越多，這臺負責整個頻道選路的服務(wù)器就會成為系統(tǒng)的瓶頸點，而且這臺服務(wù)器的可用性會直接影響整個系統(tǒng)的可用性，它成為徹徹底底的短板。那云信是如何解決這個問題的？

是因為云信采用了分布式音頻選路方案！

我們來簡單的看一下這個方案，客戶端連到邊緣媒體服務(wù)器以后，這臺邊緣媒體服務(wù)器本機收到的音頻包進入本機的上行選路器進行音頻選擇，上行選路器選擇完成以后會將選路通過的語音包交由下行選路器，同時也會同步一份給級聯(lián)的服務(wù)器，這部分數(shù)據(jù)就會進入對端媒體服務(wù)器的下行選路器，總結(jié)來說就是每臺機器的上行選路器只選直連本機的用戶的音頻包，而下行選路器需要將本機上行選路器和遠端上行選路器的結(jié)果再次選路，最終選擇出發(fā)給客戶端的數(shù)據(jù)。通過這個方案，我們最終實現(xiàn)了超大并發(fā)下的分布式音頻選路方案，在這套架構(gòu)下整個選路系統(tǒng)不存在單點故障點，也就是任意一臺邊緣媒體服務(wù)器宕機不會影響音頻通話的正常進行，同時級聯(lián)的選路和下行選路也大大降低了服務(wù)器間的流量和下行客戶端的流量。當然這里還有一個點，就是選路到底應(yīng)該選音量最大的幾路的問題，以我們的經(jīng)驗，一般情況下3路就夠了，但是在某些特殊場景下，比如齊聲朗讀、大合唱的時候，選擇8路也足夠，因此云信將選路的路數(shù)是開放成接口讓客戶根據(jù)自己的場景來設(shè)置的。

?在線 KTV?

這兩年隨著音樂社交的不斷發(fā)展，在線 KTV 這個場景也越來越火。在線 KTV 主要是為了模擬真實 KTV 的場景，包括單人 K 歌和多人合唱。首先，我們來思考一個問題，在線 KTV 的場景和一般 RTC 場景有什么區(qū)別，其實本質(zhì)上是一樣的，但是有一個技術(shù)點在線 KTV 的要求是特別嚴格的，那就是延遲和同步。

單人 K 歌

對于主播來說，主播自己在演唱的時候，看著 MV 和歌詞、聽到的伴奏開始演唱，所以主播的體驗是肯定可以做得同步的，但是觀眾側(cè)要做到 MV、伴奏、延遲以及歌詞的完全同步就有一定的技術(shù)含量了，這里其實有兩種方案來實現(xiàn)。

• 主播發(fā)送音視頻

方案具體細節(jié)：主播側(cè)將含有歌詞的 MV 視頻和 MV 伴奏在本地播放，同時主播開始演唱，SDK 將 MV 和 MV 伴奏使用自定義入口輸入的 SDK 引擎，同時采集麥克風的主播演唱聲音，在 SDK 引擎內(nèi)部將 MV 的伴奏和主播聲音進行混音，并使用通用的音畫同步方案將MV和混合出來的聲音做同步后發(fā)送到聽眾接收端；此時聽眾接收端只需要把收到音頻和視頻按常規(guī)的播放渲染流程就能得到同步的效果了。

這個方案的明顯優(yōu)勢就是：簡單、并且能做的很好的同步；但是也存在明顯的劣勢：MV 視頻是通過 RTC 的視頻流進行傳輸?shù)?#xff0c;流量成本特別高，而且往往 MV 的視頻分辨率都比較高至少在720p，高分辨率的視頻也比較容易引起傳輸?shù)膿砣?#xff0c;最后造成觀眾側(cè)體驗卡頓。

• 主播發(fā)送純音頻

為了應(yīng)對第一種方案的問題，我們提出了第二種相對復雜的方案，如右圖。主播不需要將高清的 MV 視頻發(fā)送給對端，我們利用補充增強信息?SEI NAL，主播側(cè)將當前 MV 的播放時間戳填入到 SEI 中。

主播側(cè)的 SDK 會在引擎內(nèi)部做主播演唱的語音和 SEI 的對齊，接著 SDK 把 SEI 和主播的演唱發(fā)送到聽眾側(cè)，聽眾側(cè)根據(jù) SEI 里面時間戳信息控制 MV 的播放節(jié)奏，這樣就可以做到同步了，通過這個方案可以就大大減少了視頻的流量。當然這個方案在聽眾側(cè) MV 的播放控制方面也有一定的實現(xiàn)難度，需要深入到播放器的內(nèi)核。總結(jié)來說這兩個方案也各有優(yōu)劣吧，各位同學可以按需選擇。

多人合唱

其實多人 K 歌這幾年也有多套方案在演進，早期的方案存在主播無法聽到合唱者的聲音等眾多問題。隨著音視頻技術(shù)的不斷迭代進步，云信解決了多人合唱最核心的兩大問題，全球時間戳精準同步和端到端的延遲控制；端到端的延遲控制，不僅涉及端語音采集播放的低延時處理，還涉及了全球范圍內(nèi)全鏈路端到端的延遲要控制在?70ms?以內(nèi)。這里利用了?WE-CAN，分段 QoS?等多種手段。

而全球時間戳精準同步，云信自研了利用 WE-CAN 的分布式 NTP 對時系統(tǒng)，讓全球所有的邊緣媒體服務(wù)器的 NTP 時間都能做到1ms?內(nèi)的誤差，這樣所有的主播、合唱者和聽眾再和邊緣媒體服務(wù)器進行高精度時間戳同步，就能做到在全球范圍內(nèi)超高精度同步，目前云信的時間戳同步能做主播和合唱者 的1ms 誤差。有了這樣的技術(shù)解決方案，主播與合唱者就只需要在同步的開始在本地播放伴奏，然后演唱就可以做到很好的多人合唱體驗了。

?元宇宙——Metaverse?

?“元宇宙”一詞源自90年代的一本科幻小說，它指的是現(xiàn)實中的人可以在一個沉浸式的虛擬世界中，使用數(shù)字化的特定身份相互交流，獲得互動體驗。2021年被大家稱為元宇宙元年，我相信大家或多或少都聽說過，特別是在《頭號玩家》電影里面大家也都體驗過了那種在虛擬世界里面體驗人生的感覺。從 RTC 技術(shù)的挑戰(zhàn)的角度，我簡單提幾個點：

VR、AR 技術(shù)是元宇宙的核心基礎(chǔ)，這幾年 VR 與 RTC 的結(jié)合業(yè)界已經(jīng)有很多探索，核心要解決超高清視頻和超低延遲，對于超高清 8K 及以上分辨率的視頻非常依賴高性能視頻編解碼技術(shù)和底層硬件的支持；而超低延遲除了需要傳輸協(xié)議層面和 QoS 做相關(guān)優(yōu)化，也依賴 5G 乃至 6G 的底層通信技術(shù)；另外，為了讓大家在元宇宙的世界中有身臨其境的感覺 RTC 里面需要 3D 立體音，另外前面我們提到的大房間音頻選路，在元宇宙里面還需要在服務(wù)端上實現(xiàn)根據(jù)距離的音頻選路。

上面這幅圖是游戲公司 Beamable 的創(chuàng)始人近期發(fā)表解析的元宇宙文章里的配圖，他從結(jié)構(gòu)化方向上深度解析了元宇宙7層價值鏈，感興趣的同學可以進一步的去了解一下。

元宇宙價值鏈包括七個層面：體驗（Experience）；發(fā)現(xiàn)（Discovery）；創(chuàng)作者經(jīng)濟（Creator economy）；空間計算（Spatial Computing）；去中心化（Decentralizition）；人機交互（Human Interface）；基礎(chǔ)設(shè)施（Infrastructure）。

在線教育場景技術(shù)實戰(zhàn)

大家應(yīng)該都知道今年因為“雙減”政策對在線教育公司有不少影響，但是在線教育的場景這幾年是一直推著 RTC 技術(shù)不斷往前的迭代優(yōu)化的。在這一部分，我會與大家分享小班課、大班課還有超級小班課的技術(shù)實戰(zhàn)。

?在線教育小班課的優(yōu)質(zhì)體驗?

在線教育的小班課作為音視頻場景里面相對復雜的一個場景，其實需要面臨的挑戰(zhàn)很多，小班課中各個終端的觀看需求不同、網(wǎng)絡(luò)情況也各不相同。因此為了做好小班課的體驗，我們需要有一個完善的發(fā)布訂閱系統(tǒng)，同時配合好服務(wù)端的智能選擇，這依賴于服務(wù)器上的一套智能碼率分配以及碼流選擇算法；另一個核心功能是要實現(xiàn)服務(wù)器的分段 QoS，所謂分段 QoS 就是在服務(wù)器上需要分別針對用戶到服務(wù)器的上行鏈路和服務(wù)器到用戶的下行鏈路做好 QoS 保障，當然對于服務(wù)器來說核心是要做好下行的帶寬估計、擁塞控制和弱網(wǎng)對抗。

為了做好自動適配下行帶寬，首先針對每個上行用戶和下行用戶需要分別估算他們的上行和下行可用帶寬，這里涉及到分段帶寬估計以及帶寬估計算法的優(yōu)化，云信在融合了 GCC 和 BBR 算法優(yōu)勢的基礎(chǔ)上研發(fā)了自己的發(fā)送側(cè)帶寬估計算法，該算法帶寬估計準確度能做到95%。在估算到準確帶寬以后，為了適配下行帶寬，我們使用了各類策略包括：

1、最基礎(chǔ)的是基于大小流（simuclast）的選流策略，發(fā)送端發(fā)送不同分辨率的視頻流到服務(wù)器上，服務(wù)器根據(jù)下行帶寬情況，選擇相匹配的分辨率發(fā)送給各個下行客戶端；

2、云信實現(xiàn)了基于 SVC 時域分層的選流策略，再結(jié)合大小流，就能提供更精細的碼率分配策略；

3、除了碼率選擇，云信還在系統(tǒng)中提供了基于優(yōu)先級的帶寬分配策略，特別是會議和在線教育場景，主講者的優(yōu)先級明顯高于其他參會者，這時候就設(shè)置主講者為高優(yōu)先級，那么下行策略就會優(yōu)先把更多帶寬留給主講者，保證大家看到主講者的畫面是最優(yōu)的；

4、基于 TopN 的帶寬反饋策略，在默認情況下我們會盡量保證多數(shù)用戶都能看到高清的畫面，這個時候會適當壓制上行的碼率，以匹配 TopN 的客戶，N 是可配參數(shù)。

通過上訴手段我們就能保證在服務(wù)端上，為所有用戶決策出最佳匹配當前下行網(wǎng)絡(luò)狀態(tài)的碼流分配結(jié)果。

低延時大班課的平衡之道?

當前，大班課絕大多數(shù)都是通過傳統(tǒng)的直播解決方案實現(xiàn)的。傳統(tǒng)方案采用基于??TCP 協(xié)議的 CDN 直播，盡管經(jīng)過了多年發(fā)展和改進，但由于 TCP 協(xié)議本身的特性決定了它在實時流媒體領(lǐng)域的固有問題是很難攻克的，這就導致了延遲高、弱網(wǎng)抗性差等問題，直接影響了學生的用戶體驗。而 RTC 方案雖能解決上述問題，但其高昂的成本讓人“又愛又恨”，也讓眾多平臺望而卻步。所謂的平衡之道，其實就是要在效果（也就是清晰度、端到端延時、流暢度）與成本間去找到二者之間的平衡點。

為了實現(xiàn)低延時大班課的平衡之道， 我們實現(xiàn)了低延時直播。

在推流端支持第三個推流工具和云信推流 SDK，將流用?RTMP 或者云信的私有協(xié)議推到媒體邊緣加速服務(wù)器，對于開通了低延時功能的會通過 WE-CAN 大網(wǎng)進行高效分發(fā)，否則就通過融合 CDN 分發(fā)。WE-CAN 針對低延時直播的流做了全鏈路的延時優(yōu)化，相比于 CDN 直播?4s?以上的延遲，低延時直播可以將延時控制在0.6~1.2s。另外，低延時直播也復用了部分 RTC 的弱網(wǎng)對抗和首屏優(yōu)化技術(shù)，可以將首屏控制在500ms 以內(nèi)；我們實際測試，在30%的丟包的場景下基于傳統(tǒng) CDN 基本上已經(jīng)不可用了，而低延時直播還是非常流暢。通過各類技術(shù)保障，其實就是讓用戶用 CDN 的價格體驗到了 RTC 的效果。

?超級小班課場景落地?

在在線教育的領(lǐng)域，優(yōu)質(zhì)的老師資源一直是稀缺資源，因此很多教育場景使用了直播大班的方案來最大化利用優(yōu)質(zhì)教師的內(nèi)容，但是直播大班課相比與小班課也有一個弊端就是學生的互動體驗較差，為了解決這個問題云信提出了超級小班課方案。

它就是直播大班與互動小班的合體，即：一名主講老師面向數(shù)萬名學生進行直播授課，學生被分成若干個小班，在小班內(nèi)與老師、班內(nèi)其他同學進行互動，同時還可以安排多名助教分別進入多個小班，助教負責管理小班內(nèi)課堂秩序和輔助教學。通過該方案就完美了平衡了名師資源和學生互動的問題。

超級小班課的技術(shù)要點，我們分別需要實現(xiàn)聊天室的超級小班能力以及音視頻的超級小班能力。

對于?IM 聊天室，核心技術(shù)是 IM 聊天室標簽功能——靈活地支持聊天室消息定向收發(fā)、聊天室權(quán)限定向管理、聊天室成員定向查詢等個性化功能，分組互動。而對于音視頻，核心技術(shù)有兩個：

1、跨房間連麥，這個在今天分享第二部分提到，云信的媒體服務(wù)器是以流的作為管理單元而不是以房間作為管理單元，那么實現(xiàn)跨房間連麥時，就非常方便；

2、加入多房間，客戶端需要支持同時加入多房間，這樣學生就可以同時加入老師的大班課和互動小班兩個房間；

云信通過這些 IM 和音視頻的底層能力，完美的解決了超級小班課的痛點，也為多個在線教育平臺提供了超級小班的能力。

RTC 數(shù)據(jù)驅(qū)動

大家都知道現(xiàn)在是一個大數(shù)據(jù)時代，我認為做好大數(shù)據(jù)驅(qū)動對于音視頻技術(shù)持續(xù)演進來說極其重要。

為了做好大數(shù)據(jù)驅(qū)動，我們從?SDK、引擎、調(diào)度服務(wù)器、頻道與流管理服務(wù)器、邊緣媒體服務(wù)器、實時傳輸網(wǎng)，也就是音視頻業(yè)務(wù)的每一個環(huán)節(jié)都做了數(shù)據(jù)采集上報。我們上報了100+的關(guān)鍵事件，這些事件包括了用戶行為，各系統(tǒng)行為，QoS 行為，還有很多的音視頻 QoE 體驗相關(guān)的關(guān)鍵事件，比如：分辨率切換、登錄耗時、出圖時間等等；還上報了300+的核心指標，這些指標包括：全鏈路的系統(tǒng)運行時狀態(tài)，QoS 指標，QoE 指標以及服務(wù)端狀態(tài)。這些上報的數(shù)據(jù)都會經(jīng)由我們大數(shù)據(jù)平臺進行處理，日均有百億行的數(shù)據(jù)，有 T 級的存儲。利用我們的高性能大數(shù)據(jù)平臺，我們可以秒級的實時處理這些數(shù)據(jù)。有了這些數(shù)據(jù)以后，我們可以驅(qū)動很多事情，包括質(zhì)量透明平臺（對用戶開放）、業(yè)務(wù)質(zhì)量報表、產(chǎn)出接入調(diào)度優(yōu)化、大網(wǎng)路由優(yōu)化、QoS 算法優(yōu)化、QoE 故障實時告警、各維度聚合質(zhì)量分析。云信新一代音視頻，就是在源源不斷的大數(shù)據(jù)驅(qū)動下，不斷打磨，提升自身的質(zhì)量。

展望

最后來對 RTC 技術(shù)做個簡單的展望，同時也是我個人比較關(guān)注的幾的技術(shù)方向，我認為：低成本 RTC 會成為業(yè)界一個標配，低成本體現(xiàn)在兩個方面：接入低成本和費用低成本， RTC 的接入會像現(xiàn)在 CDN 接入這么簡單，而價格也會匹配目前 CDN 的價格，RTC-CDN 應(yīng)該會在未來幾年內(nèi)到來；而未來的音視頻編解碼還是會斷的迭代創(chuàng)新：比如視頻編碼器 AV1 和基于 AI 的音頻編器 SoundStream，未來肯定還會涌現(xiàn)出更多優(yōu)秀的音視頻編解碼器；對于 Web 技術(shù)：我個人比較關(guān)注?Webtransport 和 WebCodec，我相信 Webtransport 會大大優(yōu)化 Web 端的傳輸方式，而 WebRTC 的 Next Version 會開放更多 low level 的底層接口，也會讓 WebRTC 的使用更加靈活，值得大家保持持續(xù)關(guān)注；AI 與大數(shù)據(jù)挖掘技術(shù)，肯定會不斷在 RTC 領(lǐng)域中發(fā)揮重要作用。

我堅信技術(shù)的進步是永無止境的，同時技術(shù)也是可以改變世界的，音視頻領(lǐng)域未來還有無限可能的！

?作者簡介?

吳桐，網(wǎng)易云信流媒體首席架構(gòu)師，網(wǎng)易多媒體開發(fā)專家。2013年從浙江大學碩士畢業(yè)后加入網(wǎng)易，現(xiàn)任網(wǎng)易云信云平臺技術(shù)負責人、在線教育行業(yè)線負責人，全面負責實時音視頻、互動白板、低延時直播、互動直播、WE-CAN 全球傳輸網(wǎng)等項目的架構(gòu)設(shè)計與研發(fā)，對音視頻、高性能服務(wù)器以及網(wǎng)絡(luò)傳輸?shù)阮I(lǐng)域均有多年的工作與項目經(jīng)驗。

總結(jié)

以上是生活随笔為你收集整理的RTC 融合通信服务架构与场景应用 | 2021稀土开发者大会音视频专场的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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