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

IPTV

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

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

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

解決組播傳輸下頻道快速啟動問題，終端加入組播組的時間是隨機(jī)的，無法保證每次加入組播組后接收到的報文就可以理解用于解碼并顯示，所以我們通過在系統(tǒng)中增加一個FCC Server，解決該問題，終端在起播觀看一個頻道的時候，優(yōu)先向FCC Server 請求一條單播流，F(xiàn)CC Server 會以1.X 倍的速率將I 幀和解碼所需的報文發(fā)給終端，配合終端快顯技術(shù)可以實(shí)現(xiàn)300ms 以內(nèi)的頻道切換速度。

IPTV多屏

隨著移動終端的發(fā)展，運(yùn)營商希望在IPTV 業(yè)務(wù)基礎(chǔ)上，發(fā)展手機(jī)等多屏業(yè)務(wù)，開始支持HLS（主流）、MPEG DASH（部分海外運(yùn)營商，支持MultiDRM）流媒體協(xié)議。這套系統(tǒng)在流媒體協(xié)議層面臨的問題是不同屏幕，不同DRM 格式，多種格式帶來了存儲空間成倍的上升，特別是NPVR 個人錄制業(yè)務(wù)，對存儲的需求非常大。主要解決思路就是JITP（Just In Time Package），即只要存儲一份內(nèi)容，根據(jù)用戶觀看的內(nèi)容格式進(jìn)行實(shí)時格式轉(zhuǎn)換。

OTT點(diǎn)播

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

OTT 直播

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

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

2、其次直播相較于點(diǎn)播需要額外考慮的一點(diǎn)就是直播時延，第一類：電視臺/ 事件（新聞/ 賽事/ 演唱會）直播基本沒有和觀眾互動的要求。所以它們依然選擇對CDN 友好的HLS 和DASH 協(xié)議，但是時延會高達(dá)10-30s，隨著CMAF 格式的出現(xiàn)，根據(jù)我們在實(shí)驗(yàn)室的測試數(shù)據(jù)表示時延可以小于5s。第二類：個人（游戲/ 網(wǎng)紅/ 秀場）直播，以國內(nèi)直播平臺為例，商業(yè)模式主要靠打賞分層，所以要求直播的E2E 時延必須低于5s，否則觀眾與主播的互動效果非常差，直接影響直播平臺的收入。這類廠家選擇的技術(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)境下的直播上行效果差成為直播平臺需要解決問題。為了解決這個問題，大家把眼光轉(zhuǎn)向UDP，基于UDP 的直播傳輸技術(shù)逐步進(jìn)入人們的視野。常見的有ZIXI、SRT 和RIST。ZIXI 屬于純商業(yè)化公司，顯然不合適大量個人直播上傳這類商業(yè)模式的直播平臺。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ù)棧構(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，主播與觀眾連麥等場景，這些對時延的要求直接從5s 變成1s 以內(nèi)， 甚至小于400ms， 為了滿足業(yè)務(wù)的發(fā)展，直播平臺選擇了實(shí)時通信的技術(shù)棧RTP+RTCP over UDP。一旦引入UDP，就需要解決丟包帶來的視頻體驗(yàn)問題，這里常見的技術(shù)有FEC、ARQ 等。

實(shí)時音視頻 RTC

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

如果把流媒體協(xié)議做三個維度劃分：質(zhì)量（畫質(zhì)/幀率）、平滑、延遲。實(shí)時音視頻通信和OTT 直播上傳場景相比，對低質(zhì)量的容忍度更高，即允許降低一定的質(zhì)量，下降（降幀率等）來換取更加平滑的體驗(yàn)和更低的延遲。這個選擇上的差異，導(dǎo)致在技術(shù)設(shè)計上需要打通網(wǎng)絡(luò)傳輸系統(tǒng)和音視頻編解碼系統(tǒng)，實(shí)現(xiàn)根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量實(shí)時動態(tài)調(diào)整音視頻編碼參數(shù)，在質(zhì)量、時延、平滑三個維度上進(jìn)行權(quán)衡得出最優(yōu)解。

流媒體新的發(fā)展方向

1、 新的媒體表現(xiàn)形式包括VR、自由視角、點(diǎn)云；他們與傳統(tǒng)視頻的最大區(qū)別在于，傳統(tǒng)視頻主要支持時間維度的定位，而新的媒體，除了支持時間維度的定位，還支持空間維度的定位。當(dāng)前主要在MPEG 標(biāo)準(zhǔn)組織中進(jìn)行討論，基于MPEG DASH 規(guī)范進(jìn)行演進(jìn)。以VR 為例，一般人類的FOV 視場角<140°，新的流媒體協(xié)議利用這個特性，可以實(shí)現(xiàn)根據(jù)觀眾觀看的視頻范圍，進(jìn)行部分傳輸，從而降低的對帶寬的訴求，這也很好的解決了傳輸?shù)臄?shù)據(jù)量越來越大對帶寬要求苛刻的問題。華為云視頻的Cloud VR 產(chǎn)品已經(jīng)支持8K VR、自由視角的直播和點(diǎn)播服務(wù)。

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