音視頻傳輸協(xié)議眾多， 不同業(yè)務(wù)應(yīng)該如何選擇？ RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此我們就從業(yè)務(wù)發(fā)展的視角來(lái)理解各種流媒體協(xié)議，幫助大家有更加清晰的理解，選擇時(shí)做出更理性的判斷。

IPTV

IPTV 是由運(yùn)營(yíng)商主導(dǎo)建設(shè)的一套系統(tǒng)，他的主要對(duì)標(biāo)對(duì)象是傳統(tǒng)廣電的數(shù)字電視。所以這套系統(tǒng)首要解決的是大規(guī)模直播的問(wèn)題，在此基礎(chǔ)上還需要支持點(diǎn)播、時(shí)移、回看等新業(yè)務(wù)。運(yùn)營(yíng)商的優(yōu)勢(shì)就是可以自建一套可管理的網(wǎng)絡(luò)，所以直播就基于組播技術(shù)進(jìn)行大規(guī)模分發(fā)。主要技術(shù)棧是RTP+TS over multicast，這個(gè)技術(shù)大大降低了直播峰值對(duì)流媒體服務(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ù)了全國(guó)接近1.7 億多用戶。這套技術(shù)棧面臨的挑戰(zhàn)和對(duì)應(yīng)的解決方案主要包括幾點(diǎn)：
解決單播基于UDP 傳輸丟包的問(wèn)題，丟包會(huì)導(dǎo)致用戶觀看花屏或爆音，我們基于RTSP 協(xié)議擴(kuò)展制定了一套規(guī)范，基于RTSP 的GET_PARAMETER擴(kuò)展了重傳數(shù)據(jù)報(bào)文的信令，主要是基于NACK 原理進(jìn)行設(shè)計(jì)，通知流媒體服務(wù)器哪個(gè)報(bào)文沒(méi)有接收到，流媒體服務(wù)器根據(jù)請(qǐng)求中攜帶的RTP 序號(hào)進(jìn)行重發(fā)。

解決組播傳輸丟包問(wèn)題，組播報(bào)文丟包會(huì)導(dǎo)致直播花屏或爆音，我們采用了2 個(gè)手段解決這個(gè)問(wèn)題：
· FEC
· ARQ

通過(guò)FEC 技術(shù)增加等步長(zhǎng)的冗余報(bào)文，可以解決隨機(jī)丟包問(wèn)題，但是無(wú)法解決突發(fā)連續(xù)丟包問(wèn)題，這個(gè)時(shí)候就需要ARQ 技術(shù)，我們?cè)谙到y(tǒng)中增加一個(gè)RETServer，RET Server 也會(huì)加入組播組接收和機(jī)頂盒收到的相同的組播報(bào)文，機(jī)頂盒在檢測(cè)到丟包后，會(huì)向這臺(tái)服務(wù)器發(fā)起NACK 報(bào)文，RET Server 收到請(qǐng)求后根據(jù)請(qǐng)求的RTP 需要將對(duì)應(yīng)的報(bào)文發(fā)送給機(jī)頂盒。

解決組播傳輸下頻道快速啟動(dòng)問(wèn)題，終端加入組播組的時(shí)間是隨機(jī)的，無(wú)法保證每次加入組播組后接收到的報(bào)文就可以理解用于解碼并顯示，所以我們通過(guò)在系統(tǒng)中增加一個(gè)FCC Server，解決該問(wèn)題，終端在起播觀看一個(gè)頻道的時(shí)候，優(yōu)先向FCC Server 請(qǐng)求一條單播流，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)營(yíng)商希望在IPTV 業(yè)務(wù)基礎(chǔ)上，發(fā)展手機(jī)等多屏業(yè)務(wù)，開(kāi)始支持HLS（主流）、MPEG DASH（部分海外運(yùn)營(yíng)商，支持MultiDRM）流媒體協(xié)議。這套系統(tǒng)在流媒體協(xié)議層面臨的問(wèn)題是不同屏幕，不同DRM 格式，多種格式帶來(lái)了存儲(chǔ)空間成倍的上升，特別是NPVR 個(gè)人錄制業(yè)務(wù)，對(duì)存儲(chǔ)的需求非常大。主要解決思路就是JITP（Just In Time Package），即只要存儲(chǔ)一份內(nèi)容，根據(jù)用戶觀看的內(nèi)容格式進(jìn)行實(shí)時(shí)格式轉(zhuǎn)換。

OTT點(diǎn)播

伴隨著以Youtube，Netflix，愛(ài)奇藝，優(yōu)酷，騰訊視頻為代表的OTT 視頻點(diǎn)播平臺(tái)的崛起，以及蘋(píng)果手機(jī)的普及和HLS 協(xié)議的出現(xiàn)，流媒體協(xié)議從HTTP漸進(jìn)式下載發(fā)展到ABR Streaming，HLS 是其中最為主流的一種ABR 協(xié)議，HLS 也成為了各個(gè)OTT視頻平臺(tái)的首選視頻傳輸協(xié)議。這套系統(tǒng)在流媒體協(xié)議層面臨的問(wèn)題和解決方案如下：
1、 解決基于互聯(lián)網(wǎng)的大規(guī)模分發(fā)問(wèn)題。CDN 技術(shù)可以很好的解決這個(gè)問(wèn)題，這也是OTT 流媒體協(xié)議基本上在設(shè)計(jì)之初就考慮對(duì)CDN 友好的原因。
2、 Netflix 由于業(yè)務(wù)量的規(guī)模發(fā)展到一定規(guī)模，從最開(kāi)始選擇第三方CDN，走向了自建CDN（Open Connect）的道路，但是他的技術(shù)棧依舊是HLS 和DASH 這類對(duì)CDN 友好的流媒體協(xié)議。

OTT 直播

細(xì)分為事件類（新聞/ 賽事/ 演唱會(huì)）直播、個(gè)人（游戲/ 網(wǎng)紅/ 秀場(chǎng)）直播。滿足這類直播業(yè)務(wù)的流媒體協(xié)議層面臨的問(wèn)題和解決方案如下：

1、首先他們和OTT 點(diǎn)播一樣，需要解決基于互聯(lián)網(wǎng)的視頻大規(guī)模分發(fā)問(wèn)題。

2、其次直播相較于點(diǎn)播需要額外考慮的一點(diǎn)就是直播時(shí)延，第一類：電視臺(tái)/ 事件（新聞/ 賽事/ 演唱會(huì)）直播基本沒(méi)有和觀眾互動(dòng)的要求。所以它們依然選擇對(duì)CDN 友好的HLS 和DASH 協(xié)議，但是時(shí)延會(huì)高達(dá)10-30s，隨著CMAF 格式的出現(xiàn)，根據(jù)我們?cè)趯?shí)驗(yàn)室的測(cè)試數(shù)據(jù)表示時(shí)延可以小于5s。第二類：個(gè)人（游戲/ 網(wǎng)紅/ 秀場(chǎng)）直播，以國(guó)內(nèi)直播平臺(tái)為例，商業(yè)模式主要靠打賞分層，所以要求直播的E2E 時(shí)延必須低于5s，否則觀眾與主播的互動(dòng)效果非常差，直接影響直播平臺(tái)的收入。這類廠家選擇的技術(shù)棧為延遲更低的RTMP 和HTTP FLV。

3、隨著手機(jī)和4G 網(wǎng)絡(luò)的普及，部分主播也開(kāi)始嘗試在戶外進(jìn)行開(kāi)播，由于戶外直播的網(wǎng)絡(luò)條件不可控，而RTMP 是基于TCP 傳輸?shù)模瑢?dǎo)致在戶外4G網(wǎng)絡(luò)條件不穩(wěn)定的環(huán)境下，直播效果很差，所以針對(duì)弱網(wǎng)環(huán)境下的直播上行效果差成為直播平臺(tái)需要解決問(wèn)題。為了解決這個(gè)問(wèn)題，大家把眼光轉(zhuǎn)向UDP，基于UDP 的直播傳輸技術(shù)逐步進(jìn)入人們的視野。常見(jiàn)的有ZIXI、SRT 和RIST。ZIXI 屬于純商業(yè)化公司，顯然不合適大量個(gè)人直播上傳這類商業(yè)模式的直播平臺(tái)。SRT 有相對(duì)成熟的開(kāi)源社區(qū)支持，所以在國(guó)內(nèi)應(yīng)用較為普遍。RIST 是由Video Services Forum (VSF)于2017 年初開(kāi)始制定的可靠的互聯(lián)網(wǎng)流傳輸協(xié)議（Reliable Internet Stream Transport，RIST），相較于SRT，基于UDT 非實(shí)時(shí)流媒體的技術(shù)棧構(gòu)建，RIST 一開(kāi)始便使用較為成熟的RTP+RTCP 技術(shù)，而且他只定義了標(biāo)準(zhǔn)化的語(yǔ)法，允許實(shí)廠家在此基礎(chǔ)上進(jìn)行創(chuàng)新，而又不影響互相操作。經(jīng)過(guò)近幾年的發(fā)展RIST 支持的場(chǎng)景越來(lái)越多，也越來(lái)越成熟。

4、直播業(yè)務(wù)發(fā)展越來(lái)越繁榮后，又出現(xiàn)了多主播PK，主播與觀眾連麥等場(chǎng)景，這些對(duì)時(shí)延的要求直接從5s 變成1s 以內(nèi)， 甚至小于400ms， 為了滿足業(yè)務(wù)的發(fā)展，直播平臺(tái)選擇了實(shí)時(shí)通信的技術(shù)棧RTP+RTCP over UDP。一旦引入U(xiǎn)DP，就需要解決丟包帶來(lái)的視頻體驗(yàn)問(wèn)題，這里常見(jiàn)的技術(shù)有FEC、ARQ 等。

實(shí)時(shí)音視頻 RTC

隨著5G 網(wǎng)絡(luò)的普及，以及疫情帶來(lái)的影響，人們對(duì)實(shí)時(shí)音視頻技術(shù)的應(yīng)用場(chǎng)景會(huì)越來(lái)越多，主要包括：會(huì)議、連麥、音視通話、視頻通話、在線教育、遠(yuǎn)程醫(yī)療等。由于這些應(yīng)用場(chǎng)景對(duì)時(shí)延的要求<400ms，所以從技術(shù)棧選擇來(lái)看，基本上都是選擇RTP/RTCP over UDP 的方式進(jìn)行音視頻數(shù)據(jù)的輸出。

如果把流媒體協(xié)議做三個(gè)維度劃分：質(zhì)量（畫(huà)質(zhì)/幀率）、平滑、延遲。實(shí)時(shí)音視頻通信和OTT 直播上傳場(chǎng)景相比，對(duì)低質(zhì)量的容忍度更高，即允許降低一定的質(zhì)量，下降（降幀率等）來(lái)?yè)Q取更加平滑的體驗(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 視場(chǎng)角<140°，新的流媒體協(xié)議利用這個(gè)特性，可以實(shí)現(xiàn)根據(jù)觀眾觀看的視頻范圍，進(jìn)行部分傳輸，從而降低的對(duì)帶寬的訴求，這也很好的解決了傳輸?shù)臄?shù)據(jù)量越來(lái)越大對(duì)帶寬要求苛刻的問(wèn)題。華為云視頻的Cloud VR 產(chǎn)品已經(jīng)支持8K VR、自由視角的直播和點(diǎn)播服務(wù)。

2、 全互聯(lián)實(shí)時(shí)音視頻直播，隨著在線教育和在線辦公的普及，越來(lái)越多客戶對(duì)具備大規(guī)模分發(fā)能力的低時(shí)延互動(dòng)視頻服務(wù)有著強(qiáng)烈的訴求，當(dāng)前的架構(gòu)要么支持大規(guī)模分發(fā)，要么支持低時(shí)延、互動(dòng)，無(wú)法同時(shí)具備三者的能力。我們認(rèn)為未來(lái)的主流架構(gòu)需要同時(shí)滿足這三樣能力，華為的實(shí)時(shí)音視頻服務(wù)已經(jīng)完成這套架構(gòu)的實(shí)現(xiàn)，致力于在流媒體領(lǐng)域持續(xù)深耕，讓我們共建流媒體的未來(lái)。