《移動時代新多媒體協議白皮書（57頁）.pdf》由會員分享，可在線閱讀，更多相關《移動時代新多媒體協議白皮書（57頁）.pdf（57頁珍藏版）》請在三個皮匠報告上搜索。

1、目錄目錄摘要摘要:.2 21.1.視頻制作域和傳輸域的場景、用例和關鍵指標視頻制作域和傳輸域的場景、用例和關鍵指標.4 41.1場景.41.2視頻制作域的數據傳輸.51.2.1電視制作域.51.2.2互聯網直播帶貨.91.3移動傳輸域的數據傳輸.112.2.視頻制作域傳輸協議視頻制作域傳輸協議.13132.1電視級制作使用的協議.132.1.1 SMPTE ST 2022.142.1.2 SMPTE ST 2110.152.1.3 NDI.172.1.4 無壓縮與淺壓縮的視頻編碼技術的簡介.182.2移動鏈路回傳協議.192.2.1 RTMP.192.2.2 SRT.202.2.3 WebRT

2、C.212.2.4 ZIXI 協議.222.2.5 RIST.232.2.6 GB28181 協議.242.2.7 ONVIF 協議.252.2.8 RTMP，WebRTC，ZIXI，RIST 和 SRT 的對比分析.263.3.移動傳輸域傳協議移動傳輸域傳協議.2 29 93.1自適應碼率傳輸.293.2面向廣播組播分發.363.2.1 基于 FLUTE 和 ROUTE 的廣播分發（Qualcomm）.363.2.2 基于 BIER 的組播分發.383.3單點分發 HTTP/HTTP2/HTTP3.413.3.1 HTTP/1 協議.413.3.2 HTTP/2 協議.423.3.3 HTT

3、P/3 協議.443.4VR 內容的分發.463.4.1 VR 媒體服務總體架構.463.4.2 VR 視頻傳輸模式.473.4.3 VR 媒體封裝及傳輸格式.484.4.小結和音視頻傳輸趨勢預測小結和音視頻傳輸趨勢預測.5050參考文獻參考文獻.5353致謝致謝.55552摘要摘要:隨著 5G 網絡的部署，手機等移動終端的通信能力得到極大提升。手機、Pad等移動設備觀看視頻已經從 WiFi 連接為主轉變為移動和 WiFi 連接并重的局面。通過 5G 蜂窩網絡觀看視頻，最大的優點是擺脫了 WiFi 連接的地域限制，使用戶能夠隨時隨地觀看視頻。為了提升用戶的體驗，手機廠家近年來不斷改善手機的GP

4、U 計算能力和顯示技術，為用戶呈現 UHD、10 比特 HDR 和高幀率的顯示效果。借助 5G 提供的巨大傳輸能力，提供內容的 OTT 公司順應這一趨勢，為用戶提供了大量 4K 超高清和 10 比特 HDR 的視頻內容。隨著 5G 的廣泛部署，大帶寬上行能力也逐漸凸顯。目前，5G 大上行產品已經可以支持高達 2Gbps 的上行峰值速率，用戶平均體驗速率也達到了百兆級別。5G 視頻背包已經可以提供播出級別的超高清視頻，這也開啟了基于淺壓縮協議的超高清視頻云端協同這一新應用場景?？梢灶A期，隨著后 5G 網絡提供更大的傳輸帶寬和更低的傳輸時延會，基于移動寬帶的視頻業務將會進一步向前發展，賦能更多的新

5、用例。視頻傳輸協議構建于 IP 層之上，利用物理層提供的帶寬支撐各種視頻業務。視頻傳輸協議的設計原則之一就是充分適配物理傳輸帶寬和信道的變化，來滿足不同視頻業務的需求。與 5G 結合的視頻傳輸協議應用有兩個方面的考慮：首先是被廣泛應用在后 4G 時代的傳輸協議，例如視頻背包使用的 RTP/RTMP協議，可以預期在一段時間內仍然將是主流的傳輸協議。隨著 SRT、WebRTC等低時延協議逐步成熟，也有可能成為背包傳輸的主流協議。在服務器分發視頻流方面也是類似情況，FLV、HTTP/1 等協議仍然被廣泛使用，但 HTTP/3等協議被越來越多的關注，可以預期新的協議會隨著 CDN、OTT/APP 和智

6、能手機幾個方面的不斷努力，新的協議逐步被廣泛應用。其次就是隨著 5G 傳輸速率不斷提升，原來用于以太網等固定連接傳輸的低時延、高速率協議也有可能被用于 5G 鏈路。例如 JPEG XS、NDI 等制作域協議也有可能被 5G 鏈路承載，實現播出級的云端制作。3本報告從視頻制作域和傳輸域的需求入手，分別總結了不同場景下傳輸協議的需求和關鍵指標，并給予技術分析。最后在此基礎上，本報告對面向未來移動通信技術的新型視頻制作和分發給予了展望。41.1.視頻制作域和傳輸域的場景、用例和關鍵指標視頻制作域和傳輸域的場景、用例和關鍵指標1.1 場景場景根據使用場景區分，可以將屏到屏的視頻呈現分為制作域和傳輸域。

7、制作域主要關注內容生產，通過有線或無線的方式將內容傳送到廣播中心。傳輸域關注內容分發，從廣播中心通過電視臺或者互聯網將內容發送給終端用戶。(a)視頻制作域示意圖(b)視頻傳輸域示意圖圖圖 1 1視頻制作和傳輸系統示意圖視頻制作和傳輸系統示意圖通常，視頻制作域可以分為電視級內容生產、互聯網直播和行業視頻應用。表 1 列出了視頻制作的場景分類。5視頻上行業務場景種類繁多，各場景的業務特性、視頻編碼方式，封裝與傳輸方式，QoE 等均有所不同，與之相對應的技術實現方案及組網架構也有所不同。同時，對網絡帶寬和時延要求也有所不同。本章的 1.2 章節將按照表 1 給出的分類詳述各個分類的典型應用和傳輸指標

8、。表表 1 1視頻視頻制作制作的場景分類的場景分類場景分類典型應用電視級內容生產影視拍攝及制作，賽事轉播，新聞采訪；移動互聯網直播新媒體直播、電商直播，互聯網主播，網紅直播，旅游文化休閑直播等；行業視頻應用視頻監控，無人機測繪拍攝，機器視覺的工業應用等；在傳輸域，傳統的視頻分發主要面向電視機、戶外大屏等固定接收終端。近年來隨著智能手機的快速發展，智能手機、平板電腦的數量已經遠遠超過了電視機等傳統終端。因此，傳輸域從有線擴展到了移動通信領域。業務形態既包括傳統的視頻節目推送、視頻點播，還包括短視頻、交互視頻等新的業務類型。1.2 視頻制作域的數據傳輸視頻制作域的數據傳輸1.2.1 電視制作域電視

9、制作域近年來，電視制作越來越多的利用移動通信網絡傳輸視頻內容。通過移動網絡聚合網絡，快速現場搭建高速、穩定、低延時的制作網絡，提供給車載/箱載系統，用于接收和發送各類 IP 化視音頻信號和數據信號，面向各類傳統媒體和融合媒體的制作發布。同時，作為快速輕便的傳輸方案，視頻背包近年來得到越來越多的應用。當前的背包主要通過 4G、5G 商用網絡，采用 HD/4K 攝像機+編碼器+4G、5G 聚合路6由的上行模式為主。同時便攜式業務會把編碼模塊和移動通信聚合模塊集成，采用 5G 背包和 5G 手機的形式。目前 5G 背包和 5G 手機以 HD/4K+Sub-6 5G 為主，編碼器以 HEVC 為主，預

10、期未來 8K 和 5G 毫米波網絡成熟之后，將會演進為 8K+5G毫米波背包，提供更大的帶寬。目前在專業內容生產制作領域，廣電內容制作和信號處理設備之間的連接，主要有三種方式：基帶有線傳輸、IP 有線傳輸和無線傳輸（微波、衛星，4G/5G等）?；鶐в芯€傳輸，是廣電領域傳統的傳輸和連接方式，通過采用 BNC 接口的同軸電纜，傳輸未壓縮的 SDI 信號（串行數字信號）。SDI 接口標準由 SMPTE 標準組織制定，具備不同的速率等級，目前常用于 4K 和 8K 視頻傳輸的通常為 SMPTEST-2082 定義的 12G-SDI 信號，可以通過 SDI 線纜傳輸 12Gbps 信號。SDI 信號傳輸

11、信號隨著線纜長度增加而快速衰減，通常 12G-SDI 的傳輸距離在 110 米以內。隨著視頻分辨率的不斷提升，基帶信號和 SDI 傳輸方式的傳輸速率普遍被認為趨近于物理極限，即 12Gbps。當前單線纜最多支持到 4Kp60 標準（12G-SDI），而 8K 內容的制作系統，則需同時采用 4 根 12G-SDI 線纜來傳輸一路 8K 信號?；鶐鬏斈芰Φ南拗?，增加了系統連接和調整的復雜度，也導致系統風險系數升高。另外，采用 SDI 傳輸的基帶信號基本上都是單向傳輸，設備間如果存在多種信號的交換需求（視頻、音頻、控制、同步等），就需要多套線纜提供雙向連接。隨著目前大型現場節目的復雜度越來越高，對

12、于轉播制作系統調整和機動性的要求也越來越高。隨著數字技術的發展，以 IP 網絡傳輸取代線纜傳輸，采用 IP 網絡架構替代傳統的基帶系統連接，是專業內容制作領域的發展趨勢之一。IP 傳輸一方面可以簡化基帶結構和連線的復雜度，借助 IP 網絡技術實現多種信號的復合與雙向傳輸；同時，IP 結構具備更為優異的帶寬性能，比如傳輸性能高達 100Gbps 的交換機已作為新一代視音頻系統路由終端替代傳統的基帶視音頻路由矩陣，可應對單鏈路 8K 信號的傳輸需求。在此之上，甚至可以考慮提升視頻采樣率和比特深度（如 4:4:4、12bit 等），以實現內容制作質量的進一步升級。IP 系統帶來的另一改變是實現了高質

13、量遠程制作的可能。通過部署專線，將現場的攝像機信7號通過 IP 專線傳給遠端或異地的演播室轉播系統，所有的制作和技術調整，都在遠端來完成，這樣能夠大大提升現場制作的效率。目前廣電領域采用的 IP 系統，遵循 SMPTE 發布的 ST-2110 標準協議，將 SDI的 AV 信號（視頻和音頻）轉換成 IP，并同時將音頻、視頻和數據三種信號區分形成三路獨立的 IP 數據流進行傳輸，在傳輸過程中可分別對每種信號進行處理。三種信號的分開與重新合并需要做到高精準的同步，為此，ST-2110 支持采用 PTP 協議進行時鐘校準，以確保所有音視頻流的同步轉換。除了在演播室、攝影棚的視頻制作，一些視頻拍攝還需

14、要在室外拍攝并通過無線技術傳輸回演播中心。這類視頻目前通常使用微波和衛星通過無線鏈路傳輸視頻。衛星傳輸制作域信號，一般是負責將演播室或現場轉播系統制作完成的基帶節目信號，通過地面衛星車內編碼器壓縮編碼后，再通過衛星鏈路實現上行轉發。微波傳輸，更多用于現場制作過程中，將需要移動拍攝的攝像機信號（如綜藝晚會中的無線斯坦尼康攝像機，馬拉松比賽中在移動拍攝馬車上的無線攝像機）通過攝像機加載的微波發射適配器，借助周圍高點的微波中繼轉發，通常由轉播系統來接收使用?？紤]到發射功率、帶寬、時延等因素，衛星或微波一般不會用于傳輸高碼率視頻。例如，高清 1080 傳輸碼率約為 8-15Mbps，而 4Kp50 約

15、為 30Mbps?？紤]到時延和現場環境的要求，微波的傳輸碼率可能會比衛星更低。由于傳輸碼率的局限對畫質產生影響，在高要求的廣電專業制作域，無線機位目前一般不會作為核心機位來使用，而更多是起到輔助作用。在 4G LTE 部署后期，已經有公司不斷嘗試使用 4G 商用網絡，通過多卡多鏈路聚合的方式向制作中心傳輸 4K 視頻信號。由于我國運營商提供了 4G 網絡的全國覆蓋，這種基于公網的傳輸方式具有非常大的靈活性，無需提前布線可以隨時隨地的提供超高清視頻傳輸服務。當前我國 5G 商用網絡已經實現了全國大部分城市的覆蓋，上行傳輸速率已接近 80-100Mbps。相比傳統衛星和微波，5G 在傳輸速率及使用

16、成本方面展現出更佳的適用性及更高的性價比。隨著 5G 基站在國內的快速布設，5G 信號的覆蓋8范圍和信號強度將逐步提升，切片等新興技術的運用也預期將為廣電信號傳輸的高可靠性要求提供精準的服務質量保障。另外，視頻編解碼技術的不斷升級，特別是針對編碼效率及編碼時延的進一步優化，為超高清視頻信號在制作域借助 5G 進行傳輸提供了先決條件。在高碼率和高畫質得到保障的前提下，綜合考慮編碼延時和 5G 信道延時對方案設計和實際應用而言將非常重要。云端制作是遠端制作的進一步發展，通過 IP 鏈路將視頻信號傳回廣播中心。圖 2 是超高清視頻通過移動通信鏈路傳輸示意圖。攝像機將采集到的數據傳輸到編碼器進行編碼，

17、編碼后的數據通過路由器和 CPE 作為上行數據發出。信號通過邊緣計算節點 MEC、OBS 通信機房進入國際廣播中心（IBC）。圖圖 2 2 通過通過5G5G鏈路轉播回傳超高清視頻示意圖鏈路轉播回傳超高清視頻示意圖超高清視頻制作通常采用 SMPTE ST-2110 傳輸無壓縮或淺壓縮信號，通過傳輸大帶寬信號獲得極低的傳輸時延。以 4K 為例，攝像機輸出的通常是 12Gbps的 SDI 信號，通過制作域的淺壓縮編碼器后轉換為 IP 碼流通常的大小在數吉比特到數百兆比特每秒。根據經驗值，用于母盤制作的視頻壓縮率控制在基帶信號的 1/8-1/12，即 1-1.5Gbps。刨除信號帶寬中的部分冗余信號，

18、信號帶寬通常需要在 600Mbps 以上。淺壓縮信號通常需要預留一幀以保證同步，即在 50p/s的信號編碼需要大約 25-30ms 的時延，同時移動通信系統需要引入 60ms 左右的端到端時延，屏到屏的總時延大約在 100ms 以內。目前移動視頻傳輸通常采用 5G 背包形式。即將攝像機信號通過 HEVC 等方式進行深度壓縮編碼，通過 5G 商用網絡傳輸。這種方式對網絡適應性好，通常無9需部署專用網絡。缺點是受限于商用網絡傳輸能力，通常4K信號被壓縮至 30Mbps以內，信號損失大，不適合母盤制作和大屏播出。為了提供適合大屏幕播出的高質量信號，編碼后的速率需要保證在 80-100Mbps 左右。

19、表表 2 2 超高清（超高清（4K4K）信號的示例性）信號的示例性KPIKPI場景視頻壓縮標準數據帶寬屏到屏時延制作域JPEG XS,SDI overIP600Mbps-Gbps=100ms視頻背包HEVC 等80 100 Mbps20ms25:10.5 GbpsMXFH.265/HEVC(AI)H.265/HEVC(AI)20ms50:10.25 GbpsMXFH.266/VVC(AI)H.266/VVC(AI)20ms95:10.13 GbpsTBD注：上述提及的碼率為 4K/P50 的條件下，延時僅包括視頻內容編碼所需的典型延時，不包括傳輸及數據封裝等其他環節引入的延時。HEVC 以及

20、VVC 的 AI（AllIntra）的編碼為理論值，并未有大量商用。192.22.2 移動鏈路回傳協議移動鏈路回傳協議隨著 5G 的部署，遠端采集的信號可以通過 5G 等移動通信網絡及時回傳到轉播中心。比較典型的協議包括：RTP、SRT、RTMP、RIST、ZiXi 等。后 5G 時代，隨著帶寬的增大預計回傳協議會朝向更低編碼時延、更低壓縮率的方向發展。隨著視頻業務的快速發展，眾多視頻流媒體協議不斷涌現，并被用于不同的視頻工作流。根據 Haivision 的調研報告5，大多數受訪者使用不止一種流媒體協議。對于視頻低延遲回傳與分發場景，基于 TCP 的 RTMP 實時消息傳遞協議仍然是最廣泛使用

21、的協議，但 RTMP 的部分缺點在應用中逐漸顯現，以至于引起了部分 CDN 提供商的憂慮。伴隨著網絡與視頻應用的發展，以 UDP 為核心的流媒體視頻傳輸逐漸成為新的選擇，近年來 SRT 的安全可靠傳輸、WebRTC 的實時互動性能，在諸多場景下展現出更為優異的適用性，出現了逐步取代 RTMP 的趨勢。目前，在視頻上行傳輸方面，RTMP，SRT 和 Web RTC 協議占比較高。在將 OTT 視頻傳輸到最終用戶方面，HLS 和 MPEG-DASH 是最受歡迎的。由于CMAF 支持 HLS 和 DASH，如開源低延遲 HLS 項目、LHLS 或蘋果自己的版本 LL-HLS，它在與其他低延遲交付協議

22、的競爭中發揮著重要作用，預測使用者數量會逐步上升。2.2.12.2.1 RTMPRTMPRTMP（Real Time Messaging Protocol，實時消息傳輸協議）協議最初是由Macromedia 為通過互聯網在 Flash 播放器與一個服務器之間傳輸流媒體音頻、視頻和數據而開發的，基于 TCP 協議傳輸，并由 Adobe 采納，為其 Flash 技術服務，并成為類似 RTP 等復雜機制的替代。但很長時間以來它都是不開放代碼的，因此從 2005 年開始，人們開始逆向此協議并發布了若干開源版本。最終 Adobe在 2012 年發布了 RTMP 標準，但仍保留了部分技術，如 H.264

23、先經過一種加密的握手方式才能進行解碼播放。隨著視頻直播領域的興起，也成為業內廣泛使用的協議。由于其基 TCP 的丟包重傳能力和可調緩沖區而享有可靠的聲譽，但其也存在著累積延遲和加密方面的問題。20RTMP 協議至今仍然被廣泛應用，但是近年來在應用中觀察到如下問題急需解決：1.協議比較古老，最后更新日期是 2012 年，最高只支持到 H.264,對HEVC/AV1，VP9 等視頻格式沒有定義，很多都是各 CDN 廠家自行開發的；2.RTMP Over TCP 連接時間過長，TCP 需要 RTMP c0/s0 到 c2/s2 三次握手，除此之外，其本身又存在 c0/s0 到 c2/s2 的三次握手

24、，再加上 Connection、Createstream、Play/Publish，總地來說 RTMP 完成一次建連需要進行 9 次會話，因此 RTMP 傳輸時延通常至少會在 2 秒多；3.RTMP 的傳輸完全依賴傳輸層的算法來進行擁塞的管理，不夠靈活；4.不能實現自適應帶寬編碼，依賴于 TCP 協議無法提供實時帶寬數據對可變碼率的支持。2.2.22.2.2 SRTSRTSRT（Secure Reliable Transport）6安全可靠傳輸協議是新一代低延遲視頻傳輸協議，是一種開源、免費和應用靈活的規范，它的性能與專用的協議一樣優秀，同時能夠在不同制造商生產的產品之間工作。SRT 最初由

25、Haivision 和Wowza 開發，目前 SRT 聯盟成員超過 450 個，包括 Bitmovin、Brightcove、CanalCable、Comcast Technology Services、Cinergy、Deluxe、Ericsson、Huawei、Harmonic 和 NGCodec 等少數知名公司以及數十家小型供應商。SRT 使用 UDP 協議，旨在利用有損網絡來確?？煽啃?。它通過使用“高性能”發送器和接收器模塊來實現這一點，該模塊不會通過握手確認來阻塞網絡。這允許它擴展并最大化可用帶寬。SRT 保證發送的分組節奏（壓縮視頻信號）與解碼器接收的分組節奏相同。SRT 增加了專

26、為高效安全的視頻流而設計的其它功能：128/256 AES 加密，通過公共網絡在鏈路級提供安全性；內容不可知，并在單個 SRT 流中匯集多個視頻，音頻和數據（元數據）流，使其能夠輕松支持高度復雜的工作流程；支持發送和接收模式（與僅支持單一模式的 RTMP 和 HTTP 相反）；21在發送器/接收器模塊內，可以檢測網絡性能，并使用一種自適應比特率和糾正延遲，丟包和抖動；SRT 協議具有良好的丟包重傳機制，同時支持 ACK,ACKACK,NACK；基于時間的報文發送，防止流量的突發；豐富的擁塞控制統計信息，RTT，Lost rate，inflight，Send/receivebitrate，利用這

27、些信息做擁塞控制，或自適應 Bitrate；SRT 是開源的，對于應用開發者較為友好；可支持當前和下一代壓縮技術，即 H264（AVC），H265（HEVC），AV1，VP9；SRT 開發了許多新功能，包括傳輸大文件、小的對話數據等等。但是 SRT 的“傳統優勢領域“還是實時的視音頻傳輸，SRT 本質上是一個點對點的傳輸協議（單播而不是組播）。SRT 的亮點在于能夠克服有損網絡中的抖動和丟包。SRT目前還是專注于節目的制作和分發而非交付。SRT 是一種能夠在復雜網絡環境下實時、準確地傳輸數據流的網絡傳輸技術，它在傳輸層使用 UDP 協議，具備 UDP 速度快、開銷低的傳輸特性，支持點對點傳輸，

28、無需中間服務器中轉，可實現低至 120ms 的低延時傳輸。SRT 協議基于 UDP 協議，雖然 UDP 協議是一種不可靠傳輸協議，在互聯網抖動與丟包的網絡環境下不穩定，但是憑借 SRT 強大的丟包重傳的數據恢復能力，前向糾錯技術應用等，可將網絡丟包的可能性降到最低，確保了 SRT 傳輸穩定性。同時 SRT 還可以進行 AES 加密，從而確保數據在傳輸過程中的信息安全。此外，針對公司或組織運用防火墻保護私有網絡安全的策略，SRT 使用的握手過程支持出站連接，而不需要在防火墻中打開危險的永久外部端口，從而維護了公司的安全策略。2.2.32.2.3 WebRTCWebRTCWebRTC（Web Re

29、al-Time Communication）即”網頁即時通信”是一項在網頁瀏覽器內部進行實時視頻和音頻通話的技術，于 2011 年 6 月由谷歌開源。22WebRTC 允許開發人員使用 HTML 和 JavaScript API 來創建實時應用，而無需下載安裝任何插件。作為典型的瀏覽器之間的協議，WebRTC 最大的特點是低延時和無卡頓。WebRTC 可以提供點對多點的安全連接，使得多個音頻合視頻流可以在其連接上流動。WebRTC 提供了視頻會議的核心技術，包括音視頻的采集、編解碼、網絡傳輸、顯示等功能，并支持跨平臺（Windows，Linux，Mac，Android）。2020年的疫情驅使視

30、頻通信需求劇增，也驅動 WebRTC 面向更大規模的在線并發會議場景演進。與此同時，去噪、用戶隱私、打洞等功能逐步完善，大量新發布的規范也逐步涵蓋了 WebRTC 傳輸、安全、數據通道、擁塞控制等方面。2021 年 1 月26 日，W3C 和 IETF 同時宣布賦能無數服務的 WebRTC 發布成為正式標準78。WebRTC 因傳輸速度快、延遲低，適合應用于對實時性、互動性要求高，但對畫質要求不嚴苛的應用場景。當前在音視頻會議、在線教育、即時通訊、游戲及人臉識別等領域，WebRTC 正被廣泛采用。與此同時，WebRTC 的兼容性和瀏覽器不斷升級帶來的維護成本是使用者需要考慮的問題。2020 年

31、，谷歌在 WebRTC及其關應用上進行了大舉投資，以進行代碼優化和加強功能集合，使其在多個平臺和設備上的運行更加高效和穩定。2021年伊始，大量關于 WebRTC/SIP/RTP/SDP相關的規范（例如：RFC8830-34,RFC8836，RFC8858）密集發布。這些發布的建議規范涵蓋了 WebRTC 傳輸，安全，數據通道，擁塞控制，SIP/SDP 和 RTP 的支持。2.2.42.2.4 ZIXIZIXI 協議協議ZIXI 的傳輸流協議是一種內容和網絡感知協議，可動態調整以適應不斷變化的網絡條件，并采用糾錯技術實現 IP 上網絡上的無差錯視頻流傳輸。這種動態機制以最小的物理帶寬開銷，提供

32、低端到端低時延傳輸。并將實時消除抖動，恢復和數據包重新排序，平滑視頻傳輸，并將視頻重新生成為其原始形式。ZIXI 提供可預測的低延遲、無數據包丟失的卓越可靠性和廣播級視頻質量(標清、高清和 UHD)，沒有延遲、分辨率或斷斷續續的折中。從一個支持 ZIXI的設備/服務器到另一個支持 ZIXI 的設備/服務器的數據流保護數據流免受路徑上質量下降的影響。它能夠在任何距離上傳輸高質量的視頻，同時克服公共互聯23網不斷變化的網絡條件，在公共互聯網中，網絡錯誤、數據包丟失、抖動和無序數據包的數量“每秒”都會波動。ZIXI 的傳輸流技術通過網絡感知、動態去抖動、MPEG 特定的優化、Z-ARQ誤差恢復、Z-

33、FEC-動態內容感知、主動多路徑錯誤恢復、UDP 單播或多播的自適應比特率控制以實現最高質量和可靠性。并通過基于 DTLS 標準的保護提供一流的安全性，采用了包括加密和密碼保護在內的多層方法的 256 位 AES 傳輸加密。ZIXI 9發端將數據流封裝在 ZIXI 傳輸協議中，并通過標準的 IP 連接進行點對點或多點傳輸。ZIXI 可以部署在本地或云中，能夠監控路徑上任何地方的流。對于管理、處理和更大規模的分發功能，ZIXI 可以支持復雜的實時內容生產制作，并能夠支持可靠的和可擴展的集群環境中的轉碼、錄制等。2.2.52.2.5 RISTRISTVideo Services Forum(VSF

34、)于 2017 年初成立了可靠的互聯網流傳輸協議（Reliable Internet Stream Transport，RIST）小組，為協議創建了通用規范。視頻壓縮技術的進步和互聯網基礎設施的普及，使得流媒體在互聯網上廣泛傳輸。但是網絡丟包一直是一個困擾人們的問題。市面上已經有許多私有的解決方案用于解決流媒體傳輸的丟包問題，但是由于是私有協議，各個廠商的設備之間無法實現互操作性。RIST10旨在解決在公共網絡上的丟包問題，同時解決各廠商設備之間缺乏互操作性的問題。從 2018 年 10 月推出的 tr06-1 規格，到將在 2021 年推出的 tr06-3 規格，RIST 一直在進行更新調整

35、，緊隨著時代變化的腳步，產品隨著最新的網絡技術，壓縮技術等保持更新換代，更加貼合時代的需求?，F在 RIST 有兩種配置文件：主要配置文件 main profile 和簡易配置文件 simple profile，另有高級配置文件 advanced profile 預計在 2021 年發行。簡易配置文件 simple profile 的基礎流是基于標準 RTP 協議的，且與非 RTP設備也可適配，其余特性還包括：基于 ARQ 的數據包恢復；非常好的性能（接近50%的丟包率）；支持多鏈接支持；且其他公司可以自由地創新并改進的同時不丟失兼容性。主要配置文件 main profile 在傳輸時可以將多個

36、流結合到單個 UDP 接口，24這簡化了許多的 IT 調試，且連接可以在任一終端進行初始化，同時對于任何類型的 IP 數據也有可支持選項，另外，在加密時，主配置文件相較于簡易配置文件還提供可調試的 AES 加密。這些之外，RIST 還有著一些其他特性：通過刪除空包來進行頻帶最優化，支持高比特率的操作。目前正在開發的高級配置文件 Advanced profile，它可以自動調試網絡參數，并動態地根據網絡環境的變化進行修正，可以進行擁塞控制，VPN 隧道，在有多個流時的進行時間控制，IGMP 偵聽，支持 VBR，NAT 穿越防火墻，以及因特網/衛星混合模式等。開源的 RIST 接口在 Upipe,

37、libRIST,FFMPEG 中都有支持。RIST 可將數據流分為多個流來進行傳輸，并支持無縫切換和雙向傳輸。RIST 的技術建議已經通過類似的標準化過程達成一致，目前已經有 40 余個支持成員，并且在快速增長。鑒于這是迄今為止唯一一個團體開發的開放解決方案，有理由相信 RIST 將是許多廣播公司的強制性要求。此外，RIST 還允許通過以僅實時傳輸協議模式運行與非 RIST 接收器的互操作性，有效地使其與SMPTE2022-1 和 SMPTE2022-2 接收器兼容。2.2.62.2.6 GB28181GB28181 協議協議GB/T-28181 協議11是在國際上通用的 SIP 協議進行私有

38、化定制，流媒體方面就是在國際最流行的編碼上進行封裝。聯網系統的信息傳輸、交換、控制方面的 SIP 監控域互聯結構見圖 4，描述了在單個 SIP 監控域內、不同 SIP 監控域間兩種情況下，功能實體之間的連接關系。功能實體之間的通道互聯協議分為會話通道協議、媒體（視、音頻）流通道協議兩種類型。區域內的 SIP 監控域由 SIP 客戶端、SIP 設備、中心信令控制服務器、流媒體服務器和信令安全路由網關等功能實體組成。各功能實體以傳輸網絡為基礎，實現 SIP 監控域內聯網系統的信息傳輸、交換和控制。在若干個相對獨立的 SIP或非 SIP 監控域以信令安全路由網關和流媒體服務器為核心，通過 IP 傳輸

39、網絡，實現跨區域監控域之間的信息傳輸、交換、控制。25圖圖 4 4 監控域互聯示意圖監控域互聯示意圖聯網系統在進行視音頻傳輸及控制時應建立兩個傳輸通道：會話通道和媒體流通道。會話通道用于在設備之間建立會話并傳輸系統控制命令；媒體流通道用于傳輸視音頻數據，經過壓縮編碼的視音頻流采用流媒體協議 RTP/RTCP 傳輸。媒體流在聯網系統 IP 網絡上傳輸時采用 RTP 傳輸，RTP 的負載應采用如下兩種格式之一：基于 PS 封裝的視音頻數據或視音頻基本流數據。2.2.72.2.7 ONVIFONVIF 協議協議ONVIF 12是基于網絡視頻的使用案例，適用于局域網和廣域網。規范始于一個核心套接口函數

40、配置和通過定義它們的服務類接口實現控制網絡視頻設備。網絡視頻設備包括 NVT、NVD、NVS。該框架涵蓋不同網絡視頻環境下的各個階段，從網絡視頻設備部署和配置階段到實時流處理階段。這個規范涵蓋了設備發現、設備配置、事件、PTZ 控制、視頻分析和實時流媒體直播功能，以及搜索，回放和錄像錄音管理功能。所有的服務使用同一種的 XML schema（XML 文檔的結構）。ONVIF 標準將為網絡視頻設備之間的信息交換定義通用協議，包括裝置搜尋、實時視頻、音頻、元數據和控制信息等。ONVIF 規范中設備管理和控制部分所定義的接口均以 Web Services 的形式提供。ONVIF 規范涵蓋了完全的 X

41、ML 及 WSDL的定義。每一個支持 ONVIF 規范的終端設備均須提供與功能相應的 Web Service。26服務端與客戶端的數據交互采用 SOAP 協議。ONVIF 規范的目標是實現一個網絡視頻框架協議，使不同廠商所生產的網絡視頻產品（包括攝錄前端、錄像設備等）完全互通。ONVIF 中的底層流媒體協議主要還是通過 RTP/RTSP 實現。2.2.82.2.8 RTMPRTMP，WebRTCWebRTC，ZIXIZIXI，RISTRIST 和和 SRTSRT 的對比分析的對比分析在 4G 時代，RTMP 協議以低延遲著稱并被廣泛應用。作為基于 TCP 的標準協議，RTMP 兼容性極佳，對用

42、戶來說，在現有單向直播架構上，接入成本較低。但隨著網絡技術的發展，RTMP 協議開始顯得相對老舊，不支持 H.265。在緩沖器固定的情況下，當 RTMP 客戶端播放端距離服務器越遠（RTT 越），它從服務器獲得的流吞吐量就越少。同時，由于 RTMP 基于 TCP 協議，不會丟包，所以當網絡狀態差時，服務器會將包緩存起來，導致累積的延遲，延遲時間一般在幾秒到幾十秒。RTMP 無法提供實時帶寬數據來動態調整視頻編碼的 Bitrate，無法實現 NAE 網絡自適應帶寬編碼。因此，逐漸被 WebRTC、SRT 等新進協議取代。WebRTC作為 Google 公司的開源技術，降低了音視頻通信的接入門檻。

43、WebRTC使用 UDP 作為傳輸層協議，它的顯著優勢在于用戶體驗好，且僅通過分享鏈接即可觀看視頻，非常適合應用于大規模在線并發、有互動性要求的互聯網在線直播、培訓、會議等場景。許多實時音視頻服務專業廠商通過采用 WebRTC 技術，可實現毫秒級的低延遲，遠遠低于傳統 RTMP 的分發延遲。GB28181和 ONVIF 都是為了確保安全防范視頻監控聯網系統信息傳輸即網絡視頻在安防市場的應用接口標準的不同，使不同廠商生產的網絡視頻產品具有互通性的接口標準，其底層流媒體數據傳輸協議主要還是基于 RTP（實時傳輸協議），并通過 RTCP（實時傳輸控制協議）進行數據傳輸質量控制。在網絡傳輸層，其媒體數

44、據傳輸可以采用 UDP 或者 TCP，以適配不同的網絡組網環境，滿足視頻監控中各種復雜的應用場景。ZIXI 協議進入市場較早，目前很多攝像和編解碼設備支持 ZIXI 協議。ZIXI提供卓越的性能(可預測的低延遲)、卓越的可靠性(無數據包丟失)和廣播級視頻質量(標清、高清和 UHD)，沒有延遲、分辨率或斷斷續續的折中。SRT 協議建立在開源的 UDT 協議上。它強制輸入數據加密，可以保護數據安全。它允許在一個連接上混合多個 SRT 流。SRT 試圖加快重傳速度。SRT 在防火27墻的情況下也可以很好地工作，是目前收到較多關注的傳輸協議。SRT 在國內應用較多，但目前主要的問題是眾多廠家針對 Ha

45、vision 的 SRT 開源協議做了各自修改，互相之間適配性較差。目前 Haivision 等公司已經推動 SRT 的 IETF 標準制定，預期未來基于統一的 IETF 標準，SRT 的互通性會得到改善。RIST 需要兩個端口，第一個端口用于傳輸媒體流，并在第二個端口上使用RTCP 創建了一個控制界面。RTCP 協議是雙向的。RIST 的技術路線圖分為三種，分別是簡單配置、主要配置和先進配置。其中簡單配置包括交互 ARQ、重傳限制、連接聚合和冗余傳輸路徑。它兼容普通的 RTP 協議，利用 RTCP 協議進行丟包恢復。RIST 的主要配置包括流加密，多流隧道，高比特率支持等。RIST 的加密采

46、用 DTLS，它和網站采用的 TLS 類似。它還采用預分享的密鑰，不需要證明。RIST采用了 GRE 隧道，非常適合 IPv6 穿透。GRE 隧道消除了額外的端口，并且允許在一個連接中多流復用。GRE 隧道也支持雙向流等。RIST 的先進配置包括智能帶寬優化，公共通道會話管理，集中呼叫和因特網/衛星混合操作功能。28表表 5 5 ZIXI,ZIXI,SRTSRT和和RISTRIST協議的對比協議的對比協議協議防火防火墻穿墻穿越越ARQARQFECFEC 前前向糾錯向糾錯加密加密鏈路保護鏈路保護空包空包壓縮壓縮ZIXI支持，兩端支持支持，專有的AES128/256&DTLS支持（SMPTE202

47、2-7）支持RIST支持，發送方（計劃兩端）支持支持SMPTE2022-1支持（可調試的AES&DTLS）支持不支持（計劃）SRT支持，兩端支持支持AES128/256&TLS1.3不支持（計劃SMPTE2022-7）支持ZIXI,RIST 和 SRT 均基于 UDP 協議，支持高碼率的分發能力，具備 FEC 前向糾錯和 AES 加密功能。同時，在傳統的 UDP 協議之上增加了 ARQ 丟包重傳。使用 ZIXI,SRT 和 RIST 協議的場景很豐富，包括攝影機到基站的轉播、體育場轉播、新聞報道和云轉播等等。后期我們將會進行基于 5G 網絡的 SRT 和 RIST傳輸性能對比測試分析。293.

48、3.移動傳輸域傳協議移動傳輸域傳協議當前，采用智能手機等移動客戶端觀看體育賽事、演唱會等實時節目已經成為趨勢?；?IP 的廣播協議呈現出了推流效率高、擴展性好、低時延等發展趨勢。3.13.1 自適應碼率傳輸自適應碼率傳輸在 20 世紀 90 年代，互聯網流媒體先驅們在為用戶交付視頻內容的時候注意到一個嚴重的問題：不同的用戶通過技術連接到互聯網，其帶寬差異很大：有些人使用撥號，有些人使用 DSL 或 ISDN，還有一些人使用 T1 連接。這個難題使內容發行商陷入兩難境地：他們應該用什么視頻碼率來編碼他們的內容？如果他們使用高比特率，他們有可能剝奪大部分觀眾的權利。如果他們使用一個 最低共同標準

49、 的比特率，那么他們擁有最好連接的最高付費客戶將收到低質量的視頻。RealNetworks 公司在 20 世紀 90 年代末推出了一個簡單、粗暴的解決方案：以多碼率對同一內容進行編碼。在會話開始時，讓終端用戶根據他們的連接速度選擇碼率。這個簡單的解決方案比單一的(而且是次優的)碼率編碼的方案有了改進，但仍有兩個頭疼的問題:1.它要求最終用戶知道他們的連接速度（并考慮到各種開銷，如 TCP、IP、以太網和物理層頭），這對普通用戶來說是不可行的。2.它假定帶寬在整個流的持續時間內保持固定-鑒于互聯網的公共性質和由此產生的高度動態流量和負載，這是一個糟糕的假設。因此，2007 年，Move Netw

50、orks 通過在多碼率編碼的概念上增加一些改進，引入了自適應 HTTP 流的概念。他們沒有將每個媒體資產編碼為一個單一的文件，而是將其編碼為一系列可獨立解碼的小文件或片段。例如將一部兩小時的電影編碼為 720 個 10 秒的片段。在多碼率編碼中，每個變體將被編碼為多個片段，并確保每個片段的邊界都是對齊的。然后創建一個播放列表，其中包括關于變體數量的信息（內容被編碼的不同比特率）以及關于單個文件段的信息（如其位置、持續時間等）。30在會話開始時，播放器設備將下載播放列表，并從一個默認的變體中請求片段（使用 HTTP GET 請求）。當片段被下載時，播放器將不斷估計自己和服務器之間的帶寬，并在分段

51、邊界上的自適應比特率(ABR)階梯上下移動。播放器的目標是在不超過估計帶寬的情況下接收最高質量的視頻，同時適應帶寬的潛在波動。圖 5 用 ABR 階梯說明了這一概念，ABR 階梯由三種變體組成（0.5、1.5 Mbps和 5.0 Mbps）。突出顯示的片段是由播放器要求并顯示的。具有諷刺意味的是，這本身并不是一個流傳輸協議，而是一系列文件下載。文件段下載仍然受益于 CDN 緩存以及通過 TCP 端口 80 的防火墻穿透，并增加了動態帶寬適配的好處。該方案的可擴展性得益于這樣一個事實，即將動態適配帶寬的智能(用于估計帶寬和適應帶寬)放在客戶端，而不是服務器。與 RTP 不同，HTTP 是無會話的

52、，并且不包括 RTCP 消息的交換(盡管底層 TCP 協議確實要求服務器負責錯誤和流量控制)。圖圖 5 5 ABRABR多碼率階梯示意圖多碼率階梯示意圖Move Networks 的想法很快被當時的主要流媒體技術提供商采用。微軟在2008 年推出了基于該思路的版本，命名為 Smooth Streaming。2009 年，蘋果和 Adobe 分別推出了 HTTP 實時流（HLS）和 HTTP 動態流（HDS）。雖然這些相互競爭的技術依賴于上述相同的原則，但它們在兩個重要方面有所不同。它們使用不同的文件格式來封裝音頻/視頻內容（Smooth Streaming 使用 MP4，HLS 使用MPEG-

53、2 傳輸流，HDS 使用 F4V），并且它們對其播放列表文件使用不同的語法。而這集中不同的技術路線恰恰導致了市場的分裂。不同的設備使用不同的專有技術，無法互操作。內容提供商不得不以多種格式對相同的內容進行編碼，而31CDN 則不得不以不同的格式分發和緩存相同的內容-導致存儲和帶寬的浪費。為了解決這個問題，移動圖像專家組（MPEG）在 2011 年制定了 HTTP 動態自適應流（DASH）標準，希望各方都能使用這種單一的方法。DASH 基于碎片化的 MP4（fMP4）容器格式和標準化的清單文件語法，可以實現動態廣告插入（DAI）、3D 視頻、多攝像機角度、字幕和隱藏字幕以及實時和預先錄制內容的混

54、合流式播放等高級功能。雖然 DASH 現在已經在很大程度上取代了 Smooth Streaming 和 HDS，HLS 仍然被蘋果設備廣泛使用，這些設備構成了相當大的市場份額。因此 MPEG 推出了多個方案和規范來更好的解決這個問題，其中最成功的就是 CMAF，全稱 CommonMedia Application Format，CMAF 的核心就是促使 HLS 和 DASH 同時使用一種媒體封裝格式（加入限制的 ISO BMFF 文件格式），如圖 6 所示意。圖圖 6 6 CMAFCMAF為為DASHDASH、HLSHLS提供統一的封裝提供統一的封裝通用媒體應用格式(CMAF)的規范旨在為將由

55、 DASH 和 HLS 流式傳輸的資產提供單一容器格式。此外，通過指定字節范圍而不是媒體文件或數據段來請求媒體的概念允許終端設備同時使用 DASH 和 HLS。與傳統的 RTP 相比，DASH 和 HLS（或 CMAF）協議更適合互聯網或不可靠網絡傳輸，卻有一個讓人詬病的缺點：典型的情況下，通過 HTTP 自適應的實時會話會有 30 秒以上的端到端延遲。為了改善延遲問題，廠商們引入了新的技術，例如分塊編碼和傳輸，它們有望將端到端的延遲減少到幾秒。其基本思想是編碼器將文件段(通常持續時間為2 到 4 秒)劃分為小至 500 毫秒的較小段。然后，每個塊都可以單獨轉發到打包32器(并轉發到源服務器，

56、通過 CDN 一直轉發到客戶端)，而不必等待整個數據段編碼完成。與數據段本身不同的是，這些數據塊不能獨立解碼，因此碼率切換仍然發生在數據段邊界上，但通過這個技術，端到端的延遲已經可以縮短到幾秒了。圖圖 7 7 低時延分片顯著降低時延低時延分片顯著降低時延其中，具有代表性的標準是 LL-HLS（Low-Latency HLS）和 LL-DASH（Low-Latency DASH）。2019 年 6 月，Apple 在 WWDC 大會上提出了 HLS 的擴展LL-HLS標準規范。該擴展與常規 HLS 向后兼容，同時提供了 Apple 認可的方法來降低HLS 的延遲，主要手段包括：1)采用 HLS

57、Partial Segments 機制，允許片段分為更小的部分，類似于 CMAF 定義的 Chunk;2)服務端通過 HTTP/2 來實現媒體描述文件與媒體內容的發送傳輸。2020 年初，Apple 宣布對 LL-HLS 規范草案進行更新。與早期的版本相比，保留了第一個特性，在媒體描述文件（M3U8）中通過#EXT-X-PART 標簽來描述 Partial Segment，每個 Partial Segment 可以獨立生成、打包和發送，且每個 Partial Segment 可以很短，不必像 Segment 一樣必須是 IDR 幀開頭，從而達到降低延時的目的。對于第二個特性，此次更新刪除了 H

58、TTP/2 的要求，而是引入了一個新標簽來描述即將出現的片段。新提出的標簽稱為#EXT-X-PRELOAD-HINT，借助此標簽，發布 LL-HLS 流的服務器可以描述繼續播放所需的下一個媒體數據的最可能位置。2017 年 4 月，LL-DASH 首次被提出，2020 年 3 月，MPEG 發布 LL-DASHGuidelines。LL-DASH 的實現參照了CMAF 中的CTE(Chunked TransferEncoding)機制，通過使用 HTTP/1.1 Chunked Transport 來傳輸媒體片段，與CDN 能很好的兼容，如圖所示。此外，LL-DASH 通過“提前通知”的機制，

59、片段33在被完全準備好之前，客戶端就可以知道其下載地址，發起下載請求。在傳輸過程中，通過使用 Chunked Transport，以 Chunk(Chunk 是比 DASH 片段更小的媒體片段，一般為一幀或幾幀)為單位進行傳輸，實現邊編碼，邊傳輸，從而節省了準備一個完整媒體片段的耗時。在兼容性方面，除了使用 HTTP/1.1 ChunkedTransport 來傳輸媒體片段外，LL-DASH 依然可以解析標準 DASH 的媒體描述文件（MPD），并請求相應的片段進行下載和播放，僅僅是不再具有低延遲特性而已。盡管 LL-HLS 和 LL-DASH 從設計上可以減低延遲，同時支持多碼率自適應，但是

60、這些協議目前仍然在推廣當中，實際 CDN 廠商支持不足，缺乏真實大規模使用的成功案例。尤其在國內，目前完全支持 CMAF、LL-DASH 或 LL-HLS 的 CDN 廠家非常有限。國內流媒體傳輸使用較多的依然是 HTTP-FLV 的模式，雖然協議比較古老，但基建成熟，架構穩定，終端和操作系統支持較為友好。FLV 協議設計最大的問題是不支持多碼率自適應，難以平衡清晰度和流暢度。鑒于 FLV 的產業鏈成熟優勢，業界期望能改進 FLV，使其在保證低延遲的同時，支持多碼率自適應。2020年 6 月，CCSA（中國通信標準化協會）通過了基于流式的直播多碼率協議（LAS:Live Adaptive St

61、reaming）的立項（標準計劃編號為 2021-0503T-YD）。圖圖 8 8 LASLAS架構示意圖架構示意圖上圖是 LAS 的基本架構圖，其基本工作流程為 LAS 客戶端首先下載一個媒體34呈現描述文件（類似 DASH 的 MPD 文件或 HLS 的 M3U8 文件），從而得到媒體的相關信息，例如檔位信息、地址信息等。緊接著 LAS 客戶端向服務端發送 LAS 請求，拉取直播流。LAS 服務端以流式的方式，源源不斷的向客戶端推送數據。當客戶端檢測到網絡發生變化且需要切換媒體檔位時，會再次向 LAS 服務端發送請求，并攜帶期望吐流的位置信息，服務端會結合請求的地址信息和位置信息，從對應的

62、媒體檔位的合適位置開始吐流。值得注意的是，媒體的傳輸方式是幀級流式傳輸，從而實現低延遲。同時，在傳輸過程中，只有在媒體檔位發生切換時，才需要發送新的請求，相對基于媒體塊的傳輸方式，可以大大降低請求次數，降低開銷。為了保證不同媒體檔位之間的無縫切換，LAS 要求轉碼時實現關鍵幀對齊，即不同檔位媒體流的 I 幀的 PTS 嚴格相等。如圖 9 所示：圖圖 9 9 LASLAS轉碼規范示意圖轉碼規范示意圖在發生檔位切換，需要發送新請求時，通過攜帶目標檔位的 URL 地址信息以及期望開始發送數據的位置信息（I 幀的 PTS），實現不同檔位的無縫切換。LAS支持的媒體切換方式包括 GOP 邊界切換和任意點

63、切換。在 GOP 邊界切換模式中，只有在一個 GOP 下載結束后，才會觸發多碼率自適應決策，并允許發送媒體請求，如圖 10 所示。這種方式的優點在于實現簡單，I 幀對齊天然的保證了無縫切換。其缺點在于自適應決策機會少，當網絡發生突變時，不夠靈活。35圖圖 1010 GOPGOP邊界決策示意圖邊界決策示意圖于是，LAS 還支持了任意點切換，如圖 11 所示。在任意點決策方案中，任意時刻均可觸發自適應算法并發送媒體檔位切換請求，易于應對網絡的的突變，但是實現復雜，需要考慮重復數據和跳幀的平衡問題，詳細細節可參考 LAS 標準文檔。圖圖 1111 任意點決策是示意圖任意點決策是示意圖以目前國內使用最

64、多的 HTTP-FLV 的 GOP 邊界決策為例，LAS 客戶端通過頭信息（flv_tag_header）來獲取當前正在傳輸的幀的類型。如果為 I 幀，則說明上一個 GOP 下載結束，并記錄其對應的 PTS 信息。此時觸發自適應策略做碼率自適應決策，決定下一個 GOP 的檔位。如果需要多碼率自適應算法決策需要切換檔位，則發送新的請求，并攜帶上述記錄的 PTS 信息即可。LAS 具有以下幾個特性：1)低延遲自適應：LAS 基于幀級流式傳輸，相比于傳統的 FLV 協議，可以極大的降低延遲。同時，LAS 支持多碼率自適應技術，依據實時網絡狀態動態在多檔之間實現無縫切換，平衡清晰度和流暢度；2)生態3

65、6鏈成熟易部署：LAS 從提出伊始，就得到國內各云廠商的大力支持。目前，阿里、騰訊、百度、金山、華為、網宿、白山等國內主流 CDN 廠商都支持 LAS，且服務行業內頭部 APP 企業近兩年，服務穩定，部署簡單；3）易擴展：在底層，LAS支持 HTTP、QUIC 等多種協議，未來將支持 WebRTC，進一步降低延遲，在上層，LAS1.0 版本基于 HTTP-FLV 實現直播拉流，與目前國內使用最廣泛的基于HTTP-FLV 的非多碼率架構兼容；4)開銷較小、傳輸效率高：LAS 沒有分片的概念，采用流式傳輸，直播過程中無需更新 MPD。請求數量少，開銷低。目前，LAS在行業內頭部 APP 直播已經全

66、量，每天使用量上億，穩定性和可靠性得到實際大規模應用的考驗。3.23.2 面向廣播組播分發面向廣播組播分發3.2.13.2.1 基于基于 FLUTEFLUTE 和和 ROUTEROUTE 的廣播分發的廣播分發FLUTE 是由 IETF(Internet Engineering Task Force)所制訂的通信協議，用于將文件由傳送端以多點傳送方式，通過 Internet 等 IP 鏈路傳送至多個接收端。FLUTE 構建在 UDP 協議之上，運行時不需要任何由接收端回傳至發送端的反饋信息。因此具備優秀的擴展性，對于接收端的數量幾乎沒有限制，無論是 10萬個或是 100 萬個接收端都可以正常工作

67、。FLUTE 被 DVB-H 和 3GPP MBMS 同時采納為單向傳輸協議。在兩個廣播標準中，FLUTE 既可以傳輸廣播的業務信息，也用來 ESG 等傳輸廣播輔助信息，應用非常廣泛。FLUTE 協議的主體部分是 ALC15協議，兩者的主要差別在于，ALC 是一套單向的“對象”多點傳送通信協議，而 FLUTE 則是一套單向的“文件”多點傳送通信協議。ALC 所傳送的對象本身，并不具任何的屬性。FLUTE 通信協議針對 ALC 的最主要擴充，就是將 ALC 傳送的對象視為文件，并為每個對象加上檔案所需要的屬性，例如文件名稱、檔案長度及檔案類型。為此，FLUTE 額外定義了一種叫 FDT(File

68、 Description Table，檔案描述表)的數據結構，里面記錄了 ALC 對象的檔案屬性。37ALC 是一種 IP 多播通信協議，可適用于 IPv4 與 IPv6，傳輸的基礎是 UDP協議，傳輸文件采用“盡力而為”方式。傳統的 IP 多播協議本身并沒有對話管理、擁塞控制、以及提供可靠傳輸的能力。ALC 通信協議建構于 IP 多播協議之上，并通過 LCT 協議解決了上述三個缺點，具備更好的可用性。LCT 是 ALC 通信協議的主體部分，負責提供前述的 進程管理的功能。擁塞控制是其中一個可選的組成組件，負責 ALC 在 Internet 上的擁塞控制。通常在移動單向廣播網并不會發生擁塞問題

69、，所以擁塞控制這個組件有時不會用到。ALC 的可靠性是通過 FEC 提供的前向糾錯功能保障的，應用層的 FEC 協議（如 Raptor）不需要來自接收端的回饋信息，通過預先提供冗余信息來彌補 ALC 封包在傳送時所發生的遺失或錯誤。ALC 的 FEC 組件相對獨立，目前比較常用的是 IETF 定義的Raptor17和 RaptorQ18。FLUTE 協議本是設計用于傳輸非實時文件的，隨著實時視頻流業務的增加，FLUTE 協議的缺點逐漸顯露，包括：-每次傳輸只能傳輸一個文件-不能區分傳輸文件的時延特性，無法針對實時視頻等文件優化時延-需要接收完整數據后才能播放在 ATSC 3.0 協議中，為了進

70、一步降低廣播傳輸時延，在 FLUTE 協議的基礎上設計了 ROUTE 協議。ROUTE 協議同時針對媒體傳輸協議 DASH 做了優化。-ROUTE 協議支持多路傳輸，多個 LCT 進程可以與一個修復進程綁定，以保證所有業務保持穩定的 QoS-ROUTE 協議支持亂序接收，以適應互聯網傳輸的時延抖動-ROUTE 協議支持不同業務封包的可見性，即在傳輸時可以根據被傳輸對象（實時媒體或者非實時文件）的時延特性優化傳輸的參數和設置。實時媒體數據可以在完成整個文件傳輸之前就開始播放。ROUTE 協議稍后被納入 DVB-Adaptive media streaming over IP multicast規

71、范中19。為了更好的將 ROUTE 協議推廣到其他支持 IP 廣播的協議中，IETF正在制定獨立的 ROUTE 協議20。383.2.23.2.2 基于基于 BIERBIER 的組播分發的組播分發BIER(Bit Index Explicit Replication)是一種簡化的組播報文轉發技術。它是一種基于位索引顯式復制的新型組播技術，提供一種無狀態的組播轉發機制。該技術不需要顯式建立組播分發樹，也不需要中間節點保存任何組播流狀態。它消除了復雜的組播協議、組播轉發表，無需維護任何組播流狀態，只需交換組播發送者和接收者的信息，BIER 網絡節點僅根據網絡拓撲進行轉發，就可實現高效的進行組播報文

72、的分發。IETF RFC8279 將 BIER 組播架構分為 Overlay、BIER、Underlay 三層。圖圖 1212 BIERBIER協議的三層架構示意協議的三層架構示意Overlay 層：業務層，負責組播業務控制面信息交互，BIER Egress 出口節點和 BIER Ingress 入口節點之間用戶組播的加入和離開、組播流進入和離開BIER 域的封裝和解封裝轉發等。BIER 層：Bier 轉發，主要完成 BIER 路由信息發布和洪泛以及本地 BIER 轉發表計算更新。Underlay 層為：Bier 鏈路建設，通過鏈路狀態協議如 ISIS、OSPF 等擴展 TLV屬性攜帶本節點的

73、 BIER 信息。BIER 在組播首節點（BIER Ingress）確定組播的接收者（BIER Egress）信息，中間節點不需要維護任何組播流轉發狀態信息（Group、Ingress、Egress），39BFIR 是最靠近組播源的 BIER 路由器。BIER 本地轉發表根據 IGP 的 BIER 鏈路狀態庫計算生成，BIER 鏈路狀態庫則由 IGP（ISIS/OSPF）協議的 BIER 擴展洪泛生成。大型 BIER 網絡可以根據網絡拓撲或者地理位置設計多個 SD（Sub Domain）簡化管理，如全國性的運營商設立如東部大區 SD 網絡、西部大區 SD 網絡、南部大區 SD 網絡、北部大區

74、SD 網絡等。每個 SD 內的 BSL 和 BFR-id 是獨立的，互不影響。Bier 組播網絡中沒有維護組播狀態，無需組播控制協議運行，中間節點看不到任何組播流，也無需保存任何組播流相關信息，與用戶及業務量的增減無關，所以與業務完全解耦，而傳統的 PIM 組播技術需要保存組播狀態及組播樹的維護，對于組播成員的加入、退出都需要進行管理，需要業務參與流程的管控。表表 5 5 BierBier與傳統與傳統PIMPIM組播的比對組播的比對BIERBIER 組播組播傳統傳統 PIMPIM 組播組播網業耦合度網絡服務層次化，組播業務與組播轉發完全解耦，可以任意形式搭配網絡服務扁平化，組播業務與組播傳輸緊

75、耦合路徑收斂快：BIER 網絡在路由方面，只需要單播路由協議支撐，繼承單播的快速重路由（fastreroute，FRR）等路徑保護技術?；诼酚墒諗繒r，因為不需要組播路由收斂過程，單播路由收斂完成，就代表 BIER 完成收斂，比傳統組播收斂快。慢：所有節點都需要維護組播樹狀態，網絡拓撲變化時都需要先做單播收斂，當單播收斂后，組播協議再為每個組播樹重新收斂處理，從而收斂到新的組播樹，時間較長，收斂速度慢.可維護性中間節點無須維護多播狀態及業務相關轉發表項，大大減少了需要支持大量的組播協議簇，運營運維復雜40業務轉發所需的復雜協議，運營運維方便可擴展性BIER 網絡不需要組播路由，也不需要維護業務

76、相關的路由表及業務狀態，轉發表項只和拓撲相關，表項非常小。增刪中間轉發節點，不需要組播業務相關的配置，相當于即插即用，擴展方便，業務靈活。所有節點都需要維護組播路由，任何一次增刪節點都需要更新組播樹，擴展性差。計費管控易管控：BIER在 BFIR上可以完全控制業務流投遞的接收端（BFER），這樣基于一個控制點，就可以控制業務的流向和接收者，擺脫了傳統組播控制困難、難以收費的困境。難管控：缺乏靈活的管控手段，難以進行計費管控移動性支持靈活快速：當組播源移動時，只要由控制器切換組播源關聯的BFIR 就能解決問題，避免傳統組播樹重建過程或者流量繞行的問題。當接收端移動時，只需要在 BFIR修改位串，

77、就可以正確投遞組播業務源可能在不斷在變化，切換速度頻繁，每次變更都需要重建組播樹，無法滿足移動終端的快速切換需要，所以對移動 IP 中的應用支持困難。413.33.3 單點分發單點分發 HTTP1/HTTP2/HTTP3HTTP1/HTTP2/HTTP3歷史上第一個有記載的 HTTP 版本是 0.9（The HTTP Protocol AsImplemented In W3），它誕生在 1991 年。這個協議目前已經過時，其最早被設計用于從服務器獲 取 HTML（HyperText Markup Language）文檔。圖圖 1313 HTTPHTTP協議發展示意協議發展示意3.3.13.3.

78、1 HTTP/1HTTP/1 協議協議1996 年，一個更加完整、更加接近我 們目前對 HTTP 認知的版本，HTTP/1.0（Hypertext Transfer Protocol HTTP/1.0）發布了。這個版本中已經包含了很多我們如今都比較熟悉的概念：HTTP 響應狀態碼、HTTP 頭和 HTTP 方法。隨著互聯網的迅速發展，人們對 HTTP 協議有了更高的要求。1999 年，現在最常見的 HTTP 1.1（Hypertext Transfer Protocol HTTP/1.1）版本誕生了。從此之后，這個 HTTP 協議一直服務至今。并且，在后來的十多年里，這個協議還不斷更新和細化，

79、最終在 2014 年形成了 6 個 RFC（RFC7230-7235）。相比于 HTTP/1.0，HTTP/1.1 支持長連接（或持久連接），亦即在一個 TCP 連接上可以 傳送多個 HTTP 請求和響應，減少了每次建立和關閉連接的消耗和延遲。從而在需要 一次請求多個文件/圖片等資源的情況下，通過一個 HTTP 連接來完成傳輸，節約資源加載延遲，提高網絡帶寬利用率。同時，HTTP/1.1 還增加了42更多的請求頭和響應頭來 改進和擴充 HTTP/1.0 的功能，使得用戶站點可以支持更多的功能，比如內容緩存，帶 寬優化，消息傳遞，錯誤提示，內容協商等。3.3.23.3.2 HTTP/2HTTP/

80、2 協議協議2015 年，HTTP/2.0（RFC 7540-Hypertext Transfer Protocol Version 2（HTTP/2）誕生。HTTP/2.0 支持很多新的特性，主要的幾個特性如下：1.新的二進制格式（Binary Format），HTTP/1.x 的解析是基于文本?；谖谋緟f議的格式解析存在天然的缺陷，文 本的表現形式有多樣性，要做到健壯性的話，考慮的場景必然很多。但是，二進制則 不同，該方式只看 0 和 1 的組合?；谶@種考慮 HTTP/2.0 的協議解析決定采用二進制 格式，實現更加方便，而且健壯。2.多路復用（Multiplexing），即連接共享，即

81、每一個 HTTP Request 都是是用作連接共享機制的。一個 HTTP Request 對應一 ID，這樣一個連接上可以有多個 HTTP Request，每個連接的 HTTP Request 可以隨機的混雜在一起，接收方可以根據 HTTP Request 的 ID 將 HTTP Request 再歸屬到各自不同的服務端請求里面。多路復用原理如圖所示，在單條 TCP 連接上可以存在多個 HTTP Response，不同的 HTTP Response 對應 于不同的 HTTP Request。3.頭部壓縮（Header Compression），在介紹 HTTP/1.x 時，我們知道在HTTP

82、/1.x 的“頭”中帶有大量信息，包括各種狀態響應信息等，而且每次建立 HTTP Request/HTTP Response 都要重復發送 HTTP“頭”，HTTP/2.0 使用 Encoder 來減少需要傳輸的 HTTP“頭”大小，通訊雙方只需要各自緩存一份 Header Fields 表，這樣既避免了重復 HTTP“頭”的傳輸，又減小了需要傳輸數據的大小。4.服務端推送（Server Push），和 Google SPDY 一樣，HTTP/2.0 也具有 ServerPush 功能。所謂 Server Push 指的是 HTTP/2.0 服務器在還沒有收到客戶端發送的 HTTP Reque

83、st 時，HTTP/2.0 服務器就可以把各種還未被請求的資源文件推送到客戶端。43圖圖 1414 HTTPHTTP/2/2服務端推動服務端推動目前，有大多數網站已經啟用 HTTP/2.0，例如 YouTube，淘寶網等網站。此外，Nginx 與 Apache 也已經支持 HTTP/2.0 及其相關特性。下圖表示了 HTTP/1.x、HTTP/2 多路復用與 HTTP/2 Server Push 在網頁中請求文件的示意圖，在 HTTP/1.x 中，客戶端需要請求網站首頁 index.html，格式文件 style.css 與圖片 home.jpg 等資源時，需要一個一個 HTTP Reques

84、t發送，在一個 HTTP Request 發送之后，必須等到對應請求的 HTTP Response 到達客戶端之后，才能繼續發 送下一個 HTTP Request。HTTP/1.1 雖然支持 TCP長連接，但是其還存在相同的問題，并且一般而言，很多瀏覽器可支持的長連接數目有限，在資源很多的情況下，同樣存 在低效的網絡帶寬利用情況。而 HTTP/2的多路復用則可以通過 Stream 機制，該機制 是一種抽象概念，允許多個 HTTPRequest 與多個 HTTP Response 在同一個 TCP 連接上 存在，從一定程度上提高了鏈路帶寬的利用率。但是即使如此，客戶端與服務端由于 每次發起 HT

85、TPRequest，等待 HTTP Response 都存在一定的延遲，從而浪費了有限的鏈路帶寬資源。HTTP/2 的 Server Push 則允許服務端主動推送一系列資源文件，而不需要客戶端一個一個發起 HTTP Request，從而大大提升了網絡請求與響應的性能?？梢钥闯龌?HTTP/2 Server Push 來請求網站首頁 index.html，格式文件style.css 與圖片 home.jpg 三個資源文件所需要的時間開銷最短，延遲最低，這也意味著用戶會 得到更好的網頁瀏覽體驗。44圖圖 1515 HTTPHTTP/1.x,/1.x,HTTPHTTP/2.0/2.0無無Serv

86、erServer PushPush和和HTTPHTTP/2.0/2.0結合結合ServerServer PushPush流程比流程比較較3.3.33.3.3 HTTP/3HTTP/3 協議協議雖然 HTTP/2 解決了很多之前舊版本的問題，但是，由于其底層還是 TCP協議，因此，還是存在一些問題。HTTP/2 的缺點主要有以下幾點：1.TCP 與 TCP+TLS 建立連接的高延時問題（一個典型的獲取資源的等待延遲可能達到 4 個 RTT）2.TCP 隊頭阻塞問題（TCP 多路復用帶來的弊端）Google 在推 SPDY 的時候就已經意識到了這些問題，2012 年便實現部署了一個基于 UDP 協

87、議的“QUIC”協議，讓 HTTP 跑在 QUIC 上而不是 TCP 上。2018年，IETF 相關工作組提出將“HTTP over QUIC”更名為 HTTP/3，這進一步推動了“HTTP over QUIC”逐漸演變為 HTTP 協議的下一個版本。目前，HTTP/3 仍然處于草案狀態。HTTP/3 在 HTTP/2 的基礎上又實現了質的飛躍，一定程度上解決了“建連高延遲”與“隊頭阻塞”問題。45圖圖 1616 HTTP/HTTP/3 3和前代和前代HTTPHTTP協議比較協議比較QUIC 雖然基于 UDP，但是在原本的基礎上新增了很多功能：1.實現了類似 TCP 的流量控制、傳輸可靠性的功

88、能2.實現了快速握手功能3.集成了 TLS 加密功能4.多路復用，徹底解決 TCP 中隊頭阻塞的問題HTTP/3 有以下優點：1.使用 stream 擴展了多路復用特性。在 HTTP3 模式下，一般傳輸多少個文件就會產生對應數量的 stream。當這些文件中的其中一個發生丟包時，只需要重傳丟包文件的對應 stream 即可2.通過 UDP 建立，在用戶空間保證傳輸的可靠性，UDP 之上的 QUIC 協議提高了連接建立的速度，降低了延遲3.引入 Connection ID，使得 HTTP3 支持連接遷移以及 NAT 的重綁定4.含有一個包括驗證、加密、數據及負載的 TLS 安全機制5.將擁塞控制

89、移出了內核，通過用戶空間來實現，不再需要等待內核更新可以實現很方便的進行擁塞控制算法快速迭代6.使用 QPACK 壓縮方案，優化了對亂序發送的支持，也優化了壓縮率463.43.4 VRVR 內容的分發內容的分發近年來，以 VR、AR 為代表的虛擬和增強現實終端成為行業的熱點。在行業中，這兩類終端被統稱為 XR（eXtended Reality）。有別于傳統的智能手機和平板電腦，XR 終端需要集中呈現使用者視角內的圖像，而虛化視角邊緣的圖像。同時，需要及時根據使用者的頭部移動方向和角度，調整投射的圖像。在 XR 類業務中，VR 類業務是通過封閉式眼鏡提供獨立視頻，而 AR 業務則是結合周圍環境提

90、供交互類視頻。本章重點介紹 VR 類業務的呈現和傳輸協議，AR類業務呈現方式類似，但需要增加與周圍環境的交互，對通信更加依賴，對交互時延也更加敏感。3.4.13.4.1 VRVR 媒體服務總體架構媒體服務總體架構虛擬現實指通過展現 360 度的視頻為終端用戶提供沉浸式體驗的技術，支持全景視頻內容，也稱 360 度全景視頻或沉浸式視頻，支持用戶交互性地切換觀看視角，終端能夠根據用戶的觀看視角動態渲染圖像、視頻及其相關聯的音頻。如圖 17 所示，VR 媒體內容由源站提供，在現實場景中采集到的視頻等媒體數據經過 VR 源站拼接服務器進行拼接、投影、旋轉等，成為完整視頻畫面，繼而經過編碼器編碼得到 V

91、R 媒體內容源，利用封裝服務器完成系統層封裝；用戶通過 VR 終端請求 VR 媒體服務，其中傳輸協議訪問模塊完成 VR 媒體索引文件的解析，終端根據傳感器獲取到的視窗元數據（如用戶頭動信息、觀看方向等）請求相應的內容分片，并完成解封裝、解碼，最終根據視窗元數據完成視頻畫面的渲染和音頻等其他媒體資源的播放。47圖圖 1717 VRVR媒體內容傳輸流程媒體內容傳輸流程3.4.23.4.2 VRVR 視頻傳輸模式視頻傳輸模式VR 視頻傳輸模式包括：基于全景傳輸的虛擬現實基本傳輸模式，即視窗獨立傳輸模式，以及基于主視場或者輔助視場的多碼流切換的虛擬現實視點自適應傳輸模式，即視窗依賴傳輸模式。視窗獨立傳

92、輸模式指將 360全方向視頻以同等質量、完整地發送給用戶?？梢员ＷC映射內容完整保留了原始球面的所有內容，保留信息量最大?？蛻舳讼蚍掌髡埱螳@取無差別的全景視頻文件，當用戶觀看方向發生變化時，所有的處理都在終端完成。在沉浸媒體的消費過程中，由于人眼視覺范圍有限，用戶在某一時刻只能觀看局部的內容。按需傳輸，利用人眼視覺系統的局限性，實現在不降低視覺體驗的前提下對數據量進行減少，依賴用戶當前的視野對傳輸內容進行自適應，按需下載視頻內容，即視窗依賴傳輸模式，也稱之為 VR FOV 傳輸。視窗依賴傳輸模式可以分為兩類：基于區域封裝的視窗依賴傳輸和基于分塊編碼的視窗依賴傳輸。對于基于區域封裝的視窗依賴傳輸

93、模式，全方向原始球面視頻內容采用非均勻映射處理。其在對球面內容進行采樣時，令球面上的像素點有不同的權重，使48得關鍵視頻內容得到保留，而不重要的區域被下采樣，僅保留少部分關鍵信息。非均勻映射方法用于傳輸質量不均勻的 360全景視頻，用戶視窗范圍內是高分辨率，其他區域是低分辨率，從而減少整體碼率。分塊傳輸技術將 360全方向視頻按照空間劃分為若干個子視頻塊，客戶端可以根據網絡狀況和用戶頭部運動有針對性的向服務器端請求視頻片段。分塊傳輸僅傳一部分內容，或將當前視窗的高質量視頻內容以及低質量全景視頻內容混合傳輸，減少了傳輸數據量，可以自由地選擇各個分塊的質量。3.4.33.4.3 VRVR 媒體封裝

94、及傳輸格式媒體封裝及傳輸格式VR 視頻封裝格式可參考 MPEG 制定的 OMAF（Omnidirectional MediA Format）全景視頻封裝格式，以及表 6 所示的視頻基本配置規范及更高配置規范。具體內容參見22。表表 6 6 VRVR視頻視頻基本配置基本配置規范規范媒體規范編碼格式視頻編碼規范Level數據盒封裝標識類別基于HEVC編碼格式的視窗獨立視頻封裝HEVCMain105.1podv、erpvhevi基于HEVC編碼格式的視窗依賴視頻封裝HEVCMain105.1podv、erpv與ercm至少一個hevd基于AVC編碼格式的視窗依賴視頻封裝AVCProgressiveH

95、igh5.1podv、erpv與ercm至少一個avde虛擬現實音頻可參考表 7 基本配置規范及更高配置規范。具體內容參見22。表表 7 7 VRVR音頻音頻基本配置基本配置規范規范媒體規范編碼格式音頻編碼規范Level最高采樣率3D 元數據類別OMAF 3D 音頻基準MPEG-HLowComplexit1,2 或48 kHz編碼中已包oabl49規范Audioy3含OMAF 2D 音頻規范AACHE-AACv2448 kHz無3D元數據oa2dVR媒體傳輸協議要求和智能手機類似，也是以DASH和HLS為主：DASH：VR媒體服務可以基于DASH傳輸協議以及針對VR媒體服務的信令擴展，具體配置

96、內容參見22附錄 B。HLS：VR 媒體服務可以基于 HLS 傳輸協議以及針對 VR 媒體服務的信令擴展，具體配置內容可參考23。504.4.小結和音視頻傳輸趨勢預測小結和音視頻傳輸趨勢預測視頻類應用是被業界廣泛認可的 5G 發展方向之一。隨著移動互聯網的發展，以智能手機為代表的移動終端成為主流的視頻接收端。特別是近年來，中高端智能手機已經普遍具備 4K 和 HDR 視頻處理能力，有 AI 加持的 GPU 甚至超過了電視等大屏顯示器的處理能力。為了提升用戶體驗，主流的視頻 APP 提供商陸續推出4K 內容，這也驅動了運營商加速部署 5G 網絡以提供相應的流量?？梢灶A期，隨著運營商 5G 網絡的

97、部署和升級，用戶將會獲得更大的體驗帶寬，屆時 APP 服務商也會進一步的提高幀率、HDR 量化比特數等關鍵指標以提升用戶觀看體驗。在上行方向，5G 將速率提升了兩個數量級，目前上行峰值速率已經接近2Gbps。這極大的擴展了 5G 上行業務的范疇，背包業務從 20Mbps 以下的超高壓縮率、低畫質內容擴展到 80Mbps 以上的高畫質內容。同時，5G 超大上行鏈路幫助電視制作域從有線走向無線。利用 600Mbps 的大帶寬，5G 可以把 4K 編碼器輸出的淺壓縮信號在 50ms 內傳送回節目制作中心，屏幕到屏幕的時延可以控制在80-100ms 以內。這是電視制作域在從基帶信號進入信號全 IP 化

98、之后的又一次革命性變化，信號傳輸從光纖、網線的有線連接進入全無線連接時代。繼光纖取代SDI 線纜后，演播室和拍攝現場的線路部署被進一步簡化，現場部署的復雜度被極大降低，“剪尾巴”后的攝像機可以自由移動，不再被限定到固定拍攝機位。5G 在上行和下行兩個方向提供了超大的傳輸速率，為了更好的支持制作域的上行傳輸和傳輸域的下行分發業務，可能還需在傳輸協議層面加以適配。本文從制作域和傳輸域分別總結了當前主流的傳輸協議，并分別加以分析。在視頻制作域，JPEG-XS 和 NDI 等協議目前主要通過光纖和千兆、萬兆以太網等固定鏈路傳輸。5G 提供了可以媲美千兆以太網的傳輸速率，目前已經有一些利用 5G 傳輸

99、JPEG-XS 和 NDI 等淺壓縮信號的實驗，預計在不久的未來就會出現早期的商用方案。視頻背包類業務目前主要采用 HEVC 或 J2K 等深壓縮方案結合一些基于 ARQ（SRT、ZIXI 以及 RIST）或傳統的 RTP、RTMP 的方案進行傳輸，預計未來會根據場景考慮采用不同的傳輸方式，例如在專業視頻制作使用高可靠的 SRT、ZIXI 或 RIST 協議、在直播或會議類應用中使用交互性好的 WebRTC 協議、在視頻監控類應用中使用的 GB28181 協議等?，F階段在遠程視頻傳輸協議的選擇51上，SRT、ZIXI 以及新推出的 RIST 協議各有所長，如果需要立刻部署的話，使用 SRT 或

100、 ZIXI 會是一個更合適的方案，因為其公網傳輸的優異性能以及成熟度已經被業界證明；而如果長遠規劃的話，RIST 會是更面向未來的選擇。在視頻傳輸域，底層傳輸協議需要智能手機從操作系統層提供良好的支持，HLS 和 DASH 是兩大主流自適應碼率傳輸協議，分別在 IOS 和 Android 平臺占據主導，具有最佳的生態支持。同時，業界的各 OTT 大廠通過自身 APP 強大的滲透率也在基于自身業務的需要、分別演進適合業務發展的協議。這類演進主要是從CDN 和智能手機支持的成熟協議出發，加入適合業務類型的技術改進，解決自身業務發展遇到的“痛點”。本文中 LAS 就是根據目前被廣泛使用 FLV 協議

101、設計了多碼率自適應傳輸，優化了時延特性。表 8 5G 場景下的視頻傳輸協議應用場景傳輸協議編碼格式優點缺點專業視頻制作MPEG-TS(UDP/RTP)AVC/HEVC/VVCJ2K/JPEG-XS成熟度高、生態完善、適用范圍廣、開放協議陳舊、對網絡要求高SMPTE 2110未壓縮/JPEG-XS業界標準、面向未來、開放尚未大規模部署、對網絡要求極高、部署成本高NDIAVC/HEVC成熟度高、生態完善、產品化效率高、部署效率高單一廠商(Newtek)壟斷風險、對網絡要求高5G回傳或公網傳輸RTMPAVC(HEVC需擴展)成熟度高、生態完善延時大、公網傳輸能力不足、協議陳舊、擴展能力弱SRTANY

102、成熟度高、生態完善、延時低、開源、大量成功案例單一廠商主導技術發展、存在壟斷風險；不同廠家實現存在互通問題ZIXIANY成熟度高、延時低、糾錯能力強完全私有RISTANY業界標準、開放、生態完善、兼容RTP及實現程度及成熟度低52SMPTE-2022公網分發DASHAVC/HEVC/VVC/AV1業界標準、生態完善、開放、基于HTTP-ABR、MPEG陣營延時大、低延時方案全產業鏈支持尚需時間；LL-DASH終端支持問題需解決HLSAVC/HEVC成熟度高、協議簡單、基于HTTP-ABR、Apple陣營延時大、低延時方案全產業鏈LL-HLS支持尚需時間；Apple私有協議LASAVC/HEVC

103、成本低、延時低、基于HTTP-ABR、生態完善國外產業鏈缺乏支持，推廣可能會出現問題直播帶貨或視頻會議WEBRTCAVC/HEVC/VP8/VP9/AV1業界標準、生態完善、開源、瀏覽器支持、極延時低、可變碼率及可變質量、Google陣營擴展難度大、CDN支持復雜度高視頻監控GB28181AVC/HEVCN/A暫無對比隨著國內基于互聯網的直播類業務迅速發展，廣播和組播這種傳統的業務類型得到了重視。本文介紹了移動網絡廣播分發協議 FLUTE/ROUTE，FLUTE 協議被3GPP eMBMS、DVB 等移動廣播系統廣泛采用，ROUTE 是 FLUTE 協議的優化版本，被 ATSC 3.0、DVB

104、 協議采納。BIER 協議是一種簡化的組播報文轉發技術，未來在運營商網絡中有一定的應用前景。目前直播類節目使用最為廣泛的還是基于IP 的廣播技術，在傳輸時實際使用 HTTP 單播發送到用戶。為了優化時延和可靠性，目前 UDP 和 TCP/IP 類的協議互相吸納了彼此的優點，產生了一些類似 QUIC的融合類協議。作為近年來廣受關注的終端類型，本文還簡述了針對 VR 的媒體服務架構、傳輸模式、封裝和傳輸格式等信息，以期能夠為廣受關注的 VR 業務提供參考。但我們也看到目前 XR 類業務還有 AR、MR 等業務仍需研究。53參考文獻參考文獻1 中央廣播電視總臺，8K超高清電視節目制播技術要求（暫行）

105、，2021年1月2 中央廣播電視總臺，4K 超高清電視技術應用實施指南（2018 版），20183 SMPTE ST 2022，Moving Serial Interfaces(ASI&SDI)to IP,August 20174 SMPTE ST 2110，Structuring the Future of Broadcasting,Nov.20175 Haivision,“BROADCAST IP TRANSFORMATION REPORT 2020-The State ofIP and CloudAdoption in the Broadcast Industry”,20206 Haiv

106、ision,“SRT Protocol technical overview”,October，20187 Web Real-Time Communications(WebRTC)transforms the communicationslandscape;becomes a World Wide Web Consortium(W3C)Recommendation andmultipleInternetEngineeringTaskForce(IETF)standards,https:/www.w3.org/2021/01/pressrelease-webrtc-rec.html.en8 We

107、bRTC transforms the communications landscape as it becomes a W3CRecommendation and IETF standards，https:/www.ietf.org/blog/webrtc-standardized/9 ZiXi，Broadcaster User Guide,V1.9，http:/ Group Chair,RIST;What is the Future;11GB/T 28181-2016 公共安全視頻監控聯網系統信息傳輸、交換、控制技術要求,2016年7月12日12IETF,RFC 3551,RTP Prof

108、ile for Audio and Video Conferences with MinimalControl,July 200313IETF,RFC 3926-File delivery over Unidirectional Transport，Oct.200454143GPP,TS26.346,Multimedia Broadcast/Multicast Service(MBMS);Protocolsand codecs,v16.4.1,Mar.202015IETF,RFC 3450，ALC protocol instantiation,Dec.200216IETF,RFC 3451,L

109、CT building block,Dec.200217IETF RFC 5053,Raptor FEC scheme,Oct.200718IETF RFC 6330,RaptorQ FEC scheme,Aug.201119ETSI TS 103 769,DVBAdaptive media streaming over IP multicast,Nov.202020IETF ROUTE draft,https:/datatracker.ietf.org/doc/draft-zia-route/21IETF RFC 8279,Multicast Using Bit Index Explicit

110、 Replication(BIER),Nov.201722ISO/IEC 23090-2,Omnidirectional Media Format,201923AVS，信息技術虛擬現實內容高效編碼 第1部分：系統24BIER組播技術發展白皮書https:/ 3941-2021 內容分發網絡技術要求VR音視頻服務https:/ 23090-2 Omnidirectional media formathttps:/mpeg.chiariglione.org/standards/mpeg-i/omnidirectional-media-format55致謝致謝本報告在撰寫過程中收到來自以下高校，研究

111、機構和公司專家的大力支持和貢獻，在此報告完成之際，僅表達誠摯的感謝。4K Garden-4K 花園于路（Lu Yu）ABS-國家廣播電視總局廣播電視科學研究院張宇(Yu Zhang)Ateme陳朋奕（Ben Chen）Beijing Radio and Television Station-北京電視臺程宏（Hong Cheng）B&M Modern Media Inc.-廣州波視信息科技股份有限公司王 兆 春(VioletWang)China Unicom-中國聯合網絡通信集團有限公司黃蓉（Rong Huang）Communication University of China-中國傳媒大學林

112、濤（Tao Lin)Communication University of Shanxi-山西傳媒學院任 石 青（ShiqingRen）Haivision李翠琳（Cuilin Li）Hangzhou Arcvideo Technology Co.,Ltd.-杭州當虹科技股份有限公司陳勇（Yong Chen）JiangSu Broadcasting Cable Information NetworkCorp.Ltd.(JSCN)-江蘇有線李鑫(Li Xin)Kwai 快手周超（Chao Zhou）56Qualcomm-高通曹 一 卿(YiqingCao)杜志敏（Zhimin Du）李儼（Yan Li）Samsung 三星吳越（Yue Wu）Syntronic-新拓尼克（北京）科技研發中心有限公司王 瑞 明（RuimingWang）ZTE-中興劉 耀 東（YaodongLiu）陶長標（ChangbiaoTao）白雅賢（Yaxian Bai）