來源：Video Breakthroughs
原標題：Core Technologies for Streaming Workflows, in 2021 and beyond
原作者：Nicolas Weil
原文鏈接：https://blog.eltrovemo.com/1912/core-technologies-for-streaming-workflows-in-2021-and-beyond/
翻譯整理：徐鋆
摘要：本文作者以行業內資深大佬的眼光，首先概述了當下 OTT 領域的關鍵技術，然后展望了未來有前景的新技術，內容豐富，涵蓋廣泛。原文中有大量推薦閱讀及參考鏈接，感興趣的讀者請進原文觀看。

目錄

• 目前的核心技術

  • CMAF/CBCS/IMSC 浪潮

  • QUIC 的普遍性？

  • 編解碼器演進

  • 低延遲終于到來

  • CPIX - 統治密鑰交換業務

  • MSE 和 EME - 視頻播放器的重要推動因素

• 未來的核心技術

  • 轉播技術

  • ABR 轉碼技術

  • A/B 水印

  • DASH 清單文件優化

  • 廣告插入

  • 低延遲

  • 源攝取和同步元數據

  • QoE / 多-CDN

  • 可伸縮性

  • 全都放到一起

自從我在這個博客上發表上一篇文章以來，已經快五年了——距離第一篇文章已經十年了——時間過得很快，流媒體技術發展也是如此。在 2016 年，CMAF 標準化剛剛開始，承載著簡化工作流程和提高 CDN 緩存效率的希望。CBCS 加密方案的支持被希望遠遠超出蘋果的生態系統，而 IMSC 也準備成為主導的字幕標準。現在我們可以看看其中有多少真的發生了，還有哪些技術確實作為流媒體工作流程的礎出現了，以及哪些可能是未來五年的重要技術。

1目前的核心技術

讓我們從過去五年中被認為在 OTT 中具有重要作用的技術開始......

CMAF/CBCS/IMSC 浪潮

自 2016 年以來，CMAF 已經成為事實上的媒體容器格式。所有的視頻標準制定組織（Standards Developing Organizations，SDOs），如 DVB、ATSC、DASH-IF 或 3GPP，都采用了這個 MPEG 標準作為自己標準的基線技術。消費者技術協會（Consumer Technology Association）已經啟動了其網絡應用視頻生態系統（Web Application Video Ecosystem，WAVE）項目，以進一步推動內容生產商和媒體播放器開發商利用 CMAF 的互操作性，以及 CMAF 行業論壇，以促進 CMAF 在整個視頻生態系統中的使用。CTA-WAVE 最近發布了 DASH-HLS 互操作性規范，該規范描述了 DASH 和 HLS 應如何利用 CMAF 內容，并對 DASH 和 HLS 清單文件之間的映射進行了規范。而 MPEG 已經為 DASH 定義了一個 CMAF 配置文件（核心 DASH 規范第五版的一部分，處于國際標準最終草案 FDIS 階段）。所以 CMAF 現在無處不在，沒有什么事情是不兼容 CMAF 的。所有現代視頻播放器都支持 CMAF 媒體片段，所以 TS 片段的使用范圍現在僅限于 iOS 10 之前的設備和其他無法更新的傳統硬件播放器——由于硬件更新周期，這個集合明顯在縮小。與 LL-DASH 播放器不同，蘋果 LL-HLS 播放器并不利用 CMAF 片段，因為這些平臺上的啟發式傳輸依賴于全線速傳輸，但至少它們與之兼容，這使得 LL-HLS 和 LL-DASH 清單文件之間共享一套媒體片段成為可能。

考慮的部署架構（CTA WAVE）

CMAF 的成功也是以 CBCS 接管 CTR 加密方案為條件的，因為這是在同一組片段中攜帶多個 DRM 的初步要求，與 CTR 和 CBCS 模式的兩組片段相比，CDN 以最佳的緩存效率交付。我們需要承認，這個愿景在蘋果生態系統之外只實現了一半，因為只有 2020 年及以后的非蘋果設備在硬件上確實支持 CBCS，這限制了對 1080p 分辨率及以上的支持。考慮到標準的硬件更新周期，這導致我們在 2025 年才能看到 CBCS 被普遍支持。即使在像瀏覽器這樣的環境中——其中 CBCS 現在已經成為有競爭力的特性——在它與所有 DRM 和 Clearkey 加密表現良好之前，仍然有很多互操作相關的工作需要去做。

在 CMAF 的系列承諾中，還有一個方面是伴隨著 IMSC1 在文本和圖像 profile 的出現（見 CTA 規范的 4.4.1 節），在所有設備上使用單一的字幕 TML 格式。雖然蘋果在 2017 年的 pantos-hls-rfc8216bis-00 規范草案 中引入了對 IMSC1 文本 profile 的支持，但 HLS 仍然沒有正式支持圖像 profile，WebVTT 在 HLS 領域的統治地位還沒有真正受到挑戰，使得字幕生態系統出現斷裂。這可能與以下事實有關：即使是支持 IMSC1 文本 profile 這樣一個廣泛的規范也是具有挑戰性的，需要像 EBU-TT-D 或最近的 Netflix IMSC 1.1 文本 profile 一樣的配置文件。長話短說：我們需要更多的時間來看到 TTML 在業界的融合。

QUIC 的普遍性？

自 2013 年出現以來，QUIC 走過了漫長的歷程，在 2015 年作為標準草案與 HTTP/2 非正式合作，并在 2021 年晉升為 RFC 和 HTTP/3 的官方基礎（見 Akamai 一篇關于這段歷史的精彩博文）。

HTTP 和 QUIC 工作組范圍（Akamai）

通過多路連接和 UDP 來提高帶寬效率，HTTP 傳輸的效率已經達到了前所未有的水平。在最初考慮使用 HTTP/2 推送作為 LL-HLS 機制后，蘋果退縮了，因為他們意識到這與廣告插入不兼容（出于 HTTP/2 的安全原因，所有媒體片段和廣告片段都需要一個單一的來源），但使用 HTTP/2 仍然是 LL-HLS 合規性的一個強制性部分。而 LL-HLS 很可能會在不遠的將來被更新，正式支持 HTTP/3。最初在 DASH 領域有一些擔憂，因為 LL-DASH 依賴于 HTTP/1.1 分塊傳輸編碼，這不是一個跨越 HTTP/3 的概念（其中使用了 DATA 幀）。這實際上是工作得很好的，CDN 可以在原始層將 HTTP/1.1+CTE 透明地轉換為 HTTP/3，并在邊緣層向客戶提供 DATA 幀。憑借其效率和媒體客戶端與 CDN 之間的高度互操作性，QUIC 顯然是 HTTP 傳輸方面的主導技術，現在和未來五年內都是如此。

編解碼器演進

就視頻編解碼器而言，現在和五年前有什么區別？實際上，差別不大。AVC 仍然是占主導地位的編解碼器，而 HEVC 的采用仍然滯后，因為許可情況分散。HEVC 解碼廣泛存在于解碼芯片中，但為了避免授權費用，往往不被激活，所以它的采用一直在緩慢增加，主要是由 4K 內容分發驅動，因為 AVC 不是一個可持續的選擇，而且蘋果設備很早就提供硬件解碼能力。在瀏覽器上，Safari 以外的 HEVC 支持仍然是例外，而不是常規，即使這可以通過底層硬件支持來實現。但這也是政治因素的影響，例如，谷歌更傾向于推動 AV1 而不是 HEVC，因為這是一個由他們主要控制的編解碼器。與 HEVC 不同，AV1 自 2018 年起進入 Chrome/Firefox 等瀏覽器，并作為微軟商店的免費擴展進入 Windows 10（而 HEVC 擴展是 0.99 美元的），使得 Edge 瀏覽器可以使用 AV1。2020 年，AV1 支持開始出現在電視上，有 LG、三星和索尼的機型，在移動領域有安卓 10+ 的支持。但蘋果平臺和高通驍龍 888 等流行的移動芯片組缺乏對 AV1 的原生支持，不知為何，AV1 一直處于挑戰者的地位。廣播標準生態系統開始認真看待它，DVB 將 AV1 列入下一代編解碼器的支持名單，同時還有 AVS3（針對中國市場）和 VVC（又稱 H.266）。雖然 AV1 有一個 ISO-BMFF綁定，這使得它可以在 HLS 或 DASH 背景下使用，但 HDR 支持仍然是一個新興的 AV1 功能，只有一頁說明可用于 HDR10+，而杜比視界支持的早期跡象在這里和那里可見。

在音頻編解碼方面，很難說在過去五年中發生了什么重大變化。AAC 變體仍然是主流選擇，當有多聲道音源可供轉碼時，一些 AC-3 變體會使流媒體變得更加精彩。沒有任何音頻革命真正被電視化。

低延遲終于到來

基本的 LL-DASH 運作流（DASH-IF）

自 2017 年 DASH-IF/DVB 第一次迭代以來，LL-DASH，即 MPEG-DASH 的低延遲 profile，一直走得很坎坷。LL-DASH 花了三年時間在規范方面成熟，結果是 2020 年 2 月 DVB-DASH v.1.3.1 規范的 10.20 節和 2020 年 3 月 DASH-IF 的 DASH IOP 擴展的低延遲模式。像重新同步點這樣的必要創新需要對 MPEG 的核心 DASH 規范進行多次補充，第五版有望成為該領域的最后一次迭代。DASH-IF 在 2019 年贊助了 FFmpeg 中 LL-DASH 支持的實施，所以現在有一個堅實的開源基礎，用于低延遲 DASH 編碼/打包，可以與各種發端解決方案相結合，如 Streamline、originjs 或 Nginx 的 dash-server。但盡管如此密集的 2019/2020 年標準化和開源工作，LL-DASH 仍然是一個相對保密的技術，很少有大規模的生產部署。DASH 玩家的生態系統仍然是分散的，對低延遲的支持就像對其他基礎技術，如多周期（實現服務器端廣告插入）。

通用的低延遲工作流（Akamai）

這就是 2019 年 LL-HLS 的引入對行業的激勵作用，蘋果突然打開了看到 20 億臺 iOS 14 設備兼容 LL-HLS 的視角。開源視頻社區緊跟這一趨勢，廢除了 LHLS 社區規范，轉而采用蘋果公司的 LL-HLS 規范，在 2020 年底和整個 2021 年，Exoplayer、Shaka player 和 hls.js 中都出現了 LL-HLS 支持。LL-HLS 規范中對 RF8673（HTTP 隨機訪問和實時內容）的引用為與 LL-DASH 的互操作性打開了大門，通過在一組共同的片段上使用字節范圍尋址（見 Will Law 關于此主題的詳細博文）。并非所有主要的 CDN 都與這一最新的演變相兼容，但到 2022 年底，這應該是一個行業的競爭力特性。毫無疑問，（至少）接下來的所有大型體育賽事都將以 LL-HLS 和 LL-DASH 進行轉播，向前推進。

CPIX - 統治密鑰交換業務

DASH-IF 的內容保護信息交換格式（Content Protection Information Exchange Format，CPIX）規范，現在是 2.3 版本，最初于 2015 年發布，無疑是行業中最好的隱秘寶藏，因為它允許視頻打包者與密鑰服務器使用獨特的加密密鑰請求 XML 有效載荷，而此前密鑰交換是通過 DRM 服務平臺的專有接口實現的。像 AWS 安全打包器和編碼器密鑰交換（SPEKE）這樣的框架，建立在 CPIX 之上，試圖圍繞一個共同的 API 方法進一步統一行業，以交換 CPIX 有效載荷，因為 DASH-IF 沒有提供一個攜帶 CPIX 文檔的參考 API。隨著最近 SPEKE v2.0 的發布（這是我自 2019 年底以來與 AWS Elemental 的主要工作課題之一），現在這兩個規范有了完美的統一，并且有了明確的跨版本的發展路徑，這將使所有下一個關鍵的交換創新順利到來。CPIX 是構建密鑰交換工作流程的強大工具集，既然它也已經作為 ETSI 規范發布，那么它肯定會在未來幾年內保持行業主導地位。

MSE 和 EME - 視頻播放器的重要推動因素

在我 2016 年發表上一篇博文時，W3C 的媒體源擴展（Media Source Extensions）和加密媒體擴展（Encrypted Media Extensions）規范已經是用于支持瀏覽器中媒體播放和解密的主導性底層機制，被所有 javascript 驅動的視頻引擎如 hls.js 或 dash.js 所利用。在瀏覽器領域，自那時以來最引人注目的兼容性擴展是 2019 年在 iPad 的 iOS13 的 Safari 中增加了 MSE 支持，而在聯網電視領域，2016 年在 HbbTV v 2.0.1 中引入了 EME，2020 年在 2.0.3 版本中引入了 MSE。雖然 MSE 和 EME 在安卓/安卓電視領域并不適用，但這些技術已經在電視操作系統（如 LG webOS 自 v3.0 或 Tizen OS v2.3）中取得了進展，現在為在多個電視生態系統中開發和部署 OTT 播放器提供了便利。另一個有趣的擴展是對 iPhone 的 Safari 瀏覽器的 MSE 支持（就像已經在 iPad 上提供的那樣--在這個平臺上實現LL-DASH播放），但聽起來蘋果不太可能添加它，因為這將突然允許 (LL-)DASH 在所有的 iOS 瀏覽器中挑戰 (LL-)HLS，并將 HLS 的相關性只限制在編譯的應用程序的范圍。這對于為實施者提供更多的選擇是好事，但肯定不利于蘋果對其生態系統的控制。

2未來的核心技術

試圖預測 OTT 技術的演變總是一個非常主觀的工作，但讓我們在相信和懷疑之間試一試。

轉播技術

雖然 QUIC 贏得了邊緣之戰，但它沒有被集成到 SRT 或 RIST 等轉播技術中（還沒有），這些技術迄今為止側重于線性 TS 攝入。隨著 CMAF 的使用擴展到客戶端分布的初始邊界之外，它可能會加速，因為這與單比特率或多比特率的 CMAF 轉播完美匹配。實際上，看到 SRT 和 RIST 利用這個機會融合成一個單一的技術棧是很好的，因為他們基本上做同樣的事情，只是略有不同，支持組織試圖通過 "我的成員比你多 "的新聞發布來殺死對方，在這個競爭中，SRT 聯盟迄今為止已經超過了 RIST 論壇。不過，能有 Zixi 協議的公開替代方案當然是好事。Facebook 團隊最近發布了 RUSH IETF 草案，該草案有可能顯示出這樣一條通往轉播協議 QUIC 的融合之路。從視頻編解碼器的角度來看，在 2019 年出現的 JPEG XS 似乎正在成為低延遲無損轉播的參考選項。它在 MPEG-2 中的傳輸是由 MPEG 和視頻服務論壇（VSF）剛剛發布的 MPEG-2 和 2110-22 傳輸的補充建議標準化的。許可條款似乎也很合理。因此，JPEG XS 應該在未來的許多年里在轉播空間中無處不在。

ABR 轉碼技術

在編解碼器領域，通用視頻編碼（又稱 VVC 或 H.266）肯定有很大的發展空間，它比 HEVC 有 50% 的預期改進（根據 Comcast 公司的 Jan Ozer 和 Dan Grois 的說法，目前的實現方式是 40%），而且自然適合 8K 和 360/VR 流媒體應用要求。但是，隨著 MPEG LA 和 Access Advance 現在形成的兩個專利池，我們有一些理由認為，這個新一代的 MPEG 編解碼器可能會面臨與 HEVC 前身一樣的許可問題。

另一個新的有趣的 MPEG 選項是低復雜性增強視頻編碼（LCEVC，又稱 ISO/IEC 23094-2）方法，其中兩層編解碼器的增強可以提高底層 AVC、HEVC 甚至 AV1 或 VVC 基礎編碼的感知質量，最高可達 50%。由于 V-Nova 是目前唯一被確認的專利持有人，有機會比 VVC 的許可條款更成功，并更快地引發一波實施。與 VVC 相比，LCEVC 的另一個主要優勢是，它不需要重新編碼整個 AVC 或 HEVC 內容庫來提供可操作的好處——假設你對你的視頻播放器有足夠的控制權來升級它們以支持增強層。這也是一個更平穩的過渡承諾，為無法升級的傳統播放器提供了向后兼容的路徑。增強層信令尚未在 HLS 和 DASH 中指定，但這不應該比多層杜比視訊流的信令更具挑戰性。對 CMAF 的綁定也是如此。

LCEVC 編解碼工作流（MPEG-5 LCEVC）

從音頻編解碼器的角度來看，很明顯，我們需要新的沉浸式選項來配合 VR 視頻軌道，并支持基于對象的音頻，以允許定制流組。我們還需要靈活地根據可訪問性需求來個性化音頻流的結構。MPEG-H 提供了制作者和終端用戶所需的個性化水平，為簡單的流組構成提供了預設，并為流組組件之間的細粒度音量調整提供了高級設置，包括響度保護。Fraunhofer IIS有許多關于這個主題的博客文章和網絡研討會，還有一個創作套件和相關教程。最近，MPEG-H 授權計劃已經啟動，所以它現在已經可以用于工業。

MPEG-H 渲染平臺（Fraunhofer IIS）

A/B 水印

隨著 DRM 和 HDCP 的利用在過去幾年中成倍增加，服務器端 A/B 水印作為內容保護的"最后手段"出現，在最初的措施被規避之后。雖然幾年來它一直是專有實現的游樂場，但促進了 CPIX 創建的相同的互操作性精神已經改變了 A/B 水印的格局。首先是 2020 年底發布的用于編碼器集成的超高清論壇水印 API，它允許直播和 VOD 轉碼器以共同的集成方式承載來自多個供應商的水印模塊（具有非壓縮域與壓縮域水印使用案例的微妙之處，水印發生在編碼期間或作為其后期處理）。閱讀 Laurent Piron 的這篇文章，了解關于這個版本的更多細節。目前是 V1.0.1 版本，當 DASH-IF 正在制定的配套規范發布時，該規范肯定會有小幅發展，但不會有大的轉變，所以它肯定是一個堅實的基礎。DASH-IF 目前正在擴展這一轉碼器級別的標準化工作，為原件/包裝商和 CDN 整合制定補充指南。對于原創者和包裝者，我們的想法是根據每個終端用戶的獨特水印模式和一層邊緣決策邏輯，指定 A/B 水印如何與流的攝取和轉換操作互動，以及來自 CDN 的轉發請求，以拉取 A 或 B 版本的片段。

A/B 水印工作架構（DASH-IF）

總的來說，這個想法是允許實施者在他們的工作流程中結合或交換各種編碼器、原件/包裝商和 CDN，在更換組件時只需在 A/B 邏輯方面做最小的調整。由于標準化工作相當重要，該規范將需要幾個月的時間才能發布，但我相信（也許我有偏見，因為我參與了這項工作），這兩個規范的結合將為實施工作提供一個非常強大的基礎。

DASH 清單文件優化

目前有幾項正在進行的計劃，以減少 DASH 清單文件的大小——還沒有與 HLS 清單一起。DRM 信號優化，由 DASH 第五版的 ContentProtection@Ref/RefID 屬性定義，是最直接的優化，因為它允許在清單中聲明一次 ContentProtection 元素，并在之后通過其 ID 進行引用，從而允許將 DRM 參數因素化，并大大減少所產生的清單大小。DASH 社區還在研究混合方案清單的優化，其中音頻 AdaptationSets 使用簡潔的 +Duration 方案，獨立于視頻 AdaptationSets 使用的基于 的方案，以消除音頻 <S> 行因音頻采樣率與視頻幀率不一致而產生的冗長。對于這第二項優化，還有一些驗證工作要做，包括廣告期和不對稱/不符合規定的軌道持續時間，但通過結合這兩種優化方法，優化潛力約為清單文件大小的 95% 至 98%。

還有就是 Hulu 在 MPEG（DASH 第五版第 5.15 節）和 DASH-IF 上推動的用于直播流的顛覆性的"補丁清單"方法（請看 Zack Cava 關于這個話題的精彩演講），其目的是改變我們至今為止的一個基礎假設：每次播放器在請求清單時，它都會得到播放 URL 所攜帶的所有 DVR 歷史。補丁清單方法取代了我們在業界使用多年的這種非常粗暴的方法，它說播放器只在第一次請求時獲得完整的清單（這樣它就可以獲得自流媒體開始時間和現在以來的完整 DVR 歷史），然后它在每次補丁清單請求時獲得增量清單更新，只攜帶自上次清單更新以來添加和刪除的片段——完整的媒體時間線由播放器在內存中動態構建，作為初始清單請求和所有后續補丁清單請求的結果。

補丁清單文件播放（Hulu）

這種機制在資源受限的播放環境中非常有效，因為它優化了清單解析操作，并通過傳輸非常輕量級的補丁清單大幅減少了網絡傳輸。這種補丁清單方法不僅減少了傳輸和解析的數據量，還能實現優化的廣告插入方法。因此，它是未來 5 年 DASH 的重要工具，并且從 3.2.1 版開始已經在 dash.js 中支持。如果 DASH 播放器和包裝商支持足跡的擴展，毫無疑問，這將很快成為 DASH 直播清單的主導方法。關于所有 MPD 優化方法的更多細節，請參考 Alex Giladi 在上次全球視頻技術會議上的精彩演講。

廣告插入

SGAI - 共同的回應（Hulu）

補丁清單方法允許的新的廣告插入范式是服務器引導的廣告插入（Server Guided Ad Insertion，SGAI）方法（在 DASH-IF 關于廣告插入的最新章節中描述）：服務器不再解析清單，用廣告段引用來替換媒體段條目，而是將播放器指向輕量級的補丁清單更新，只包括離散的廣告艙段，不產生額外的現場邊緣延遲。從服務器端廣告插入的角度來看，其可擴展性的好處是巨大的。蘋果公司最近發布了一個類似的 HLS 功能與廣告插播建議，這基本上是在一個離散的 EXT-X-DATERANGE 目標 URL 中隔離廣告艙的片段。在這種情況下，視頻播放器只有在廣告艙被實際消費時才會請求廣告艙的 URL，這就減少了廣告服務器在初始 DVR 窗口中的負載，而不僅僅是實時清單更新。您可以在 DASH SGAI 中做同樣的事情，對初始清單請求的廣告期與整個 DVR 歷史使用 Xlink（以便播放器僅在接近廣告艙時解決廣告）。

雖然 DASH SGAI 和 HLS Interstitials 共享大致相同的服務器端方法，但在客戶端有區別，DASH 播放器將用一個播放器實例處理媒體段和廣告段，而在 Interstitials 方法中，兩個 HLS 播放器實例將需要協調工作，一個用于內容媒體段，一個用于廣告艙段,至少在蘋果的實現中是如此。雖然它在像蘋果設備這樣的受控環境中可能運行良好，但這種雙播放器方法已經證明了它在低功耗環境中的低效率，因此它對更廣泛的 HLS 生態系統的適用性是相當值得懷疑的，而傳統的服務器端廣告插入（SSAI）將繼續在一段時間內發揮作用。我希望通過 CTA-WAVE DASH-HLS 互操作性倡議，這些新的廣告插入方法會發生進一步的整合，但有一件事是肯定的：為廣告插入進行完全清單解析的日子已經過去了，這將使我們的生活更加輕松。

低延遲

由于 LL-HLS 和 LL-DASH 是市場上的兩大競爭者，留給其他以 OTT 為中心的低延遲方法的空間就很少了。由 THEO 發起并由 HESP 聯盟推廣的高效流協議（HESP）正是為了成為這樣一種替代方案，仍然使用基于 HTTP 的傳輸。雖然它并不完全屬于 LL-HLS 和 LL-DASH 的延遲范疇--因為它的目標是亞秒級的延遲水平，更屬于 WebRTC 的范疇。

一個 HESP 流的開頭（IETF）

該規范最近作為 IETF 草案發布。用于達到最低延遲和壓縮時間的 Maximal Gain Profile 不允許在 Continuation Stream 段中使用 B 幀，而在 Maximal Gain Profile 和 Compatibility Profile 中，Initialization Stream 段（在播放會話開始時使用）必須只包括 I 幀。這意味著所需的編碼資源至少要增加一倍，才能在與連續流片段相同的幀率下，將初始化流片段制作成僅有 I 幀的片段。在制作大型 ABR 階梯時，加倍的編碼可擴展性要求并不簡單，因為它可能需要將編碼負載分散到多個同步編碼器實例上。我們需要一個非常好的理由來接受這種權衡，比如 WebRTC 傳輸基礎設施的成本和復雜性大大優于翻倍的編碼足跡的成本和復雜性，這在一定的收視率水平上可能是真的，但我很難說清楚哪里是閾值。鑒于這種編碼的可擴展性問題，我不認為 HESP 可以取代 LL-HLS 或 LL-DASH，在目標延遲為 2 至 5 秒的任何使用情況下。

關于 HESP 列舉的另一個好處，值得注意的是，MPEG 正在進行一些活動，為 DASH 定義一個解決方案，可能不需要一個特定的切換適應集和一個特殊的編碼或重新包裝。因此，HESP 最終可能只與 HLS 在快速切換方面進行競爭。

源攝取和同步元數據

CMAF 攝取和多源（DASH-IF）

DASH-IF 正在制定一個攝取規范（第二版正在社區審查中），涵蓋了 CMAF 攝取和 DASH/HLS 攝取，旨在廢除仍在多個解決方案中使用的傳統的 Smooth Streaming 攝取，這已經有一段時間了。這在 DASH-IF 上是一個相當有爭議的討論，而且它可能還沒有完成（在一些小問題上，如使用 Unix 紀元時間作為可用性開始時間），因為 MPEG 可能會把 DASH-IF 的工作作為一個新的 MPEG 編碼器和起源規范的起點，但它與 Interface 1（CMAF 的）一起朝著好的方向發展，這可能會使業界統一在一個共同協議的碎片化攝入上。被廣泛采用的驅動力是平滑流格式越來越無法應對進一步的創新，以及對低延遲工作流程的普遍需求，這可以通過 HTTP/1.1 分塊傳輸編碼（或 HTTP/3 與 DATA 幀，這樣攝取規范將是 HTTP/3 友好的）與分塊 CMAF 相結合的攝取規范來支持。

用于帶內事件和定時元數據軌道處理的DASH播放器架構（DASH-IF）

從最初起，攝取規范中還包括使用定時元數據軌道來承載事件，如 SCTE-35 標記在一個獨立的軌道中，而不是像行業中存在的數字視頻以來的視頻軌道。這曾經是而且現在仍然是一個有爭議的話題，因為它需要一個嵌套的時間線來將元數據事件的時間戳與視頻和音頻的時間戳聯系起來，這使得在事情發生時更難進行故障排除。除了這個矛盾點以外，這個想法是好的，因為它可以通過使用單一軌道而不是在所有視頻軌道中系統地復制元數據來減少用于元數據的帶寬，確保元數據獨立于其他媒體軌道，并更容易通過人工智能引擎處理元數據有效載荷，以進行翻譯/索引/分析。雖然有辦法在 DASH 清單中發出定時元數據軌道的信號，但在 HLS 清單中仍然沒有這種情況，如果這個問題得到解決，這可能會引發更廣泛的采用。我們依靠像 CTA-Wave 這樣的 SDO 來說服蘋果填補 HLS 規范中的這種結構性空白。現在，定時元數據軌跡可以在產業鏈的上游使用，但不能直接被視頻播放器（至少是 HLS 播放器）使用；一旦端到端的使用成為可能，那么對產業來說就是一個完全不同的故事。

QoE / 多-CDN

構建一個靈活的多 CDN 視頻傳輸架構從來都不是一件容易的事情：每個 CDN 專有的邊緣視頻標記化實現往往使標記化成為不可能，而迫使使用 DRMs，在播放器層面收集的性能數據很難與 CDN 日志相關聯，專有的 CDN 負載平衡機制往往需要自定義播放器實現，因為 HLS 和 DASH 規范并沒有提供足夠的原生機制。所有這些都將發生變化，因為有多個倡議旨在解決這些問題。

CTA-WAVE 最近與 SVA 一起開始了一項關于標記化主題的工作，它被稱為通用訪問標記（Common Access Token）倡議。它的目標是定義一個可以跨多個 CDN 使用的視頻標記方案，這樣，兩個 CDN 標記之間的唯一區別可能只是用于確保 URL 簽名的秘鑰。一旦這項標準化工作產生結果（我認為大約在 2022 年第二季度），我們可以期待在主要的 CDN 中迅速采用，這些 CDN 廠商都參與了討論，并且在他們的客戶中渴望簡化他們的實施。

有了 CTA-WAVE 在 2020 年底發布的通用媒體客戶端數據（Common Media Client Data，CMCD）規范，CDN 到客戶端的性能數據關聯現在變得更加容易。該規范定義了關鍵的播放器數據點（又稱 "保留鍵 Reserved keys"），如會話 ID、緩沖區長度或測量吞吐量，以及在 CDN 請求中包含這些數據點的方法，通過頭文件/查詢字符串，或與對象請求并行，向 CDN 發送獨立的 json 對象。雖然該規范沒有說 CDN 應該如何將數據點轉發給第三方多 CDN 決策服務，但這仍然是一個非常重要的進展，因為這是我們第一次有一個標準化的框架來了解視頻播放器在多個播放會話和 CDN 環境中的性能。在播放器方面，有 dash.js、Exoplayer 和 Akamai AMP 的支持。在 CDN 方面，到目前為止，Akamai 支持它，但這正在迅速擴大。Datazoom 視頻數據平臺也在支持它。由于支持 CMCD 對于生成多 CDN 切換所需的數據至關重要，因此在不久的將來，看到更多的播放器支持 CMCD 將是至關重要的，特別是蘋果 HLS 播放器，它們在對象請求結構方面是不可定制的。這個標準化過程的下一步是定義一個通用媒體服務器數據（CMSD）的有效載荷格式，可以用來客觀地比較多個 CDN 的交付性能。這項工作在 CTA-WAVE 剛剛開始，所以在我們看到可操作的結果之前，還需要幾個季度的時間。但是，將 CMCD 和 CMSD 的數據結合到一個單一的數據湖中，應該能夠以一種非常有效的方式為多 CDN 切換決策提供信息。

這就是 HLS 內容指導提案的作用。它沒有談及每個客戶/終端用戶應該如何做出 CDN 切換決定，但它描述了在 HLS 父播放列表中應該如何描述多個 CDN 的同一直播或 VOD 內容的多個版本，以及播放器應該如何根據來自內容指導服務（基本上是多 CDN 切換服務）的 JSON 響應在這些版本之間切換。總的來說，這是一個相當簡單的機制，所以它完全有機會成功。問題是，這是一個以 HLS 為中心的機制，所以我們必須在同等的 DASH 機制上下功夫，比靜態的 BaseURL 元素有更多的表現靈活性，以支持多個 CDN 和相關的邊緣令牌，并利用相同的內容指導服務 JSON 有效載荷。這項工作在 MPEG 或 DASH-IF 還沒有開始，但這只是一個時間問題，直到它被拾起。一旦完成，我們將得到一個強大的框架，通過 CMCD/CMSD 和通用接入令牌來構建多 CDN 交換服務。

可伸縮性

我認為對可擴展性影響最大的技術之一將是 IP 多播自適應媒體流——也就是所謂的多播 ABR（mABR）。在過去 5 年左右的時間里，像 Broadpeak 這樣的公司一直在采用專有模式，電信公司和有線電視運營商的采用率也很高。它基本上是將單播的 DASH 或 HLS 流作為輸入，并將其轉化為多播的 DASH 或 HLS 的直播邊緣片段，視頻播放器以單播方式請求 DVR 片段，傳遞直播內容的最后幾分鐘。它最近被 DVB 標準化為 DVB-MABR，作為更廣泛的 DVB over Internet（DVB-I）計劃的一部分，它現在可供所有網絡運營商實施。5G 的混合模式組播能力也有同樣的潛力。在實踐中，它仍然受制于電信網絡上非常有預見性的 IP 多播計劃配置--這意味著它可以用于已知的 24/7 直播頻道，是一種相當靜態的、類似 IPTV 的配置。

mABR 參考結構（DVB）

但是，讓我們快進到這一天，當這項技術最終使用完全動態供應時（這不是現階段規格的一部分，現在只是活在我的想象中）——意味著它將能夠應用于運營商網絡上最受歡迎的直播流，可能是事先已知的 24/7 頻道或任何 OTT 事件流（如高級拳擊或足球付費賽事）突然在網絡上聚集了幾十/十幾萬觀眾。與目前的單播情況相比，常規 OTT 流的好處將是巨大的，在單播情況下，由于反向代理架構的可擴展性限制，流會以最大努力的方式被緩存在 ISP 基礎設施中。

DVB-MABR 方法的另一個局限性（實際上 ATSC 3.0 也是如此）基本上是它采用了傳統的廣播視角，同時將線性流換成了分段格式，而不是試圖通過廣播可擴展性技術來改善分段格式的傳輸。從廣告插入的角度來看，它通過第三方 CDN 代理服務（在蘋果語言中又稱內容指導服務）將視頻播放器重定向到多播交會服務的方式是一個非黑即白的選擇：如果直播流以單播方式播放，那么你可以使用 SGAI；如果直播流以多播方式播放，那么廣告插入就需要在客戶端進行（通過單播），這其中有很多的隱患。最后，無論直播流的傳輸模式是什么，個性化的廣告段都將通過單播傳輸，所以為什么不嘗試將清單和段的傳輸解耦，通過系統地以單播方式交付個性化的清單（這現在是一個高度可擴展的選項，使用 DASH 補丁清單或 HLS 廣告插播），段的轉發請求在進行多播終止的網關上從單播翻譯成多播？這將通過堅持 SGAI 方法來保持廣告插入工作流程的效率，同時通過媒體段的多播交付來保持分段線性流的可擴展性（這才是真正的可擴展性問題）。它還將保留做有針對性的內容替換的靈活性（如地理定位/基于用戶狀態的停播或體育比賽直播替換），這在全多播的直播場景中是不容易做到的。然后，問題就變成了如何讓多播網關知道單播和多播媒體段 URI 之間的映射，但與多播服務器在上游進行的單播到多播的轉換相比，這是一個微不足道的問題，需要解決。

雖然我相信我在這里提出的單播/多播混合傳輸方案可以成功實施，但通過多播傳輸媒體片段會帶來另一個問題：它基本上阻止了 A/B 水印的工作，因為媒體片段對每個視頻播放器都是一樣的。在單播 A/B 水印的背景下，CDN 邊緣決策邏輯為媒體片段的轉發請求路由提供動力，需要用其他東西來替代。第一個選擇是通過組播傳輸所有 A 和 B 段的變體，讓組播網關操作 A/B 邏輯，而不是單播 CDN 邊緣。從安全的角度來看，這是一個挑戰（多播網關必須經過加固，并支持復雜的 A/B 邏輯），從網絡的角度來看（在不同的多播 URI 上以 A 和 B 的變體傳輸所有的流，以及它在網絡上占據的所有空間）。第二種選擇是使用單一的組播媒體段，用客戶端水印取代服務器端 A/B 水印，在視頻播放器方面也有同樣的加固挑戰，如果水印已經在客戶端進行了完全的單播 OTT 分發，這可能真的不是一個額外的負擔。不管怎么說，這里有一個很大的挑戰要解決，而且絕對不是簡單的。我相信 DVB 和 DASH-IF 的專家會找到一個優雅的解決方案，如果我們在混合單播/多播傳輸模式的規范中走到這一步的話。

全都放到一起

縱觀本文，我們得出了一個混合架構的設想，在這里我們既可以受益于 OTT 解決方案的靈活性--服務器端流的個性化/SGAI、清單優化和基于標準化 QoE 反饋環路的多 CDN 切換，又可以盡可能受益于媒體段的組播交付的可擴展性。讓我們用一個高層次的圖表來總結一下，看看每種技術需要在哪里實施，主要的數據流是什么（而不是應該如何設計冗余/故障轉移架構）：

全文技術總體架構

我可能還需要 5 年的時間來實現這個愿景，但這很好，因為我還很年輕。最后我想說，在過去的 21 年里，與眾多的流媒體技術打交道，對我來說是一次令人興奮的旅程，我總是對這個領域的下一步發展感到著迷。在過去的 5 年里，我們看到了大量的技術在 OTT 領域崛起，而且在未來的 5 年里，這種節奏似乎也不會慢下來。很高興看到我們正在達到這樣的地步，即我們擁有所有必要的工具，使流媒體像廣播一樣可靠和可擴展——終于！。

---

掃描圖中二維碼或點擊閱讀原文

了解大會更多信息

總結

以上是生活随笔為你收集整理的未来流媒体工作流的核心技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。