超低延迟直播架构解析
本文由百度智能云-視頻云直播技術(shù)架構(gòu)師——朱曉恩 在百度開發(fā)者沙龍線上分享的演講內(nèi)容整理而成。內(nèi)容從低延時直播背景與機遇出發(fā),分析低延遲直播技術(shù),重點分享百度在低延遲直播技術(shù)的實踐工作。
文/ 朱曉恩
整理/ 百度開發(fā)者中心
視頻回放:https://developer.baidu.com/live.html?id=10
本次分享的主題是:超低延遲直播架構(gòu)解析,內(nèi)容主要分為以下三個方面:
01 低延遲直播背景與機遇
隨著各行各業(yè)直播的普及,加上疫情的強勢推廣。在線教育、直播帶貨、企業(yè)培訓(xùn)、線上招聘等實時互動的場景迅速升溫。直播已成為企業(yè)數(shù)字化轉(zhuǎn)型和內(nèi)容營銷的必備場景。
在直播中,用戶實時互動體驗一直是商家重點關(guān)心的問題。例如直播帶貨過程中,主播已經(jīng)上完優(yōu)惠券,10幾秒過去了,用戶卻還在等待優(yōu)惠券。超低延遲直播可以大大提升邊看邊買的體驗,主播可以結(jié)合互動區(qū)更好實現(xiàn)控場和互動,并且讓秒殺、抽獎、拍賣等對時效要求高的營銷玩法有了更強的底層支撐,大大優(yōu)化直播轉(zhuǎn)換率。
又比如活動賽事直播場景中,電視/文字直播用戶已在吶喊,而視頻直播畫面還未進球。超低延遲可以極大的加深觀眾對于現(xiàn)場實時互動的沉浸感,參與比分和現(xiàn)場的互動,提升用戶對于線下活動的參與感。
而隨著5G時代的到來,網(wǎng)絡(luò)條件正快速提升:邊緣帶寬實現(xiàn)Mb向Gb增長,5G網(wǎng)絡(luò)時延下降到1~10毫秒;依托于AR、VR技術(shù)的直播更是大大提升了用戶的沉浸式體驗。
這些對低延遲直播來技術(shù),都是重大的機遇。
02 超低延遲直播架構(gòu)解析
RTMP/FLV直播延遲原因分析
接下來,我們以一個簡單的直播架構(gòu)為例,分析傳統(tǒng)的 RTMP/FLV 直播產(chǎn)生延遲的原因。
架構(gòu)介紹:
主播通過 RTMP 推流到流媒體服務(wù)器,再從直播流媒體服務(wù)器通過 RTMP/HLS/FLV 等技術(shù)向觀眾分發(fā)包。
而一個視頻直播傳輸過程如下:
視頻輸入攝像頭采集數(shù)據(jù)——CDN傳輸——視頻解碼
「設(shè)備端處理延遲」、「網(wǎng)絡(luò)層延遲」和「服務(wù)器內(nèi)部處理延遲」。
緩存策略主要指CND的GOP緩存,但這種緩存策略會增加延遲。碼率過高或 GOP 太短會造成 TCP 累積延遲。
編解碼過程中,解碼端在顯示之前的視頻幀緩存和編碼端的緩存都會造成延遲。
解碼端在顯示之前的視頻幀緩存和編碼端的緩存都會造成延遲。
編碼環(huán)節(jié)中的 B 幀解碼也依賴于前后視頻幀的到達。
由于以上原因,傳統(tǒng)的基于 RTMP/FLV 的視頻直播一般會產(chǎn)生 3-5 秒左右的延遲。延遲高的關(guān)鍵在于CDN的傳輸和播放解碼沒有很好地配合和互動。所以要實現(xiàn)低延遲,主要解決這個關(guān)鍵問題。
低延遲直播方案簡單比較——基于UDP
基于 TCP 的視頻直播存在較長的延遲。為此,人們開發(fā)出了 SRT、QUIC、WebRTC 等一系列基于 UDP 協(xié)議的低延遲直播方案。
下表可以簡單概述一下基于UDP的各項低延遲直播方案的特點:
介于WebRTC生態(tài)繁榮,百度選擇了WebRTC做為低延遲,在下一章節(jié)會基于百度智能云音視頻直播服務(wù)LSS,詳細介紹低延遲的直播方案實現(xiàn)。
03 LSS低延遲直播技術(shù)實踐
LSS低延遲直播方案設(shè)計目標(biāo)與過程
設(shè)計目標(biāo):
實現(xiàn)過程:
如上圖所示,在典型的 LSS 直播推拉流的流程中
- 主播首先在主播端通過 LSS 推流 SDK 實現(xiàn) RTMP 推流 ,在該過程中將實現(xiàn)實時美顏、實時濾鏡、視覺特效、硬件加速等功能;
- 視頻流會被推到全球智能接流網(wǎng)絡(luò)中,進而接入 LSS 媒體中心,通過服務(wù)器端 SDK實現(xiàn)實時轉(zhuǎn)碼、自動鑒黃、多碼率輸出、實時水印、實時截圖、內(nèi)容加密、錄制點播、統(tǒng)計分析等功能,打通與點播、存儲、RTC等其它云服務(wù)產(chǎn)品的聯(lián)系。
- 接著,通過全球智能分發(fā)網(wǎng)絡(luò),基于 RTMP/FLV/HLS/WebRTC 等方案將視頻流分發(fā)到客戶端,通過LSS 播放器 SDK 實現(xiàn) LSS 播放,在該過程中,將實現(xiàn)首屏秒開、追幀播放、自適應(yīng)碼率、解密播放等功能。
直播場景改造
WebRTC 本身是面向多人會議的實時通信方案,為了使其更好地適用于直播場景,我們需要對其進行一系列的改造,從而支持大規(guī)模的低延遲直播分發(fā)。
- 就組件協(xié)議而言,采用 AAC、H.264 音視頻引擎、UDP 傳輸層協(xié)議、RTP 媒體協(xié)議、RTCP 數(shù)據(jù)協(xié)議。通過 STUN/ICE實現(xiàn)建聯(lián),并且通過 HTTP 請求實現(xiàn) SDP 協(xié)商。
- 就QoS 方案而言,通過 NACK 的方式實現(xiàn)丟包重傳。在播放側(cè)進行基于 Jitter Buffer 的緩沖,在發(fā)送側(cè)基于 PACING機制調(diào)整發(fā)送的頻率和碼率,通過 GCC 實現(xiàn)擁塞控制,進而估計并反饋帶寬。
- 就具體的改造點而言,仍然使用上行 RTMP 協(xié)議,支持非加密傳輸,音頻轉(zhuǎn)碼支持 Opus,視頻支持 B 幀,實現(xiàn)了 FLVtimestamp 透傳和 Metadata 透傳。
直播CDN支持與質(zhì)量
WebRTC 低延遲方案需要考慮對直播 CDN 的支持與質(zhì)量。
首先,采用與 RTMP/FLV 等協(xié)議相同的多級直播 CDN 分發(fā)拓撲,實現(xiàn)回源與推流。
這套方案通過了大規(guī)模并發(fā)的考驗,更加穩(wěn)定成熟。在CDN 邊緣節(jié)點上進行封裝協(xié)議的轉(zhuǎn)換,例如:WebRTC/FLV 協(xié)議可以復(fù)用節(jié)點回源數(shù)據(jù),如果某條直播流上已經(jīng)存在 WebRTC/FLV 的播放回源數(shù)據(jù),就可以實現(xiàn)更快的響應(yīng)。
此外,百度 WebRTC 低延遲方案依托于百度 CDN 的海量資源節(jié)點以及優(yōu)質(zhì)骨干傳輸網(wǎng)絡(luò),建立了覆蓋全國的實時節(jié)點質(zhì)量撥測系統(tǒng)與智能流量調(diào)度系統(tǒng),實現(xiàn)了更完善的直播流質(zhì)量監(jiān)控系統(tǒng),可以實時監(jiān)控直播流回源過程中的卡頓等指標(biāo)。
請求過程
WebRTC 低延遲方案的請求過程主要分為「媒體協(xié)商」、「網(wǎng)絡(luò)協(xié)商」、「媒體傳輸&信令傳輸」三個階段,我們進行的主要改造包括:
- 在媒體協(xié)商階段中,在客戶端通過 HTTP API 訪問節(jié)點,從而攜帶播放的 URL、SDPOffer。在服務(wù)端,獲得直播流對應(yīng)的媒體描述,如果直播流已經(jīng)存在于節(jié)點上,可以直接獲得媒體描述,否則將會通過回源拉流來獲取媒體描述。此外,會生成并記錄會話token,通過 HTTP 協(xié)議相應(yīng)返回,通過 ice-ufrag 字段對應(yīng)會話的 token。
- 在網(wǎng)絡(luò)協(xié)商階段中,通過 STUN 在客戶端發(fā)起 Binding Request,并在 USERNAME 字段中攜帶會話token。這樣一來,我們在服務(wù)器端就可以通過 USERNAME 映射到 ice-ufrag 字段,從而對應(yīng)到拉流的進程,返回Binding Response。
- 在媒體傳輸 & 信令傳輸階段中,實現(xiàn) RTP 和 RTCP 的復(fù)用傳輸。
總結(jié):
綜上所述,LSS實現(xiàn)了基于 WebRTC 的低延遲端到端解決方案,該方案依托于成熟穩(wěn)定的百度 CDN 直播分發(fā)架構(gòu),支持百萬并發(fā)和多協(xié)議并發(fā),能夠兼容直播媒體中心的產(chǎn)品矩陣,接入的成本較低,打通了與 BRTC、BOS 等百度智能云產(chǎn)品的聯(lián)系,支持更多的使用場景。
歡迎大家在百度智能云官網(wǎng)體驗:https://cloud.baidu.com/product/lss.html
以上是老師的全部分享內(nèi)容,有問題歡迎在評論區(qū)提出。
點擊進入獲得更多技術(shù)信息~~
掃描二維碼,備注:音視頻開發(fā),立即加入音視頻開發(fā)技術(shù)交流群。
總結(jié)
以上是生活随笔為你收集整理的超低延迟直播架构解析的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 接连三次霸榜GitHub,这个国产Git
- 下一篇: BFE Ingress Controll