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

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

用戶對(duì)服務(wù)的期望在不斷攀升，并逐漸出現(xiàn)了不滿情緒。由于有了YouTube和Netflix這樣的視頻服務(wù)，我們都希望在觀看點(diǎn)播視頻時(shí)獲得超快的下載時(shí)間和流暢的播放體驗(yàn)。可能不太明顯的是，無(wú)論我們是否意識(shí)到，這種期望都正在慢慢地向?qū)崟r(shí)音頻通信和直播應(yīng)用轉(zhuǎn)移。

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

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

WebRTC

LL-HLS

LL-DASH

HESP

WebRTC

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

10年之后，WebRTC已成為Web上的實(shí)時(shí)視頻通信標(biāo)準(zhǔn)。通過(guò)W3C和IETF維護(hù)的JavaScript API就可以訪問(wèn)WebRTC組件，因此用戶無(wú)需安裝第三方工具即可直接通過(guò)Web瀏覽器進(jìn)行直播。

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

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

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

使問(wèn)題變得更復(fù)雜

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

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

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

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

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

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

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

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

HLS/LL-HLS

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

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

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

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

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

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

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

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

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

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

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

DASH/LL-DASH

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

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

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

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

HESP

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

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

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

在傳輸時(shí)減少所需帶寬消耗。

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

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

讓我們來(lái)簡(jiǎn)單看下它的工作原理。

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

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

I幀

P幀

B幀

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果你需要雙向視頻通信，WebRTC已經(jīng)證明了它的實(shí)力。但如果構(gòu)建內(nèi)部基礎(chǔ)設(shè)施并不是你的核心業(yè)務(wù)，你很可能需要依賴已經(jīng)成功構(gòu)建了基礎(chǔ)設(shè)施（已實(shí)現(xiàn)規(guī)模化）的提供商。

最后，如果資金不是問(wèn)題，我們會(huì)選擇HESP，因?yàn)榕c實(shí)現(xiàn)WebRTC相比，它要簡(jiǎn)單得多，并且與各類(lèi)設(shè)備和瀏覽器兼容。

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

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

審核編輯 ：李倩