下載客戶端

登錄

（超）低延遲視頻流傳輸的未來

2022-06-20 15:16

來源：澎湃新聞·澎湃號·湃客

作者：Anthony Dantard

翻譯：Alex

技術審校：袁榮喜

▲掃描圖中二維碼了解音視頻技術大會更多信息▲

影音探索 #013#

用戶對服務的期望在不斷攀升，并逐漸出現了不滿情緒。由于有了 YouTube 和 Netflix 這樣的視頻服務，我們都希望在觀看點播視頻時獲得超快的下載時間和流暢的播放體驗。可能不太明顯的是，無論我們是否意識到，這種期望都正在慢慢地向實時音頻通信和直播應用轉移。

在 api.video，我們致力于向用戶交付最佳開發和觀看體驗。很自然地，我們花費了大量時間思考和跟進視頻協議的發展。每個視頻傳輸協議都有其優點和缺點，并適用于不同的應用場景。

在本文中，我們總結了四種主要的低延遲協議，探討它們的優點和缺點，并給出了我們對于這些協議未來發展的評論。下面是我們將深入討論的四種協議：

WebRTC

LL-HLS

LL-DASH

HESP

WebRTC

WebRTC 協議支持音頻和視頻流的實時、雙向通信。它主要用于音頻和視頻的推流和分發，其端到端延遲在 300ms~600ms 之間（取決于網絡質量和用戶之間的距離）。WebRTC 真正獲得成功是在 2011 年，當時谷歌收購了 Global IP Solutions（該公司最先開發了 WebRTC），并為這個項目在資金和開發人力上提供了大量的支持。

10 年之后，WebRTC 已成為 Web 上的實時視頻通信標準。通過 W3C 和 IETF 維護的 JavaScript API 就可以訪問 WebRTC 組件，因此用戶無需安裝第三方工具即可直接通過 Web 瀏覽器進行直播。

理論上，WebRTC 可以通過連接兩個瀏覽器客戶端（P2P）建立視頻會議系統。然而，現實中的網絡架構（互聯網、公司和本地網絡）會使事情變得非常復雜。

在互聯網迷宮中找到自己的出路

有些時候，我們的終端并不是直接連接互聯網，而是要經過幾個網絡層，比如 NAT、防火墻或者代理。為了解決這些問題，WebRTC 允許你使用 ICE（Interactive Connectivity Establishment，交互連接建立）協議，該協議可以幫助你找到讓兩臺機器通信的最直接路徑，并穿過不同的網絡層。為此，需要 STUN/TURN 服務器來獲取用戶的外部地址并在無法直接連接時負責通信數據轉發。在大部分的 WebRTC 生產環境中，WebRTC 協議需要（除了它自身的多媒體服務器基礎設施之外）一組 STUN / TURN 服務器支持高質量通信。

使問題變得更復雜

WebRTC 協議要求端與端之間所有通信數據必須加密（音頻、視頻和數據應用），因此它會內嵌一些安全協議填補使用 UDP 協議時的空白。WebRTC 使用 SDP（Session Description Protocol，會話描述協議）顯示 P2P 連接的一些屬性，如交換的媒體類型及其相關編碼器、傳輸網絡和一些帶寬信息。

這其中也涉及 DTLS（Datagram Transport Layer Security，數據包傳輸層安全協議）、SRTP（Secure Real-Time Transport，安全實時傳輸協議）、SCTP（Stream Control Transport Protocol，流控制傳輸協議），其中 DTLS 用于生成自簽名證書來進行加密信息的協商（用于 peer 之間加密媒體數據以及應用數據的安全傳輸）。SRTP 用于音頻和視頻的加密傳輸。SCTP 用于應用數據的加密傳輸。

WebRTC 規模化的挑戰

WebRTC 協議支持多種網絡架構服務模型，每種架構對應一種特定的應用場景，而且每種架構都有自己的優劣勢。本文我們不會深入討論這些架構，但是請注意，SFU（Selective Forwarding Unit，選擇性轉發單元）也許是目前 WebRTC 應用中最流行的架構。

WebRTC 所面臨的主要挑戰來自大規模采用的可行性（節省成本的前提下）。我們并不是說 WebRTC 無法在世界范圍內被采用：幾年以前它確實還處于規模化的早期階段，但是一些優秀公司不懈努力地對架構進行重大的改進，已經在規模化應用方面有了很大進步。

由于 WebRTC 是由多個協議組成的通信標準，所以工程師們必須學習和掌握每個協議，這進一步增加了它的應用復雜度。對于大部分公司來說，在他們的基礎設施中以合理成本部署全球規模的 WebRTC 服務還很困難。尤其是要實現支持 WebRTC 的各種場景，他們還需要將 SFU 和 MCU 架構混合部署在邊緣節點上。

低延遲 HTTP ABR 流媒體傳輸協議

與 P2P 的 WebRTC 協議（理論上不需要中央服務器在兩臺機器間建立通信）相比，基于 HTTP 的流媒體協議需要使用服務器且在標準的 HTTP 上進行通信。它們構建于 Web 最基礎的部分之上。

HLS/LL-HLS

HLS（HTTP Live Streaming）協議用于向全球范圍的觀眾傳輸直播和點播內容，它于 2009 年由 Apple 推出，其特色是延遲較大的超大規模音視頻分發技術。雖然用戶面對的平均延遲為 15 秒左右，但 HLS 的延遲卻達到了 30 秒～1 分鐘。即使在高性能的基礎設施和優化的打包和播放器配置的加持下，延遲有望達到 6 秒，但這對于實時直播視頻場景來說依然太高。不過它依然是最受歡迎的 ABR 流媒體協議。它的成功主要源自它對一眾設備的強大兼容性，以及它可以支持多種高級功能，如隱藏字幕、廣告，使用 AES 加密或 DRM 的內容保護等。雖然該協議也可以實現視頻推流，但它通常用于視頻的分發，一般與之配合的是使用 RTMP 協議進行推流。下圖就是一個包括 RTMP 協議和 HLS 協議的典型直播流媒體架構。

我們不會在本文深入探討 HLS 的工作原理，下圖是一個簡單方案：描繪了播放列表和媒體切片是如何使 HLS 實現碼率自適應技術（ABS）的。

所以 HLS 如何不斷發展以支持更低的延遲呢？

一開始，HLS 只與 MPEG-TS 容器格式（與 H.264/AVC 編解碼器相關）一起使用。在 2016 年，它增加了對 FMP4（fragmented MP4）的支持，從而可以支持 CMAF 格式并與 DASH 兼容。一年以后，HLS 增加了對 H.265/HEVC（僅 FMP4）的支持，顯著減少了帶寬的使用。因此在 2020 年 4 月，Apple 終于實現了 LL-HLS（低延遲 HLS）—— 基于 HLS 協議的擴展；在維持 HLS 自身的可擴展性的同時，還可以利用子切片和這些切片的動態傳輸實現低延遲視頻和直播。該協議的第一個草案要求支持 HTTP/2 Push，但這樣一來，它反而更難實現了。毫不意外，隨著主流 CDN 廠商選擇不支持此功能，LL-HLS 的大規模兼容部署也進入了死胡同（因為沒有 CND 廠商能夠緩存此類內容）。不過幸運的是，Apple 聽取了領域和行業內的建議，又推出了新版本的擴展協議，移除了對 HTTP/2 Push 的需求，但保持對 HTTP/2 協議的依賴。他們將該標準并入 HLS 中，使 LL-HLS 能夠完全向后兼容 HLS，這意味著 HLS 的所有功能在 LL-HLS 中都能找到。

實際上 LL-HLS 的工作原理與 HLS 一樣，但是為了降低打包過程中的延遲，它做了一些重要更改。下面是 LL-HLS 在保存可擴展性和 ABR 能力的同時，為了實現低延遲所做出的最重要的更新：

子切片（Partial Segments:）：一個切片被分割為多個子切片（或指媒體播放中幾毫秒的一部分）。與原始切片在 CDN 上的較長 “生命” 相比，它們的緩存時間非常短。一旦產生完整切片，那么為了減少帶寬，與其相關的子切片就會從播放列表中移除。

預加載提示（Preload hints）：媒體播放列表有一個 “預加載提示” 標簽，它可以使播放器預知將有哪些新的子切片，以便于服務器在數據可用時立即響應播放器的新切片請求。

阻止播放列表重新加載（Block Playlist Reload）：該功能通過向請求（只有在播放列表包含一個新的切片或者子切片時，該請求才會告知服務器播放器需要響應）消息中添加查詢參數避免了播放器和服務器之間的媒體播放列表輪詢（Polling）。

播放列表增量更新（Playlist Delta Updates）：通過使用新的 EXT-X-SKIP 標簽，播放器可以僅請求媒體播放列表的更新部分，從而節省已有數據的傳輸成本。

碼率版本報告（Rendition Reports）：Primary Manifest 中索引的每個版本都添加了 EXT-X-RENDITION-REPORT 標簽，它在播放器進行 ABR 操作時提供了一些有用的信息，比如用于每個版本的最后一個序列號和最后一個子切片。

目前，在具備合適的 GOP、子切片和合理的緩沖大小的前提下，公有云廠商所提供的端到端延遲有望達到 2 秒左右。雖然與 WebRTC 所能達到的延遲相比依然有很大差距，但在現有的直播架構中，LL-HLS 顯著降低了復雜性，且更加容易實現。你也可以通過修改設置將協議效用發揮到極限，達到 1 秒左右的延遲，但這樣做的代價是犧牲播放體驗的流暢性和質量。

DASH/LL-DASH

DASH 是 Dynamic Adaptive Streaming over HTTP 的簡稱，它是一種自適應流媒體傳輸協議。DASH 于 2012 年 4 月由 MPEG 推出，目的是在 HLS 協議（由 Apple 擁有）之外，開發一個行業標準。它的工作原理與 HLS 類似：都是基于不同質量水平的內容準備，將清單文件中索引的視頻切分成小塊，然后再對其使用 ABR 技術編碼。

DASH 還支持通過 CENC（Common Encryption standard，通用加密標準）加密的內容保護，這使它能夠與所有常見 DRM 系統兼容。

LL-HLS 和 LL-DASH 的主要區別是 LL-DASH 適用于各類編解碼器。但遺憾的是，如果使用一些特殊的編碼器，LL-DASH 將無法與依賴 iOS 的 Apple 設備兼容（包括 Apple TV）。

2017 年，LL-DASH 對標準化協議進行了必要的修改，將延遲降低到了 2 秒。背后，它所依賴的正是 CMAF（Common Media Application Format，通用媒體應用格式）。CMAF 使 LL-DASH 能夠使用一些有用的 HTTP 特性，從而顯著降低延遲。這兩個特性分別是 “分塊編碼（Chunked Encoding）” 和 “分塊傳輸編碼（Chunked Transfer Encoding）”，它們都是 HTTP1.1 的一部分（而在 HTTP/2 中禁止使用）。分塊編碼先將視頻切片分割成幾毫秒的視頻塊，這些視頻塊一旦被編碼，就會被發送到分發層；接下來由分塊傳輸編碼將這些視頻塊快速分發。然而，要完成這樣的傳輸過程，整個分發棧從源站開始一直到 CDN 都必須支持分塊傳輸編碼這一特性。

HESP

HESP（High Efficiency Stream Protocol，高效流媒體協議）是另一個基于 ABR HTTP 的流媒體傳輸協議，也是最新推出的協議。它是由 THEOPlayer 公司通過 HESP 聯盟（主要任務是致力于 HESP 協議的標準化和發展）進行標準化的。

開發 HESP 的目的是解決其他 HTTP 流媒體協議的局限性，它的目標是：

在確保可擴展性（指依然可以與主流 CDN 廠商合作）的同時達到超低延遲（低于 500 毫秒）。

在傳輸時減少所需帶寬消耗。

減少切換次數（zapping times），zapping 是指各種視頻流之間切換（可以想象成在觀看有線電視時切換頻道）的次數。

這三個性能指標對于直播觀眾的用戶體驗具有直接的影響。由于 HESP 的極低延遲，它也可以成為 WebRTC 的替代方案。HESP 最主要的缺陷是，它是專有的商業協議，商用的話，價格非常高。

讓我們來簡單看下它的工作原理。

與其他低延遲協議相比，HESP 最大的區別是它依賴兩個（而非一個）視頻流。在了解 HESP 如何幫助我們達到次秒級延遲之前，讓我們先來聊聊視頻流傳輸所使用到的不同類型的幀。在視頻壓縮中，要用到以下幾種幀：

IDR 幀（也稱為關鍵幀）

I 幀

P 幀

B 幀

讓我們先從 I 幀開始，理解了 I 幀，你才能更好地理解其他幀。I 幀包含全部圖像，并且在編碼時除自身外無需參考其他任何幀。

關鍵幀（或 IDR 幀）是一種特殊的 I 幀，關鍵幀之后的幀無法參考到它之前的幀。也就是說，所有 IDR 幀都是 I 幀，但反過來卻不是如此。任何播放器都能使用關鍵幀開始播放視頻。

P 幀只保存當前圖像與前一張圖像間的變化。B 幀所保存的是當前幀與其前后幀之間的變化。

現在你已經知道了構成視頻的不同幀之間的作用，讓我們回到組成 HESP 協議的視頻流：

第一個視頻流被稱為初始流（Initialization Stream），僅包含關鍵幀。

第二個視頻流被稱為延續流（Continuation Stream），它類似于普通的編碼流，意味著它能夠包含所有類型的幀（取決于實現最大性能或者最大兼容的編碼參數和定義的配置文件）。

初始流只用于播放開始時或者當你為了更改播放位置而滑動視頻時間線時。由于它僅包含關鍵幀，播放器背后的解碼器能夠快速解碼該幀，然后才開始（或重新開始）播放直播事件。一旦第一個視頻流中的第一幀被獲取并解碼，播放器就會自動切換到第二個視頻流，并繼續播放視頻。這是因為關鍵幀是完整的圖像，所以它的帶寬成本很高。通過切換到第二個視頻流，播放器會回退到常規的實時視頻流帶寬占用，這將提高 CDN 的并發性能（CDN 可以擴展觀眾并降低到源站的負載）。同 DASH/LL-DASH 一樣，HESP 也使用 CMAF-CTE 進行視頻打包和分發。它繼承了 DASH/LL-DASH 的所有的特性，比如加密、支持 DRM、字幕（以及聽力障礙人士所使用的字幕）、廣告等。

HESP 看起來很厲害（理論上），是吧？它確實解決了許多問題。但是同其他協議一樣，它也不是完美的。它也有自身的缺點和局限性。第一個缺點就是，它使用兩個同步編碼的視頻流，其編碼和存儲成本要高于其他基于 HTTP 的流媒體協議。

第二個缺點是，即使它依靠 CMAF-CTE 進行打包和分發，在編碼和分發階段，打包器必須進行更新才能處理兩個（而非一個）視頻流。

除此之外，和打包器一起，為了能夠使用 HESP 協議播放視頻并處理所有的字幕，播放器也必須進行更新。最后一點也很重要，你必須支付專利費用才能商用 HESP，這無疑限制了它的普及推廣。

所以哪種協議最好？

簡潔的回答是沒有最好的協議。這個答案似乎對做出選擇沒什么幫助。更完整的答案是協議的選擇主要依賴于其所針對的使用場景、資源投入（包括資金和人力）、時間成本等。

如果你需要向用戶和觀眾提供合理延遲范圍內（6 秒～15 秒）的實時視頻傳輸能力，同時保持成本效益，我們會推薦你使用 HLS 和（或）DASH，因為它們可以輕松將視頻傳輸給數百萬觀眾。你可以找到許多已經很好地實現了這兩個協議的開源庫和流媒體平臺。我們更傾向于選擇 HLS，因為它在采用率以及瀏覽器和設備的支持率方面都是最高的。幾乎在任何地方都可以使用它。

如果延遲對你的業務而言非常重要，你應該了解一下低延遲和超低延遲協議，如果你只需要延遲在 2 秒左右（適用于體育賽事、音樂會和在線課堂）的單向實時視頻傳輸性能，而又沒有太多的預算，你應該了解一下 HLS 和（或）LL-DASH 協議。

對于其他不能接受延遲超過 1 秒的應用場景，你沒有太多選擇：WebRTC 或者 HESP。如果你們是一家非盈利組織，但是需要服務大量觀眾或者不想構建極其復雜的基礎設施且沒有太多預算，不妨考慮一下 HESP 協議。

如果你需要雙向視頻通信，WebRTC 已經證明了它的實力。但如果構建內部基礎設施并不是你的核心業務，你很可能需要依賴已經成功構建了基礎設施（已實現規模化）的提供商。

最后，如果資金不是問題，我們會選擇 HESP，因為與實現 WebRTC 相比，它要簡單得多，并且與各類設備和瀏覽器兼容。

在 api.video，我們非常相信，基于 HTTP 的低延遲或超低延遲流媒體傳輸協議將在最后贏得這場 “戰斗”。原因非常簡單，這些協議在相對陳舊的基礎設施中更容易實現，并從更多設備和瀏覽器的支持中獲益，同時它比 WebRTC 更容易擴展，而且由于它們并沒有收取高昂的許可費用，所以大量公司都可以采用。

這就是我們基于 HLS 構建端到端邊緣視頻基礎設施的原因。我們有信心，HLS 在不久的未來會成為唯一滿足各類音視頻應用場景的傳輸協議。

作者簡介：