低延遲協議影音探索

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

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

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

WebRTC

LL-HLS

LL-DASH

HESP

WebRTC

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

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

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

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

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

使問題變得更復雜

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

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

WebRTC規?；奶魬?/p>

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

WebRTC所面臨的主要挑戰來自大規模采用的可行性（節省成本的前提下）。我們并不是說WebRTC無法在世界范圍內被采用：幾年以前它確實還處于規?；脑缙陔A段，但是一些優秀公司不懈努力地對架構進行重大的改進，已經在規?；瘧梅矫嬗辛撕艽筮M步。

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

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

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

HLS/LL-HLS

HLS（HTTP LiveStreaming）協議用于向全球范圍的觀眾傳輸直播和點播內容，它于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 AdaptiveStreaming over HTTP的簡稱，它是一種自適應流媒體傳輸協議。DASH于2012年4月由MPEG推出，目的是在HLS協議（由Apple擁有）之外，開發一個行業標準。它的工作原理與HLS類似：都是基于不同質量水平的內容準備，將清單文件中索引的視頻切分成小塊，然后再對其使用ABR技術編碼。

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

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

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

HESP

HESP（High EfficiencyStream 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在不久的未來會成為唯一滿足各類音視頻應用場景的傳輸協議。

審核編輯 ：李倩