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

IPTV

IPTV 是由運營商主導建設的一套系統(tǒng)，他的主要對標對象是傳統(tǒng)廣電的數字電視。所以這套系統(tǒng)首要解決的是大規(guī)模直播的問題，在此基礎上還需要支持點播、時移、回看等新業(yè)務。運營商的優(yōu)勢就是可以自建一套可管理的網絡，所以直播就基于組播技術進行大規(guī)模分發(fā)。主要技術棧是RTP+TS over multicast，這個技術大大降低了直播峰值對流媒體服務器的壓力。而點播、時移、回看業(yè)務由于必須使用單播傳輸，所以當時選擇的技術棧是使用RTSP 進行流媒體控制，使用RTP+TS over UDP（少量基于TCP）進行數據傳輸。

現在這套系統(tǒng)服務了全國接近1.7 億多用戶。這套技術棧面臨的挑戰(zhàn)和對應的解決方案主要包括幾點：
解決單播基于UDP 傳輸丟包的問題，丟包會導致用戶觀看花屏或爆音，我們基于RTSP 協(xié)議擴展制定了一套規(guī)范，基于RTSP 的GET_PARAMETER擴展了重傳數據報文的信令，主要是基于NACK 原理進行設計，通知流媒體服務器哪個報文沒有接收到，流媒體服務器根據請求中攜帶的RTP 序號進行重發(fā)。

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

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

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

IPTV多屏

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

OTT點播

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

OTT 直播

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

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

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

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

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

實時音視頻 RTC

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

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

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

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

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