本文整理自華為云視頻云架構(gòu)師武杰線上分享的演講，他詳細介紹華為云從直播到實時音視頻的網(wǎng)絡架構(gòu)演進、低時延傳輸技術，分享華為云實時音視頻的應用場景實踐。實時音視頻業(yè)務將逐步成為云基礎設施，使能千行百業(yè)。面對直播，實時音視頻爆發(fā)式增長，華為云如何使用一套系統(tǒng)解決直播，實時音視頻業(yè)務融合以及低時延傳輸?shù)认嚓P問題？

大家好，我叫武杰，是華為云視頻云架構(gòu)師。從2006年開始參加工作，曾在通信行業(yè)負責IMS核心網(wǎng)業(yè)務系統(tǒng)產(chǎn)品研發(fā)。曾主管直播CDN、彈性轉(zhuǎn)碼系統(tǒng)架構(gòu)、研發(fā)和運維。2019年加入華為，曾負責華為云直播服務，實時音視頻服務產(chǎn)品規(guī)劃和架構(gòu)，現(xiàn)負責華為云視頻云服務整體技術架構(gòu)和可靠性設計工作。有著10年以上大規(guī)模分布式系統(tǒng)研發(fā)、運維和架構(gòu)經(jīng)驗，在CDN網(wǎng)絡架構(gòu)，音視頻傳輸，擁塞控制，通信協(xié)議等領域與有著多年經(jīng)驗積累。 本次我分享主題是華為云RTC服務架構(gòu)及應用實踐。 1 對音視頻技術發(fā)展的回顧和展望 1.1 視頻業(yè)務走向?qū)崟r互動，RTC成為視頻基礎能力

從3G、4G一直到5G，隨著網(wǎng)絡的發(fā)展，網(wǎng)絡技術不斷躍遷，這也帶來了更快的傳輸速率、更低的延遲和更低的成本。從最原始的IM到點播+評論，再到直播+彈幕。我們預測未來隨著5G的發(fā)展，網(wǎng)絡會帶來更低的時延，如云渲染、虛擬空間碼率的業(yè)務以及AI、IoT業(yè)務會隨著網(wǎng)絡技術的演進逐步成熟。 1.2 實時音視頻RTC應用場景將繼續(xù)深化

從4G到5G技術的迭代，我們看到整個RTC從普通的娛樂視頻、教育視頻，到結(jié)合行業(yè)逐步適配更廣泛的應用，例如智慧辦公、應急指揮、遠程醫(yī)療等。未來隨著萬物互聯(lián)的時代到來，實時音視頻業(yè)務會繼續(xù)深入，連接物與物、人與物，成為實時交互的連接網(wǎng)絡，如智能家庭終端、智能汽車、智能手表等音視頻交互、操控?，F(xiàn)在音視頻還處于井噴的起始階段，未來人與物、物與物的協(xié)作還將繼續(xù)爆發(fā)，并且和生活密切相關。 2 傳 統(tǒng) 直 播 2.1 傳統(tǒng)直播架構(gòu)——時延和卡頓二選一

上圖的系統(tǒng)架構(gòu)是直播系統(tǒng)比較通用的架構(gòu)，一般分為3層架構(gòu)，分別是單線的CDN邊緣、多線的CDN中心和承載一些增值服務的源站。從這個架構(gòu)中可以看出以下問題：

上、下行流均需要通過兩層網(wǎng)絡到直播源站，并在直播源站關聯(lián)匯聚，成本較高；

屬于靜態(tài)路由規(guī)劃，無法保證端到端最優(yōu)路徑，質(zhì)量優(yōu)化空間有限；

全鏈路TCP，特別是第一公里和最后一公里不確定網(wǎng)絡條件，一旦產(chǎn)生丟包，質(zhì)量迅速下降。

所以在整個直播過程中，CDN會給3-5s左右的時延，讓終端有buffer抗抖動。這里的痛點是時延和卡頓，這是需要進行二選一的過程，如果要追求較低的卡頓率，時延就需要加大?，F(xiàn)在的一些超低時延直播引入了WebRTC技術或者用SRT、QUIC解決第一公里或最后一公里的問題，這樣做能帶來一些好處，但它的時延最多只能做到1s左右。 2.2 割裂的網(wǎng)絡

隨著直播業(yè)務不斷地發(fā)展，直播的交互性從2016年主播和觀眾通過文字或彈幕交互，逐步演進成實時連麥的交互，整個RTC最初比較火的業(yè)務也是連麥——主播在上播過程中可以申請權限與主播連麥，分享至很多人。對于一些直播平臺，它們需要對接兩套系統(tǒng)——實時音視頻系統(tǒng)與直播系統(tǒng)。當主播開始連麥時，從直播系統(tǒng)切至實時音視頻系統(tǒng)，主播與觀眾間有幾百毫秒的時延，對于普通觀眾在合流塊引入1到2s的延時，直播塊引入3-5s的延時，整個時延變得非常大。而當觀眾退麥時，他會在直播中看到幾秒前的自己，對于這種傳統(tǒng)直播的實現(xiàn)方式是割裂的網(wǎng)絡。 3 華為云RTC

3.1 RTC原生架構(gòu)

華為RTC云的理念是打造統(tǒng)一資源架構(gòu)和技術架構(gòu)以支持當前直播+RTC場景，華為云希望將多個網(wǎng)絡變成統(tǒng)一網(wǎng)絡、多個系統(tǒng)變成統(tǒng)一系統(tǒng)、SDK盡量做到統(tǒng)一去解決交互和直播的融合場景，實現(xiàn)會議、直播、連麥以及后續(xù)其他繼續(xù)深入的場景支撐。 3.2 華為云RTC整體架構(gòu) 華為云RTC基于華為云構(gòu)建，在整個環(huán)境中分為5層架構(gòu)：

最上層是Global區(qū)，承載了數(shù)據(jù)、內(nèi)容管理、調(diào)度等相關的能力；

Region區(qū)，部署在廣州、北京、上海，配置的是RTC的增值能力，例如截圖、審核、轉(zhuǎn)碼、RTR等；

中心與邊緣位于華為云整個CDN節(jié)點上，有相應與RTC配套的服務，包括轉(zhuǎn)碼、實時渲染等；

最下層為用戶層。我將在下文針對以上內(nèi)容做詳細說明。

3.3 實時音視頻分發(fā)網(wǎng)絡

從結(jié)構(gòu)來看，華為云RTC不再是樹狀架構(gòu)，通過調(diào)度和內(nèi)部路徑選優(yōu)的方式盡量找到主播和普通觀眾之間的最短路徑，可能會將觀眾與主播調(diào)至同一節(jié)點、或進行節(jié)點與節(jié)點之間的互通、又或者節(jié)點間通過中轉(zhuǎn)接點互通，從而確保端到端路徑最短、時延最優(yōu)。這中間一旦出現(xiàn)問題，可以進行相應的中轉(zhuǎn)節(jié)點或鏈路的調(diào)換。與此同時，部分增值業(yè)務節(jié)點可下沉到接入節(jié)點，支持超低時延（100ms） 轉(zhuǎn)碼，租戶可按需合流。

3.4 實時音視頻傳輸協(xié)議棧

華為實時音視頻傳輸協(xié)議棧，以UDP和TCP網(wǎng)絡以及華為自研的ADN——四層RPN的網(wǎng)絡為傳輸層的基礎，打造實時傳輸協(xié)議棧，在協(xié)議棧中支持HWRTC協(xié)議、WebRTC，用以上協(xié)議支持上層RTC業(yè)務、超低時延直播業(yè)務、標準直播業(yè)務，未來將整合GB28181擴展性攝像頭相關的業(yè)務。

3.5 計算資源的邊緣下層——邊緣媒體+AI計算架構(gòu)

邊緣媒體+AI計算架構(gòu)依托于華為云邊緣節(jié)點，通過IEF對整個邊緣節(jié)點找了邊緣函數(shù)框架，在上方構(gòu)建實施媒體+AI的能力。也就是說這里不僅具備編解碼能力，還可以集成第三方EI的算法鏡像。這種方法可以將端側(cè)的美顏替換能力下放到云的邊緣。

3.6 華為云RTC技術 智能編解碼+網(wǎng)絡自適應雙輪驅(qū)動

在整個RTC過程中，從采集端到播放端的過程，第一步通過設備采集音視頻，在編解碼層采用智能編碼技術，如SVC可伸縮分層編碼，它包括時域和空域的編解碼，時域是直播播放端降幀的能力，空域能把主播的流變成大小流，被叫端根據(jù)網(wǎng)絡狀況選擇播高碼率或是低碼率的流，如此當被叫端網(wǎng)絡不好時可以通過降碼的方式達到播放流暢的效果。后續(xù)是通過實時超分和ROI優(yōu)化對編解碼方面做更低碼率的壓縮，得到更好的傳輸和低時延的效果。 第二步是智能調(diào)速，主要涉及網(wǎng)絡層和編解碼層的互動，通過網(wǎng)絡層的網(wǎng)絡探測和帶寬預分析判斷端側(cè)的帶寬，也就是傳輸?shù)拇a率最大可以支持多少帶寬。通過此種方式控制編碼的碼率，使得主播端能夠有更好的流暢度。

最后一步是私有抗網(wǎng)損算法，采用FEC前向糾錯算法、自動重傳HARQ——華為自研的算法、接收端的AJB自適應抗抖動Buffer做一些網(wǎng)絡重傳的抗抖。以上算法相互配合，在保證直播流暢的情況下達到最低時延的效果。以上就是華為云RTC的智能編解碼和網(wǎng)絡自適應雙輪驅(qū)動的內(nèi)容。 語言增強技術+丟包補償 華為云在語音方面的技術，主要分為語言增強技術和語音丟包補償技術兩大部分。 語音增強技術包括語音降噪、回聲消除。降噪主要采取AI降噪與傳統(tǒng)降噪結(jié)合的方式?，F(xiàn)如今存在很多不同的場景需要降噪的適配，例如主播場景要求背景音清晰、教育場景需要降背景音，還有一些敲鍵盤或相應聲音去除等不同場景適配?；匾粝竼蜗蛲ㄔ挄r因為回音消除不完全產(chǎn)生回聲，另外在交互過程中，不會產(chǎn)生雙講或丟字。我們通過Mos值評分確定語音效果。 語音丟包補償技術應用于當前網(wǎng)絡產(chǎn)生丟包的情況，如上圖所示，產(chǎn)生丟包時，中間信號是空的，如果完全依賴于重傳，時延不能達到很好的效果，這部分會采用一些傳統(tǒng)與AI結(jié)合的方式將丟的包補齊，從而達到語音流暢的效果。上圖是在不同丟包率下做到的音頻Mos值，音頻的核心競爭力是高音質(zhì)——比較主流的是48k赫茲Mos值達到4.0以上、低延時——延時要達到小于300ms、回音消除——不漏回聲，雙講不去字。以上就是語音增強方面相關技術介紹。

4 實時音視頻RTC體驗優(yōu)化

4.1 監(jiān)控QoE/QoS全局實時監(jiān)控 在成千上萬的流量中，如何保證系統(tǒng)能夠及時發(fā)現(xiàn)問題呢？我們通過服務端和客戶端的埋點采集，對整個全網(wǎng)的節(jié)點進行監(jiān)控——包括全網(wǎng)維度、APP維度、Room維度、節(jié)點維度等。根據(jù)不同的監(jiān)控數(shù)據(jù)，通過數(shù)據(jù)聚合的方式發(fā)現(xiàn)網(wǎng)絡層面、客戶端層面出現(xiàn)的問題，通過以上這些數(shù)據(jù)，運維可以及時發(fā)現(xiàn)鏈路中的問題并著手解決。

4.2 一鍵式用戶個例通話QoS行為調(diào)查能力 當接到客戶說某個用戶有卡頓時，判斷的方法是一鍵式用戶個例通話QoS行為調(diào)查能力。首先通過房間維度的監(jiān)控進到用戶維度監(jiān)控，再通過用戶數(shù)據(jù)的幀率、碼率、時延、抖動、丟包率判斷網(wǎng)絡狀況，如發(fā)現(xiàn)與設備終端有關聯(lián)，比如用戶終端CPU跑高或內(nèi)存跑高，是由于用戶其他應用開啟造成的問題，需要定位具體原因；如果是用戶操作行為導致的問題，例如做了關麥的操作卻反饋“沒有聲音”，可以通過用戶操作行為事件判斷用戶在使用過程中產(chǎn)生的相應問題。

4.3 實時音視頻體驗自動診斷 對于單用戶的分析我們還做了相應的自我診斷功能。根據(jù)關鍵指標的監(jiān)控，通過監(jiān)控模型分析是否有聚集性的問題，比如CPU高或某一區(qū)域、節(jié)點有問題，在得到這些異常事件后，用它來分析用戶端可能會發(fā)生的一些問題，比如進房滿、視頻音頻卡頓等。另外可以反饋至運維，判斷聚集性問題和網(wǎng)絡端出現(xiàn)的問題，通過切換節(jié)點、鏈路等方式解決網(wǎng)絡側(cè)問題。以上是整個運維監(jiān)控系統(tǒng)的內(nèi)容。

5 實時音視頻主打場景

5.1 企業(yè)會議：直播互動視頻會議，涵蓋內(nèi)外溝通場景，適應業(yè)務發(fā)展需求 RTC技術和華為云會議系統(tǒng)進行對接，最終目標是打造千人會議，可以讓會場支持千人級互動與萬人級觀眾參與，讓觀眾和發(fā)言者可以進行自由切換，同時支持云端低于100ms超低時延合流，降低純觀眾播放的帶寬和成本。

5.2 在線教育：學生隨時舉手上臺，支持子母課，萬人大課堂 在教育模塊我們經(jīng)過深入研究，發(fā)現(xiàn)傳統(tǒng)的在線教育是老師在上面講課，許多學生聽老師講課，學生可以通過舉手的方式上臺與老師互動，但很多情況是老師會將學生分組，組內(nèi)可以進行交流互動，再將互動結(jié)果分享。在教育方面我們做了更多的適配場景，可以讓多個終端加入同個會場、同個子母課的方式去支持教育行業(yè)應用。通過上述方式，觀看端學生與老師之間的互動時延均低于300ms，學生切換流暢，并不像傳統(tǒng)連麥中學生互動結(jié)束后可以聽到幾秒前與老師的互動。

5.3 電商直播：面對面的溝通體驗，提升轉(zhuǎn)換率 傳統(tǒng)的電商直播受限于原有網(wǎng)絡問題，觀眾只能通過彈幕的方式和主播進行交流，導致轉(zhuǎn)化率比較低，而傳統(tǒng)的連麥架構(gòu)會導致從互動切換到直播的過程，時延變大，會看到幾秒前的自己，用戶體驗度很差，此外買家與賣家互動是單向的，只能通過文字溝通。通過實時音視頻的引入，保證了互動端和觀眾端時延在300ms以內(nèi)，整個過程中，觀眾可以隨時切麥和主播進行互動，做到全場景低時延，從而提高電商直播場景中轉(zhuǎn)化率。

原文標題：華為云RTC服務架構(gòu)及應用實踐

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關注！文章轉(zhuǎn)載請注明出處。

責任編輯：haq