本文整理自華為云視頻云架構(gòu)師武杰線上分享的演講,他詳細介紹華為云從直播到實時音視頻的網(wǎng)絡(luò)架構(gòu)演進、低時延傳輸技術(shù),分享華為云實時音視頻的應(yīng)用場景實踐。實時音視頻業(yè)務(wù)將逐步成為云基礎(chǔ)設(shè)施,使能千行百業(yè)。面對直播,實時音視頻爆發(fā)式增長,華為云如何使用一套系統(tǒng)解決直播,實時音視頻業(yè)務(wù)融合以及低時延傳輸?shù)认嚓P(guān)問題?
文/武杰
整理/LiveVideoStack
大家好,我叫武杰,是華為云視頻云架構(gòu)師。從2006年開始參加工作,曾在通信行業(yè)負責(zé)IMS核心網(wǎng)業(yè)務(wù)系統(tǒng)產(chǎn)品研發(fā)。曾主管直播CDN、彈性轉(zhuǎn)碼系統(tǒng)架構(gòu)、研發(fā)和運維。2019年加入華為,曾負責(zé)華為云直播服務(wù),實時音視頻服務(wù)產(chǎn)品規(guī)劃和架構(gòu),現(xiàn)負責(zé)華為云視頻云服務(wù)整體技術(shù)架構(gòu)和可靠性設(shè)計工作。有著10年以上大規(guī)模分布式系統(tǒng)研發(fā)、運維和架構(gòu)經(jīng)驗,在CDN網(wǎng)絡(luò)架構(gòu),音視頻傳輸,擁塞控制,通信協(xié)議等領(lǐng)域與有著多年經(jīng)驗積累。
本次我分享主題是華為云RTC服務(wù)架構(gòu)及應(yīng)用實踐。
1 對音視頻技術(shù)發(fā)展的回顧和展望
1.1視頻業(yè)務(wù)走向?qū)崟r互動,RTC成為視頻基礎(chǔ)能力
從3G、4G一直到5G,隨著網(wǎng)絡(luò)的發(fā)展,網(wǎng)絡(luò)技術(shù)不斷躍遷,這也帶來了更快的傳輸速率、更低的延遲和更低的成本。從最原始的IM到點播+評論,再到直播+彈幕。我們預(yù)測未來隨著5G的發(fā)展,網(wǎng)絡(luò)會帶來更低的時延,如云渲染、虛擬空間碼率的業(yè)務(wù)以及AI、IoT業(yè)務(wù)會隨著網(wǎng)絡(luò)技術(shù)的演進逐步成熟。
1.2實時音視頻RTC應(yīng)用場景將繼續(xù)深化
從4G到5G技術(shù)的迭代,我們看到整個RTC從普通的娛樂視頻、教育視頻,到結(jié)合行業(yè)逐步適配更廣泛的應(yīng)用,例如智慧辦公、應(yīng)急指揮、遠程醫(yī)療等。未來隨著萬物互聯(lián)的時代到來,實時音視頻業(yè)務(wù)會繼續(xù)深入,連接物與物、人與物,成為實時交互的連接網(wǎng)絡(luò),如智能家庭終端、智能汽車、智能手表等音視頻交互、操控。現(xiàn)在音視頻還處于井噴的起始階段,未來人與物、物與物的協(xié)作還將繼續(xù)爆發(fā),并且和生活密切相關(guān)。
2 傳統(tǒng)直播
2.1傳統(tǒng)直播架構(gòu)——時延和卡頓二選一
上圖的系統(tǒng)架構(gòu)是直播系統(tǒng)比較通用的架構(gòu),一般分為3層架構(gòu),分別是單線的CDN邊緣、多線的CDN中心和承載一些增值服務(wù)的源站。從這個架構(gòu)中可以看出以下問題:
上、下行流均需要通過兩層網(wǎng)絡(luò)到直播源站,并在直播源站關(guān)聯(lián)匯聚,成本較高;
屬于靜態(tài)路由規(guī)劃,無法保證端到端最優(yōu)路徑,質(zhì)量優(yōu)化空間有限;
全鏈路TCP,特別是第一公里和最后一公里不確定網(wǎng)絡(luò)條件,一旦產(chǎn)生丟包,質(zhì)量迅速下降。
所以在整個直播過程中,CDN會給3-5s左右的時延,讓終端有buffer抗抖動。這里的痛點是時延和卡頓,這是需要進行二選一的過程,如果要追求較低的卡頓率,時延就需要加大?,F(xiàn)在的一些超低時延直播引入了WebRTC技術(shù)或者用SRT、QUIC解決第一公里或最后一公里的問題,這樣做能帶來一些好處,但它的時延最多只能做到1s左右。
2.2割裂的網(wǎng)絡(luò)
隨著直播業(yè)務(wù)不斷地發(fā)展,直播的交互性從2016年主播和觀眾通過文字或彈幕交互,逐步演進成實時連麥的交互,整個RTC最初比較火的業(yè)務(wù)也是連麥——主播在上播過程中可以申請權(quán)限與主播連麥,分享至很多人。對于一些直播平臺,它們需要對接兩套系統(tǒng)——實時音視頻系統(tǒng)與直播系統(tǒng)。當主播開始連麥時,從直播系統(tǒng)切至實時音視頻系統(tǒng),主播與觀眾間有幾百毫秒的時延,對于普通觀眾在合流塊引入1到2s的延時,直播塊引入3-5s的延時,整個時延變得非常大。而當觀眾退麥時,他會在直播中看到幾秒前的自己,對于這種傳統(tǒng)直播的實現(xiàn)方式是割裂的網(wǎng)絡(luò)。
3 華為云RTC
3.1 RTC原生架構(gòu)
華為RTC云的理念是打造統(tǒng)一資源架構(gòu)和技術(shù)架構(gòu)以支持當前直播+RTC場景,華為云希望將多個網(wǎng)絡(luò)變成統(tǒng)一網(wǎng)絡(luò)、多個系統(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)度等相關(guān)的能力;
Region區(qū),部署在廣州、北京、上海,配置的是RTC的增值能力,例如截圖、審核、轉(zhuǎn)碼、RTR等;
中心與邊緣位于華為云整個CDN節(jié)點上,有相應(yīng)與RTC配套的服務(wù),包括轉(zhuǎn)碼、實時渲染等;
最下層為用戶層。我將在下文針對以上內(nèi)容做詳細說明。
3.3實時音視頻分發(fā)網(wǎng)絡(luò)
從結(jié)構(gòu)來看,華為云RTC不再是樹狀架構(gòu),通過調(diào)度和內(nèi)部路徑選優(yōu)的方式盡量找到主播和普通觀眾之間的最短路徑,可能會將觀眾與主播調(diào)至同一節(jié)點、或進行節(jié)點與節(jié)點之間的互通、又或者節(jié)點間通過中轉(zhuǎn)接點互通,從而確保端到端路徑最短、時延最優(yōu)。這中間一旦出現(xiàn)問題,可以進行相應(yīng)的中轉(zhuǎn)節(jié)點或鏈路的調(diào)換。與此同時,部分增值業(yè)務(wù)節(jié)點可下沉到接入節(jié)點,支持超低時延(100ms)轉(zhuǎn)碼,租戶可按需合流。
3.4實時音視頻傳輸協(xié)議棧
華為實時音視頻傳輸協(xié)議棧,以UDP和TCP網(wǎng)絡(luò)以及華為自研的ADN——四層RPN的網(wǎng)絡(luò)為傳輸層的基礎(chǔ),打造實時傳輸協(xié)議棧,在協(xié)議棧中支持HWRTC協(xié)議、WebRTC,用以上協(xié)議支持上層RTC業(yè)務(wù)、超低時延直播業(yè)務(wù)、標準直播業(yè)務(wù),未來將整合GB28181擴展性攝像頭相關(guān)的業(yè)務(wù)。
3.5計算資源的邊緣下層——邊緣媒體+AI計算架構(gòu)
邊緣媒體+AI計算架構(gòu)依托于華為云邊緣節(jié)點,通過IEF對整個邊緣節(jié)點找了邊緣函數(shù)框架,在上方構(gòu)建實施媒體+AI的能力。也就是說這里不僅具備編解碼能力,還可以集成第三方EI的算法鏡像。這種方法可以將端側(cè)的美顏替換能力下放到云的邊緣。
3.6華為云RTC技術(shù)
智能編解碼+網(wǎng)絡(luò)自適應(yīng)雙輪驅(qū)動
在整個RTC過程中,從采集端到播放端的過程,第一步通過設(shè)備采集音視頻,在編解碼層采用智能編碼技術(shù),如SVC可伸縮分層編碼,它包括時域和空域的編解碼,時域是直播播放端降幀的能力,空域能把主播的流變成大小流,被叫端根據(jù)網(wǎng)絡(luò)狀況選擇播高碼率或是低碼率的流,如此當被叫端網(wǎng)絡(luò)不好時可以通過降碼的方式達到播放流暢的效果。后續(xù)是通過實時超分和ROI優(yōu)化對編解碼方面做更低碼率的壓縮,得到更好的傳輸和低時延的效果。
第二步是智能調(diào)速,主要涉及網(wǎng)絡(luò)層和編解碼層的互動,通過網(wǎng)絡(luò)層的網(wǎng)絡(luò)探測和帶寬預(yù)分析判斷端側(cè)的帶寬,也就是傳輸?shù)拇a率最大可以支持多少帶寬。通過此種方式控制編碼的碼率,使得主播端能夠有更好的流暢度。
最后一步是私有抗網(wǎng)損算法,采用FEC前向糾錯算法、自動重傳HARQ——華為自研的算法、接收端的AJB自適應(yīng)抗抖動Buffer做一些網(wǎng)絡(luò)重傳的抗抖。以上算法相互配合,在保證直播流暢的情況下達到最低時延的效果。以上就是華為云RTC的智能編解碼和網(wǎng)絡(luò)自適應(yīng)雙輪驅(qū)動的內(nèi)容。
語言增強技術(shù)+丟包補償
華為云在語音方面的技術(shù),主要分為語言增強技術(shù)和語音丟包補償技術(shù)兩大部分。
語音增強技術(shù)包括語音降噪、回聲消除。降噪主要采取AI降噪與傳統(tǒng)降噪結(jié)合的方式?,F(xiàn)如今存在很多不同的場景需要降噪的適配,例如主播場景要求背景音清晰、教育場景需要降背景音,還有一些敲鍵盤或相應(yīng)聲音去除等不同場景適配?;匾粝竼蜗蛲ㄔ挄r因為回音消除不完全產(chǎn)生回聲,另外在交互過程中,不會產(chǎn)生雙講或丟字。我們通過Mos值評分確定語音效果。
語音丟包補償技術(shù)應(yīng)用于當前網(wǎng)絡(luò)產(chǎn)生丟包的情況,如上圖所示,產(chǎn)生丟包時,中間信號是空的,如果完全依賴于重傳,時延不能達到很好的效果,這部分會采用一些傳統(tǒng)與AI結(jié)合的方式將丟的包補齊,從而達到語音流暢的效果。上圖是在不同丟包率下做到的音頻Mos值,音頻的核心競爭力是高音質(zhì)——比較主流的是48k赫茲Mos值達到4.0以上、低延時——延時要達到小于300ms、回音消除——不漏回聲,雙講不去字。以上就是語音增強方面相關(guān)技術(shù)介紹。
4 實時音視頻RTC體驗優(yōu)化
4.1監(jiān)控QoE/QoS全局實時監(jiān)控
在成千上萬的流量中,如何保證系統(tǒng)能夠及時發(fā)現(xiàn)問題呢?我們通過服務(wù)端和客戶端的埋點采集,對整個全網(wǎng)的節(jié)點進行監(jiān)控——包括全網(wǎng)維度、APP維度、Room維度、節(jié)點維度等。根據(jù)不同的監(jiān)控數(shù)據(jù),通過數(shù)據(jù)聚合的方式發(fā)現(xiàn)網(wǎng)絡(luò)層面、客戶端層面出現(xiàn)的問題,通過以上這些數(shù)據(jù),運維可以及時發(fā)現(xiàn)鏈路中的問題并著手解決。
4.2一鍵式用戶個例通話QoS行為調(diào)查能力
當接到客戶說某個用戶有卡頓時,判斷的方法是一鍵式用戶個例通話QoS行為調(diào)查能力。首先通過房間維度的監(jiān)控進到用戶維度監(jiān)控,再通過用戶數(shù)據(jù)的幀率、碼率、時延、抖動、丟包率判斷網(wǎng)絡(luò)狀況,如發(fā)現(xiàn)與設(shè)備終端有關(guān)聯(lián),比如用戶終端CPU跑高或內(nèi)存跑高,是由于用戶其他應(yīng)用開啟造成的問題,需要定位具體原因;如果是用戶操作行為導(dǎo)致的問題,例如做了關(guān)麥的操作卻反饋“沒有聲音”,可以通過用戶操作行為事件判斷用戶在使用過程中產(chǎn)生的相應(yīng)問題。
4.3實時音視頻體驗自動診斷
對于單用戶的分析我們還做了相應(yīng)的自我診斷功能。根據(jù)關(guān)鍵指標的監(jiān)控,通過監(jiān)控模型分析是否有聚集性的問題,比如CPU高或某一區(qū)域、節(jié)點有問題,在得到這些異常事件后,用它來分析用戶端可能會發(fā)生的一些問題,比如進房滿、視頻音頻卡頓等。另外可以反饋至運維,判斷聚集性問題和網(wǎng)絡(luò)端出現(xiàn)的問題,通過切換節(jié)點、鏈路等方式解決網(wǎng)絡(luò)側(cè)問題。以上是整個運維監(jiān)控系統(tǒng)的內(nèi)容。
5 實時音視頻主打場景
5.1企業(yè)會議:
直播互動視頻會議,涵蓋內(nèi)外溝通場景,適應(yīng)業(yè)務(wù)發(fā)展需求
RTC技術(shù)和華為云會議系統(tǒng)進行對接,最終目標是打造千人會議,可以讓會場支持千人級互動與萬人級觀眾參與,讓觀眾和發(fā)言者可以進行自由切換,同時支持云端低于100ms超低時延合流,降低純觀眾播放的帶寬和成本。
5.2在線教育:
學(xué)生隨時舉手上臺,支持子母課,萬人大課堂
在教育模塊我們經(jīng)過深入研究,發(fā)現(xiàn)傳統(tǒng)的在線教育是老師在上面講課,許多學(xué)生聽老師講課,學(xué)生可以通過舉手的方式上臺與老師互動,但很多情況是老師會將學(xué)生分組,組內(nèi)可以進行交流互動,再將互動結(jié)果分享。在教育方面我們做了更多的適配場景,可以讓多個終端加入同個會場、同個子母課的方式去支持教育行業(yè)應(yīng)用。通過上述方式,觀看端學(xué)生與老師之間的互動時延均低于300ms,學(xué)生切換流暢,并不像傳統(tǒng)連麥中學(xué)生互動結(jié)束后可以聽到幾秒前與老師的互動。
5.3電商直播:
面對面的溝通體驗,提升轉(zhuǎn)換率
傳統(tǒng)的電商直播受限于原有網(wǎng)絡(luò)問題,觀眾只能通過彈幕的方式和主播進行交流,導(dǎo)致轉(zhuǎn)化率比較低,而傳統(tǒng)的連麥架構(gòu)會導(dǎo)致從互動切換到直播的過程,時延變大,會看到幾秒前的自己,用戶體驗度很差,此外買家與賣家互動是單向的,只能通過文字溝通。通過實時音視頻的引入,保證了互動端和觀眾端時延在300ms以內(nèi),整個過程中,觀眾可以隨時切麥和主播進行互動,做到全場景低時延,從而提高電商直播場景中轉(zhuǎn)化率。