音視頻傳輸協(xié)議眾多， 5G時(shí)代不同業(yè)務(wù)應(yīng)該如何選擇？
共 2688字，需瀏覽 6分鐘
·
2022-02-09 17:34
摘要：音視頻傳輸協(xié)議眾多， 不同業(yè)務(wù)應(yīng)該如何選擇？ RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此我們就從業(yè)務(wù)發(fā)展的視角來理解各種流媒體協(xié)議，幫助大家有更加清晰的理解，選擇時(shí)做出更理性的判斷。
IPTV
IPTV 是由運(yùn)營商主導(dǎo)建設(shè)的一套系統(tǒng)，他的主要對標(biāo)對象是傳統(tǒng)廣電的數(shù)字電視。所以這套系統(tǒng)首要解決的是大規(guī)模直播的問題，在此基礎(chǔ)上還需要支持點(diǎn)播、時(shí)移、回看等新業(yè)務(wù)。運(yùn)營商的優(yōu)勢就是可以自建一套可管理的網(wǎng)絡(luò)，所以直播就基于組播技術(shù)進(jìn)行大規(guī)模分發(fā)。主要技術(shù)棧是RTP+TS over multicast，這個(gè)技術(shù)大大降低了直播峰值對流媒體服務(wù)器的壓力。而點(diǎn)播、時(shí)移、回看業(yè)務(wù)由于必須使用單播傳輸，所以當(dāng)時(shí)選擇的技術(shù)棧是使用RTSP 進(jìn)行流媒體控制，使用RTP+TS over UDP（少量基于TCP）進(jìn)行數(shù)據(jù)傳輸。
現(xiàn)在這套系統(tǒng)服務(wù)了全國接近1.7 億多用戶。這套技術(shù)棧面臨的挑戰(zhàn)和對應(yīng)的解決方案主要包括幾點(diǎn)：
解決單播基于UDP 傳輸丟包的問題，丟包會(huì)導(dǎo)致用戶觀看花屏或爆音，我們基于RTSP 協(xié)議擴(kuò)展制定了一套規(guī)范，基于RTSP 的GET_PARAMETER擴(kuò)展了重傳數(shù)據(jù)報(bào)文的信令，主要是基于NACK 原理進(jìn)行設(shè)計(jì)，通知流媒體服務(wù)器哪個(gè)報(bào)文沒有接收到，流媒體服務(wù)器根據(jù)請求中攜帶的RTP 序號進(jìn)行重發(fā)。
解決組播傳輸丟包問題，組播報(bào)文丟包會(huì)導(dǎo)致直播花屏或爆音，我們采用了2 個(gè)手段解決這個(gè)問題：
· FEC
· ARQ
通過FEC 技術(shù)增加等步長的冗余報(bào)文，可以解決隨機(jī)丟包問題，但是無法解決突發(fā)連續(xù)丟包問題，這個(gè)時(shí)候就需要ARQ 技術(shù)，我們在系統(tǒng)中增加一個(gè)RETServer，RET Server 也會(huì)加入組播組接收和機(jī)頂盒收到的相同的組播報(bào)文，機(jī)頂盒在檢測到丟包后，會(huì)向這臺(tái)服務(wù)器發(fā)起NACK 報(bào)文，RET Server 收到請求后根據(jù)請求的RTP 需要將對應(yīng)的報(bào)文發(fā)送給機(jī)頂盒。
解決組播傳輸下頻道快速啟動(dòng)問題，終端加入組播組的時(shí)間是隨機(jī)的，無法保證每次加入組播組后接收到的報(bào)文就可以理解用于解碼并顯示，所以我們通過在系統(tǒng)中增加一個(gè)FCC Server，解決該問題，終端在起播觀看一個(gè)頻道的時(shí)候，優(yōu)先向FCC Server 請求一條單播流，F(xiàn)CC Server 會(huì)以1.X 倍的速率將I 幀和解碼所需的報(bào)文發(fā)給終端，配合終端快顯技術(shù)可以實(shí)現(xiàn)300ms 以內(nèi)的頻道切換速度。
IPTV多屏
隨著移動(dòng)終端的發(fā)展，運(yùn)營商希望在IPTV 業(yè)務(wù)基礎(chǔ)上，發(fā)展手機(jī)等多屏業(yè)務(wù)，開始支持HLS（主流）、MPEG DASH（部分海外運(yùn)營商，支持MultiDRM）流媒體協(xié)議。這套系統(tǒng)在流媒體協(xié)議層面臨的問題是不同屏幕，不同DRM 格式，多種格式帶來了存儲(chǔ)空間成倍的上升，特別是NPVR 個(gè)人錄制業(yè)務(wù)，對存儲(chǔ)的需求非常大。主要解決思路就是JITP（Just In Time Package），即只要存儲(chǔ)一份內(nèi)容，根據(jù)用戶觀看的內(nèi)容格式進(jìn)行實(shí)時(shí)格式轉(zhuǎn)換。
OTT點(diǎn)播
伴隨著以Youtube，Netflix，愛奇藝，優(yōu)酷，騰訊視頻為代表的OTT 視頻點(diǎn)播平臺(tái)的崛起，以及蘋果手機(jī)的普及和HLS 協(xié)議的出現(xiàn)，流媒體協(xié)議從HTTP漸進(jìn)式下載發(fā)展到ABR Streaming，HLS 是其中最為主流的一種ABR 協(xié)議，HLS 也成為了各個(gè)OTT視頻平臺(tái)的首選視頻傳輸協(xié)議。這套系統(tǒng)在流媒體協(xié)議層面臨的問題和解決方案如下：
- 解決基于互聯(lián)網(wǎng)的大規(guī)模分發(fā)問題。CDN 技術(shù)可以很好的解決這個(gè)問題，這也是OTT 流媒體協(xié)議基本上在設(shè)計(jì)之初就考慮對CDN 友好的原因。
- Netflix 由于業(yè)務(wù)量的規(guī)模發(fā)展到一定規(guī)模，從最開始選擇第三方CDN，走向了自建CDN（Open Connect）的道路，但是他的技術(shù)棧依舊是HLS 和DASH 這類對CDN 友好的流媒體協(xié)議。
OTT 直播
細(xì)分為事件類（新聞/ 賽事/ 演唱會(huì)）直播、個(gè)人（游戲/ 網(wǎng)紅/ 秀場）直播。滿足這類直播業(yè)務(wù)的流媒體協(xié)議層面臨的問題和解決方案如下：
1、首先他們和OTT 點(diǎn)播一樣，需要解決基于互聯(lián)網(wǎng)的視頻大規(guī)模分發(fā)問題。
2、其次直播相較于點(diǎn)播需要額外考慮的一點(diǎn)就是直播時(shí)延，第一類：電視臺(tái)/ 事件（新聞/ 賽事/ 演唱會(huì)）直播基本沒有和觀眾互動(dòng)的要求。所以它們依然選擇對CDN 友好的HLS 和DASH 協(xié)議，但是時(shí)延會(huì)高達(dá)10-30s，隨著CMAF 格式的出現(xiàn)，根據(jù)我們在實(shí)驗(yàn)室的測試數(shù)據(jù)表示時(shí)延可以小于5s。第二類：個(gè)人（游戲/ 網(wǎng)紅/ 秀場）直播，以國內(nèi)直播平臺(tái)為例，商業(yè)模式主要靠打賞分層，所以要求直播的E2E 時(shí)延必須低于5s，否則觀眾與主播的互動(dòng)效果非常差，直接影響直播平臺(tái)的收入。這類廠家選擇的技術(shù)棧為延遲更低的RTMP 和HTTP FLV。
3、隨著手機(jī)和4G 網(wǎng)絡(luò)的普及，部分主播也開始嘗試在戶外進(jìn)行開播，由于戶外直播的網(wǎng)絡(luò)條件不可控，而RTMP 是基于TCP 傳輸?shù)模瑢?dǎo)致在戶外4G網(wǎng)絡(luò)條件不穩(wěn)定的環(huán)境下，直播效果很差，所以針對弱網(wǎng)環(huán)境下的直播上行效果差成為直播平臺(tái)需要解決問題。為了解決這個(gè)問題，大家把眼光轉(zhuǎn)向UDP，基于UDP 的直播傳輸技術(shù)逐步進(jìn)入人們的視野。常見的有ZIXI、SRT 和RIST。ZIXI 屬于純商業(yè)化公司，顯然不合適大量個(gè)人直播上傳這類商業(yè)模式的直播平臺(tái)。SRT 有相對成熟的開源社區(qū)支持，所以在國內(nèi)應(yīng)用較為普遍。RIST 是由Video Services Forum (VSF)于2017 年初開始制定的可靠的互聯(lián)網(wǎng)流傳輸協(xié)議（Reliable Internet Stream Transport，RIST），相較于SRT，基于UDT 非實(shí)時(shí)流媒體的技術(shù)棧構(gòu)建，RIST 一開始便使用較為成熟的RTP+RTCP 技術(shù)，而且他只定義了標(biāo)準(zhǔn)化的語法，允許實(shí)廠家在此基礎(chǔ)上進(jìn)行創(chuàng)新，而又不影響互相操作。經(jīng)過近幾年的發(fā)展RIST 支持的場景越來越多，也越來越成熟。
4、直播業(yè)務(wù)發(fā)展越來越繁榮后，又出現(xiàn)了多主播PK，主播與觀眾連麥等場景，這些對時(shí)延的要求直接從5s 變成1s 以內(nèi)， 甚至小于400ms， 為了滿足業(yè)務(wù)的發(fā)展，直播平臺(tái)選擇了實(shí)時(shí)通信的技術(shù)棧RTP+RTCP over UDP。一旦引入U(xiǎn)DP，就需要解決丟包帶來的視頻體驗(yàn)問題，這里常見的技術(shù)有FEC、ARQ 等。
實(shí)時(shí)音視頻 RTC
隨著5G 網(wǎng)絡(luò)的普及，以及疫情帶來的影響，人們對實(shí)時(shí)音視頻技術(shù)的應(yīng)用場景會(huì)越來越多，主要包括：會(huì)議、連麥、音視通話、視頻通話、在線教育、遠(yuǎn)程醫(yī)療等。由于這些應(yīng)用場景對時(shí)延的要求<400ms，所以從技術(shù)棧選擇來看，基本上都是選擇RTP/RTCP over UDP 的方式進(jìn)行音視頻數(shù)據(jù)的輸出。
如果把流媒體協(xié)議做三個(gè)維度劃分：質(zhì)量（畫質(zhì)/幀率）、平滑、延遲。實(shí)時(shí)音視頻通信和OTT 直播上傳場景相比，對低質(zhì)量的容忍度更高，即允許降低一定的質(zhì)量，下降（降幀率等）來換取更加平滑的體驗(yàn)和更低的延遲。這個(gè)選擇上的差異，導(dǎo)致在技術(shù)設(shè)計(jì)上需要打通網(wǎng)絡(luò)傳輸系統(tǒng)和音視頻編解碼系統(tǒng)，實(shí)現(xiàn)根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量實(shí)時(shí)動(dòng)態(tài)調(diào)整音視頻編碼參數(shù)，在質(zhì)量、時(shí)延、平滑三個(gè)維度上進(jìn)行權(quán)衡得出最優(yōu)解。
流媒體新的發(fā)展方向
1、 新的媒體表現(xiàn)形式包括VR、自由視角、點(diǎn)云；他們與傳統(tǒng)視頻的最大區(qū)別在于，傳統(tǒng)視頻主要支持時(shí)間維度的定位，而新的媒體，除了支持時(shí)間維度的定位，還支持空間維度的定位。當(dāng)前主要在MPEG 標(biāo)準(zhǔn)組織中進(jìn)行討論，基于MPEG DASH 規(guī)范進(jìn)行演進(jìn)。以VR 為例，一般人類的FOV 視場角<140°，新的流媒體協(xié)議利用這個(gè)特性，可以實(shí)現(xiàn)根據(jù)觀眾觀看的視頻范圍，進(jìn)行部分傳輸，從而降低的對帶寬的訴求，這也很好的解決了傳輸?shù)臄?shù)據(jù)量越來越大對帶寬要求苛刻的問題。華為云視頻的Cloud VR 產(chǎn)品已經(jīng)支持8K VR、自由視角的直播和點(diǎn)播服務(wù)。
2、 全互聯(lián)實(shí)時(shí)音視頻直播，隨著在線教育和在線辦公的普及，越來越多客戶對具備大規(guī)模分發(fā)能力的低時(shí)延互動(dòng)視頻服務(wù)有著強(qiáng)烈的訴求，當(dāng)前的架構(gòu)要么支持大規(guī)模分發(fā)，要么支持低時(shí)延、互動(dòng)，無法同時(shí)具備三者的能力。我們認(rèn)為未來的主流架構(gòu)需要同時(shí)滿足這三樣能力，華為的實(shí)時(shí)音視頻服務(wù)已經(jīng)完成這套架構(gòu)的實(shí)現(xiàn)，致力于在流媒體領(lǐng)域持續(xù)深耕，讓我們共建流媒體的未來。