低延遲協(xié)議影音探索

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

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

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

WebRTC

LL-HLS

LL-DASH

HESP

WebRTC

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

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

理論上，WebRTC可以通過連接兩個瀏覽器客戶端（P2P）建立視頻會議系統(tǒng)。然而，現(xiàn)實中的網(wǎng)絡架構(gòu)（互聯(lián)網(wǎng)、公司和本地網(wǎng)絡）會使事情變得非常復雜。

在互聯(lián)網(wǎng)迷宮中找到自己的出路

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

使問題變得更復雜

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

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

WebRTC規(guī)?；奶魬?zhàn)

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

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

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

低延遲HTTP ABR流媒體傳輸協(xié)議

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

HLS/LL-HLS

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

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

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

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

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

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

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

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

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

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

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

DASH/LL-DASH

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

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

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

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

HESP

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

開發(fā)HESP的目的是解決其他HTTP流媒體協(xié)議的局限性，它的目標是：

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

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

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

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

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

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

IDR幀（也稱為關(guān)鍵幀）

I幀

P幀

B幀

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

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

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

現(xiàn)在你已經(jīng)知道了構(gòu)成視頻的不同幀之間的作用，讓我們回到組成HESP協(xié)議的視頻流：

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

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

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

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

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

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

所以哪種協(xié)議最好？

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

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

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

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

如果你需要雙向視頻通信，WebRTC已經(jīng)證明了它的實力。但如果構(gòu)建內(nèi)部基礎(chǔ)設施并不是你的核心業(yè)務，你很可能需要依賴已經(jīng)成功構(gòu)建了基礎(chǔ)設施（已實現(xiàn)規(guī)?；┑奶峁┥?。

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

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

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

審核編輯 ：李倩