在WWDC 2019上，Roger Pantos宣布了Apple針對HLS的最新規范，其變化旨在減少實時視頻流的延遲。本文來自Mux流媒體專家Phil Cluff，LiveVideoStack進行了翻譯。

文 / Phil Cluff

翻譯 / John

原文?

https://mux.com/blog/the-community-gave-us-low-latency-live-streaming-then-apple-took-it-away/

在WWDC 2019上，Apple 依照慣例宣布了一系列的軟件更新。并且像過去4年的傳統一樣，Roger Pantos上臺宣布了HTTP直播視頻流（HLS）規范的最新變化，今年的變化旨在減少實時視頻流的延遲，但這樣做的代價是什么呢？

HLS是一種分段傳輸技術，支持向設備進行實時和點播視頻流傳輸。雖然HLS是為蘋果設備設計的，但現在也已經被廣泛應用于視頻流生態系統，包括瀏覽器、智能電視、機頂盒和游戲機。HLS是一個易于理解和實現的簡單協議，開發者可以提供一個主播放列表（通常稱為清單）文本文件，該文件描述了可用內容的不同分辨率和碼率組合，開發者可以為每種組合提供單獨的播放列表，此列表包含媒體片段、持續時間以及獲取它們的URL。

雖然HLS具有簡單、易擴展等優勢，但當被用于實時流式傳輸時，很容易出現高延遲問題。關于這點，我們將重點討論“wall-clock”或者“glass-to-glass”延遲，即從發生IRL事件開始到被終端用戶看到之前的時間。

在HLS中，延遲與正在使用的媒體片段的持續時間密切相關。通常情況下，提供可接受的流媒體體驗使用的片段持續時間最低界限為2s，這種情況下產生的延遲大約為10秒；而使用更長持續時間的片段設置的傳統HLS流，延遲可能會達到30秒以上。

在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延遲模式。有趣的是，這不是第一次嘗試著為低延遲HLS編寫規范?；趦赡甓嘀鞍l布的白皮書，視頻開發者社區使用的低延遲HLS開發規范也已經有一年多的時間了。表面上使用視頻開發者社區的方法更簡單，同時可部署更廣泛且高可用的技術。那么為什么Apple沒有使用視頻開發者社區的解決方案呢？讓我們來看看Apple所采取的方法與其它社區一直在做的工作有何不同。

Apple的低延遲HLS（ALHLS）

首先，讓我們看看Apple的低延遲HLS解決方案是如何工作的。你可以在這里觀看演示并閱讀說明。

（https://developer.apple.com/videos/play/wwdc2019/502/）?

1. 媒體分片

ALHLS會以持續時間為250-300ms的TS或CMAF塊的形式，生成部分媒體的分片片段。其中包含幾個完整的視頻或音頻幀，但這可能不包括完整的GOP（圖像組或一組序列獨立的視頻幀），Apple將這些稱為“部件”。

Apple已經為HLS播放列表格式引入了一種新排列方式，旨在允許這些部件被公布在實時HLS播放列表的頂部并允許客戶端下載它們。這意味著在編碼器輸出數據之后，播放器可以更快地獲得較小的幀組，而不是花費2到10秒的時間以等待幀準備就緒之后再下載它們。

有趣的是，根據規范，一旦這些部件處于“可被全速下載”的狀態，它們必須且只會被添加至播放列表中。至于為什么會這樣，我們會在后文對其進一步探索。

2. 推送分片

在最基本的層面，HLS依賴于通過輪詢播放列表文件來檢查新的可用段，結束一次輪詢之后是另一個用以檢索新片段的HTTP往返。而當需要低延遲傳送時，這些傳統HTTP請求的開支將成為決定“Well-Clock”延遲下限的重要條件。

Apple解決此問題的新方法是，使用HTTP/2推送那些在播放列表請求響應中較短的媒體“部件”。然而，這也意味著按照Apple的新方法，播放列表必須要被非常頻繁地取出，其頻率具體取決于目標延遲和部件持續時間，可能高達每秒3-4次。

3. 阻止播放列表請求

Apple添加的新功能之一是一種允許播放列表的HTTP請求保留一段時間，直到特定的片段或部分可用的模式。例如：播放一段內容的片段“20”，客戶端可以再次請求播放列表以進行片段的再現；而一旦片段“21”可用，那么播放器僅需“21”的響應即可播放片段。這樣做是為了如果播放器未能在前一個播放列表到達之后立即發出請求，播放器可以被允許以最短的時間請求新的播放列表（新的媒體片段）。

此功能與接下來的兩項功能都依賴于Apple在HLS中引入的一個新客戶端——服務器通信。Apple保留了所有查詢參數，_HLS從新的“Origin API”開始就可以被用于操縱播放列表生成的行為。

4.? 播放列表增量更新

HLS的一項令人頭疼的問題是播放列表的臃腫與代價。對于包括大型實時倒帶窗口的長時間運動流，再現播放列表中的段列表可能需要非常漫長且復雜的工作；即使使用gzip，每次再現HLS播放列表也會輕易得到數十萬字節或更多的數據。而如果每隔幾百毫秒就下載一個播放列表，那么其背后龐大且臃腫的數據處理量將成為一個棘手的問題。

為解決此項通病，Apple在本次HLS更新中啟用了一種可生成“delta”播放列表的方法，該方式允許段列表僅包含完整播放列表中的某些段；玩家一次請求完整的播放列表，此時播放列表的內部狀態將維持不變，較小的增量播放列表會被添加至播放列表中。這種僅包含若干最新片段與播放列表頂部多個文件的的增量播放列表與播放列表頭部的低延遲“部件”將一起組成新的播放列表以供用戶選擇。

我必須說，此項功能深得我心; 此解決方案經過深思熟慮，真正解決了HLS長期存在的問題。我希望Apple會將此功能應用在無低延遲要求的鏈路當中，因為播放列表的臃腫是一個亟待解決的問題。

5. 更快的碼率轉換

最后，Apple引入了一個小功能，允許特定節目的播放列表響應包含有關最新塊和可用于另一個節目片段的信息——理論上這允許播放器跳轉到另一個節目，無需請求制作完成的播放列表就能立即啟動切換。

從概念上講，這是一個很好的功能；但是現在的(ALHLS規范的當前版本似乎缺少足夠的細節使其可以被可靠地用在實際工作流程中（并且Apple公開的Demo版本實際上并不支持此功能）。值得注意的是，此功能似乎并非旨在允許播放器直接從一個節目跳轉到另一個多媒體文件的某個片段，而是通過請求阻止播放列表更新來優化播放列表請求，并利用HTTP/2推送盡可能獲取部件與該請求。

我認為通過更多的思考和設計，此方案可能非常有用，特別是如果(ALHLS還有一種方法可以在播放列表響應中推送CMAF流的初始化段，將會極大增加它的可用性。

如果你之前使用過HLS，那么講到這里你也許會覺得ALHLS有如此多的可調節組件，事實上的確如此。ALHLS是對HLS這一非常簡單的規范所設計的相當復雜的補充。為了從中獲益，開發者將不得不實現所有功能，包括一些我沒有提到的（如HTTP/2等）功能以實現符合預期的低延遲HLS流。至少在目前，開發者必須讓基于ALHLS實現的應用程序進入應用程序商店，經過蘋果的審核之后才能發布。蘋果會使用特殊標識符來標記這些應用程序清單。

這些變化使得ALHLS相對于傳統HLS方法的最大不同是ALHLS需要更多建立在播放列表生成過程和編碼器編碼過程之間的數據交換。從經驗上來看，此過程并不復雜：編碼器生成一個新片段并將其放入某個存儲（CDN或對象存儲），同時更新播放列表以指示新段可用。而現在，生成播放列表時ALHLS必須執行更多邏輯，包括在某些情況下，當組件處于可被下載狀態時掛起連接一段時間。

在我看來，ALHLS并不是一個糟糕的規范。盡管ALHLS非常復雜且包含眾多可調整的組件，但這并不會影響其功能與優勢。

一些保留或使用查詢參數來改變播放列表生成行為的解決方案并非我喜歡的方法，阻塞播放列表請求行為也是不可取的，而ALHLS也面臨諸多挑戰。

ALHLS實施面臨挑戰

查詢參數用法

2019年的大多數播放列表請求都將查詢參數作為其內容安全機制的一部分，這意味著對播放列表的所有URL中的一部分進行簽名可阻止未經身份驗證的用戶訪問內容。而向URL引入新的功能性查詢參數會為播放列表請求的簽名和緩存實現增加額外的復雜性，同時也為第三方播放器開發引入了新的挑戰。

阻止播放列表重新加載

阻止播放列表請求肯定會讓整個系統變得難以維護，并且對于當前記錄的超時現象至今仍無法得到合理解釋與有效解決方案。（在目標持續時間的3倍之后503）。除此之外，此策略會給開發者帶來一系列值得關注的針對Web和CDN的安全性與性能問題。

HTTP/2服務器大規模推送

眾所周知的是，采用Apple解決方案的的最大挑戰是強制使用HTTP/2。在公告中，Apple稱HTTP/2會“被CDN廣泛采用”。雖然從表面上看這是事實，但這種說法并不適用于Apple要求開發者所使用的一系列HTTP/2功能。

HTTP/2服務器推送主要通過允許服務器（在這種情況下是CDN中的節點）將對象推回客戶端而非客戶端主動請求來實現功能。如果我們希望通過主流CDN實現大規模應用，則需面臨以下兩個主要問題：

1. HTTP/2 推送在許多CDN上未能實現。雖然通用HTTP/2在主流廠商的CDN上具有較高的覆蓋率，但推送的實施程度卻很低。如果開發者希望實施大規模流媒體服務，其應該考慮的最重要因素之一就是采用 多CDN策略 ，但這的確不是一個好方案。

一般通過在原始響應里的Link 標頭中預裝的關鍵字來實現HTTP/2推送。這會導致CDN將其緩存中的兩個對象鏈接在一起并在合適的時機推送，但這也會為我們帶來新的問題……

2. 由于開發者現在必須實現將媒體與播放列表響應一起推送，因此開發者現在必須為播放列表請求和媒體請求使用相同的邊緣端點。因為HLS明確支持媒體段的絕對URL，這與以往的經驗不同。

對于許多供應商來說，這將是一個巨大的麻煩。由于不同廠商的需求各異，供應商花費數年時間建立了系統并分離播放列表和媒體交付過程，播放列表是小文本文件，可以進行gzip壓縮并頻繁更改；而媒體段則是大型二進制塊，一旦創建就永遠不會更改。播放列表快速且易于生成，而媒體片段則遠沒有那么容易。

視頻開發者社區低延遲HLS解決方案（LHLS）

現在讓我們來談談ALHLS與視頻開發者社區的LHLS解決方案有何不同。

HLS.js與包括Mux、JW Player、Wowza、Elemental和Akamai在內的各大企業一起合作開發出了LHLS這一解決方案并在過去一年多的時間探索使用HLS實現低延遲流媒體，關于正式標準的討論請參閱以下網站：Github問題 。LHLS最初的概念與術語來自2017年中期發布的Periscope博客文章，此文章描述了他們如何自主實現低延遲HLS流。你可以在這里閱讀這篇文章。?

這種方法實際上非常簡單（比ALHLS簡單得多）。除了一些簡單的新播放列表語義之外，LHLS使用與提供低延遲MPEG DASH-HTTP 1.1分塊傳輸編碼相同的策略。分塊傳輸編碼適用于此，因為分塊傳輸編碼允許開發者在完整響應可用之前開始將HTTP響應作為數據塊發送。

這是一項十分有用的成果，因為分塊編碼允許系統在編碼器生成視頻片段的同時發送Apple正在調用視頻片段的“部件”，在此之后返回到客戶端。播放器可以在獲得這些“部件”之后立即開始播放而無需等待完整分片可用。分塊傳輸模式的真正好處在于，其可以在絕大多數CDN上使用，這也意味著分塊傳輸比現在的HTTP/2推送擁有更廣泛的支持。

除了更加出色的可用性之外，與ALHLS相比，LHLS實際上允許一些輕度操作在客戶端設備上被執行。從表面上看，LHLS遵循傳統的HLS范例、輪詢播放列表更新與片段抓取；但由于LHLS能夠在片段編碼時將片段輪回，開發者實際上不必重新加載經常播放的播放列表；而在ALHLS，開發者仍需以每秒多次的頻率輪詢播放列表從而尋找可供使用的新部件，即使這些新部件會在清單請求之后被推送給開發者。

如果Apple將ALHLS（主要是delta播放列表）的一些概念帶到LHLS，那將是一件非常棒的事情——集二者之所長，我們會得到一個完美而強大的HLS解決方案。

那Apple為什么不參與社區呢？

如果LHLS如此出色并在視頻開發者社區中得到支持，為什么Apple不參與呢？這一問題的答案我們不得而知。蘋果公司決定忽視已有的社區或標準并不是一件新鮮的事情，但蘋果公司在過去幾年內已經表示他們已開始與視頻流媒體行業的其他企業保持一致。

盡管Apple在過去幾年從未采用MPEG DASH流媒體標準（盡管MPEG DASH參與了DASH行業論壇，但其依舊是HLS的競爭標準），但Apple已經開始支持fMP4和CMAF媒體塊。這種支持現在已經應用于絕大多數Apple設備，這意味著以一種方式（包括低延遲模式）為一種終端提供一組媒體段的夢想終于開始逐漸成為現實。

然而，隨著DASH對低延遲流媒體的LHLS風格分塊傳輸交付的持續標準化，現在看來Apple正通過強化ALHLS的應用，迫使我們回到封閉的交付堆棧策略。

對于許多HLS和視頻平臺供應商來說，最大的挑戰是強制性的HTTP/2推送，但我也強烈懷疑這就是Apple選擇讓所有開發者都按照他們期待的方向前進的關鍵。ALHLS和LHLS共同面臨的一大挑戰是帶寬估計問題，為了提供出色的流媒體體驗，開發者必須準確衡量并響應用戶帶寬的變化。從以往經驗上來說，估計用戶的可用帶寬非常簡單——開發者可以測量最后一個媒體段下載的時間長度并檢查該段的大小，通過一系列簡單的數學計算得到帶寬估算結果。

然而在分塊傳輸世界中，當開發者期望每個分片完全下載的時間與生成下載所花費的時間一樣時，估計帶寬并不是一件容易的事情。開發者需要測量備用帶寬的性能，同時提取播放列表或使用小參考文件，偶爾也需使用完整段或其他內容。

我從工作中得到的經驗是，Apple不想以上述任何麻煩的方式解決此問題，只留下允許AVPlayer（Apple的流式傳輸框架）能夠測量分塊傳輸響應的各個塊的性能。我懷疑Apple為了支持HTTP/2，它們決定不在設備上添加任何新功能到遺留的HTTP 1.1堆棧。

而現在來看，HTTP/2推送絕對不能有效解決此項問題。在現代瀏覽器或設備中，沒有允許開發者檢查HTTP/2推送響應的下載性能的API。而阻止播放列表請求會讓情況變得更糟：測量阻塞播放列表提取的性能以及段加載無法得到準確的測量結果，也無法將播放列表下載性能用作代理。我們必須假設Apple有一種方法可以在使用HTTP/2時，在自己的設備上測量下載性能，原因如下：

1. 這是Apple實現讓低延遲策略與自適應碼律一起工作的唯一方式，并且......

2. 相關內容在Apple的規范中被提及：?

“在將部分片段添加到播放列表時，它必須以與客戶端鏈接的全速下載?！?/span>

當然，還有一種看待蘋果如此策略的觀點是“經典的Apple策略”。雖然這些決定確實傾向于植根更多的物理硬件，但這并不意味著這是Apple第一次表達對于現有成熟技術的強烈反對意見——耳機插孔、USB-A、物理HOME按鍵……蘋果提出這樣的策略似乎已經見怪不怪。要知道蘋果是加密狗的最忠實支持者，或許在未來我們可以得到從ALHLS到LHLS的加密狗。

非Apple設備支持ALHLS

Apple的低延遲測試版目前僅與iOS設備兼容——即使MacOS上最新的Safari技術預覽也不支持ALHLS。但是，Apple設備實際上只是HLS生態系統的一小部分。

值得關注的是，支持HLS的非Apple規模龐大，例如經由HLS.js和Video.js這樣的HLS播放套件實現的視頻流播放，每天的規模高達數十億次。因此，讓我們假設視頻行業改變過去一兩年中一直追求的方法，只是遵循Apple的規范。

如果真是如此，那么ALHLS在現代瀏覽器或其他設備上易于實現嗎？恐怕并非完全如此。Apple選擇的技術（即HTTP/2）使得非Apple設備很難實現ALHLS，包括HLS.js，在自己的網站上用它來制作自己的開發者視頻。

HTTP/2是一項年輕的技術，使用它的工具非常有限，同時瀏覽器中的Web API也不夠成熟，無法在現有應用之上構建低延遲流技術。由于Apple可以利用私有API，因此很可能Apple最終能夠在Safari中實現良好的HTTP/2支持，但是為了支持和調試ALHLS的第三方應用，其他瀏覽器可能必須迅速作出改變。

那么，我們該何去何從？

顯然，我們確信Apple針對ALHLS與LHLS已經進行了大量調研。但是，在Apple的ALHLS規范準備就緒完成實現之前，還需應對并解決一些重大的挑戰。

視頻流媒體行業的客戶都渴望獲得低延遲解決方案，以便他們可以與Twitch或Twitter / Periscope等對手競爭。社區的LHLS策略是真實存在并可實現的，同樣也沒有什么可以阻止您在所有主流瀏覽器中以向后兼容的方式實現它。

然而，甚至是在iOS上，Apple的ALHLS顯然還需要幾個月的時間才能正式上線，最早也要到iOS13才有可能出現，考慮到主流CDN上HTTP/2推送的有限可用性，使用單邊主機名的要求以及Apple對ALHLS新應用的審核與驗證，我們不太可能在近期看到ALHLS的大規模部署。如果您希望在桌面或其他Web播放器上基于ALHLS獲得相同技術的相似體驗，那么您還必須等待Web播放器可支持更復雜的ALHLS部署。這使得供應商和客戶面臨更大的挑戰。供應商是繼續推進基于分塊傳輸的解決方案LHLS，還是全面支持Apple新提出的ALHLS？市場會在不久之后給我們這一問題的答案。

公平的說，業內很多人對Apple的ALHLS規范反響熱烈，但忽視社區開發的選項，同時推行過度面向未來的方法并不是什么好的方式。在某些情況下，比如Swift方面，Apple正在成為一個更加以社區為中心的組織。

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒及技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

掃描圖中二維碼，即刻了解更多大會講師及分享內容信息！

總結

以上是生活随笔為你收集整理的ALHLS：Apple低延迟HLS技术的全部內容，希望文章能夠幫你解決所遇到的問題。

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