一、前言
5G到來後使用者的網絡速度逐漸提高，同時使用者對直播延遲等播放體驗的要求也越來越高，在此背景下，優酷技術團隊結合業内主流的直播技術架構提出了兩種基于HLS（HTTP Live Streaming）的低延遲直播方案（Low Latency HLS），并且正式應用到了優酷直播業務。
業内目前主流直播低延時方案優缺點對比如下：
1、RTMP（Real-Time Messaging Protocol）
-
優點：
1）專門為流媒體開發的協定，對FLASH的支援較好；
2）延遲較低，一般在1-3秒；
-
缺點：
1）基于TCP（Transmission Control Protocol）傳輸，使用非公共端口（1935），可能會被防火牆攔截；
2）RTMP是Adobe的私有協定，有些裝置無法直接播放，可能需要借助于第三方子產品；
2、HTTP-FLV（Hypertext Transfer Protocol- Flash Video）
-
1）基于80端口，可以比較好的穿透防火牆；
2）可通過302跳轉靈活排程和負載均衡；
3）支援HTTPS（HyperText Transfer Protocol Secure）加密傳輸，并可相容多端；
-
1）由于它的傳輸特性，會讓流媒體資源緩存在本地用戶端，在保密性方面不夠好；
2）切換清晰度需要切換播放器執行個體，是以無法實作平滑切換，切換的過程中可能出現畫面斷層（畫面停在某一幀、黑屏加載等），在網絡抖動明顯的情況下體驗會更差；
3、HLS（HTTP Live Streaming）
-
1）主流平台對HLS的支援程度比較高，應用範圍較廣；
2）基于80端口，可避免防火牆攔截；
3）支援平滑切換清晰度；
4）CDN對協定的支援比較好；
-
1）延遲較高，一般在10秒以上；
2）直接通過減小GOP（Group of pictures）的方式降低延時時容易增加碼率；
4、RTP（Real-time Transport Protocol）
-
1）實時性較好，一般延遲在1秒以内；
2）基于UDP（User Datagram Protocol），傳輸效率較高；
-
1）常用于視訊會議等，拓展性一般。PGC（Professionally-generated Content）、OGC（Occupationally-generated Content）直播應用較少；
2）對高碼率的支援較差，一般為了流暢性會犧牲碼率；
通過比較上述直播方案的優缺點，可以看出HLS協定最适合直播場景。海外廠商對HLS的認可度也很高，蘋果也一直在大力推廣基于傳統HLS的低延遲直播方案，是以，優酷技術團隊選擇了LHLS方案。
二、為什麼會有延遲
想搞清延遲的來龍去脈，需要分析HLS的檔案結構：
簡單來說，HLS包含兩部分，m3u8檔案（playlist）和承載具體媒體内容
的檔案（ts、cmaf、fmp4等），用戶端根據m3u8的訓示下載下傳媒體内容并定時重新整理m3u8檔案獲得最新内容清單。
以下是一個包含多種碼率的master playlist（如果沒有多個碼率，這個m3u8 playlist可以沒有）：
以下是其中一個playlist的m3u8内容（如果隻有一個碼率，可以隻提供這個m3u8）：
以上出現的tag描述如下，還有很多tag，具體可以參考RFC：
1. playlist重新整理、播放機制
EXT-X-TARGETDURATION通常就是GOP（Group Of Picture）的大小，如果EXT-X-TARGETDURATION是4秒，那麼需要4秒編碼完成一個片段并更新playlist，用戶端采用輪詢方案來擷取下一版playlist， 輪詢的時機在(4,8)秒區間内，都将獲得僅包含第一份片段的playlist，并且playlist的請求和響應本身需要一個RTT（round-trip time）來回傳，在移動網絡上可能增加數百毫秒的延遲，之後才開始下載下傳檔案片段。擁有足夠多資料以後，播放器才能開始播放（有的播放器要緩存2-3個片段才開始播放，延遲可能超過12秒）。
2. CDN緩存機制
如下圖所示，源站已經前進到第四個片段，但是CDN邊緣節點還緩存着上一個版本（隻包含3個片段）的playlist，必須等檔案的TTL過期邊緣節點才會去擷取最新版本的清單，最差情況下又要多等待一個TTL。而這個緩存TTL也不能取消，如果每個端上的請求到達CDN邊緣節點時都去找源站要最新版本，源站就可能會被流量沖垮。
3、網絡因素
網絡因素也是造成延遲的其中一個主要因素，對延遲的影響大小與網絡狀況有關，具體從幾百毫秒到幾秒不等。
三、基于Apple規範的标準方案——從協定本身進行優化
為了将10-30的延遲降低到2秒以下，LHLS在Apple規範的基礎上提出了6點改進：
（1）減少片段釋出延遲
（2）優化片段發現機制
（3）消除片段請求時間
（4）m3u8采用增量更新機制
（5）加速不同碼率直播流切換速度
（6）基于網絡打分的動态起播政策模型
下面詳細介紹每個優化點：
為了減少釋出延遲，引入了EXT-X-PART和EXT-X-PART-INF tag，示例m3u8如下所示，也就是原來需要生産完成整個ts才釋出出來，現在通過part的形式分小段釋出出來。
采用阻塞式m3u8加載（EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES）用戶端可以根據收到的片段數和EXT-X-MEDIA-SEQUENCE基數，計算出下一個片段的序号，然後直接找伺服器請求對應的m3u8，
GET
https://example.com/live.m3u8?_HLS_msn=1803（該請求表示，當值班流中出現1803的ts的時候，停止阻塞，傳回m3u8内容）,結合1，允許服務端下發part的話，則發送請求GET
https://example.com/live.m3u8?_HLS_msn=1803&_HLS_part=0&_HLS_push=1（該請求表示，當直播流中出現1803的第一部分_HLS_part=0的時候就停止阻塞，傳回m3u8）,具體過程是這樣：
m3u8裡面包含EXT-X-MEDIA-SEQUENCE，用戶端可以根據收到的片段數和EXT-X-MEDIA-SEQUENCE基數，計算出下一個片段的序列号，然後直接找服務端請求對應的m3u8：
上述請求表示當直播流中出現1803的ts的時候，停止阻塞，傳回m3u8内容。
結合1的内容，允許服務端下發片段part的話，則請求如下：
上述請求表示當直播流中出現1803的第一部分(_HLS_part=0)的時候就停止阻塞，傳回m3u8内容。
上述請求的最後一部分——_HLS_push比較微妙，也是這次HLS協定更新的一個很大的改變，要求伺服器支援HTTP/2，主要使用多路複用和server push等能力，請求playlist的時候就直接将片段/part的内容跟随push下來，減少一個RTT延遲。
經過上述三點改進後，可以看到相比之前的舊版HLS方案，現在可以在很低的延遲下就獲得首幀資料開始解碼播放，圖上示例的part時長是0.5秒，網絡傳輸0.5秒的話，理論上用戶端觀察到的延遲可以低到1秒左右，part長度可以進一步縮小，比如0.2秒，以獲得更低的延遲。
因為m3u8的請求可能高達每秒鐘3-4次，為了進一步減少網絡傳輸資料大小，引入了增量更新機制，
其中EXT-X-SERVER-CONTROL: CAN-SKIP-UNTIL=36.0告訴用戶端，比目前直播前沿資料早36秒以上的資料會被忽略 。這個數值要求是EXT-X-TARGETDURATION的6倍以上。用戶端就可以通過請求的參數_HLS_skip=YES告訴服務端下發增量更新内容。
這個功能在一些場合比較有用，有些直播流允許使用者往前回看一段時間，是以它們的m3u8檔案會很大，上百K都有可能。使用增量更新機制能極大減小傳輸量。
實作方案是在m3u8的最後帶上EXT-X-RENDITION-REPORT（如：GET
https://example.com/1M/live.m3u8?_HLS_report=/2M/live.m3u8），告訴用戶端其它碼率直播流的目前進展(片段序号和part序号)和加載位址，當用戶端決定要切換到另一個直播流上的時候，它不用發起一個新的請求，隻要直接在原來的連接配接上請求即可（不過在蘋果的參考實作上并沒有實作這部分内容）。
根據使用者的信号強度、出口帶寬、丢包率等參數确定一個網絡打分模型并基于該打分模型對使用者的網絡進行量化（如：網絡較好：3分、網絡一般：2分、網絡較差：1分、無網絡：0分等），根據網絡的量化結果确定起播位置，如：3分（網絡較好）時從倒數第3個part起播，2分時從倒數第5個part起播等，該動态政策模型生效後可很好的平衡延遲與卡頓的體驗，經驗證相較于HLS直播，LHLS在卡頓率無明顯增加的情況下，延遲可降低50%-80%。
四、社群LHLS方案——結合http chunked進行優化
在蘋果推出基于HLS的LHLS低延遲草案之前，各主要技術社群就已經有過類似探索，它的方案的主要技術點是基于HTTP/1.1的分塊傳輸編碼Chunked Transfer Coding機制（RFC 2616），分塊傳輸編碼主要用于發送未知長度、用戶端請求時還未完全準備好的資料，用一個HTTP 響應資料簡單說明如下：
.01
上面這個過程可以看出，分塊傳輸編碼天生适合用于傳輸“還未到來的”HLS片段資料。社群LHLS方案對标準HLS做的核心變化是提前幾個片段時長就将片段網址添加到播放清單中。舉例來說，當直播流正在啟動并且流的第一幀從推流端到達伺服器時，伺服器将立即釋出包含三個(數量可配置)片段的HLS媒體播放清單。當用戶端收到播放清單時，它們會請求第一個ts分片（有的是直接請求全部三個分片，經驗證該方式可能會造成帶寬競争，故對此作了深度改造）。伺服器使用分塊傳輸編碼來響應每個請求。對于第一段的請求将首先獲得在請求到達時在該段中累積的資料，但是之後的資料（在該段的剩餘持續時間内）将在真正到達時候才傳輸給用戶端。當接收完第一片ts資料後直接發送第二片的請求，以此類推。
在播放清單可用之前就廣播片段的好處是它消除了由于用戶端播放清單輪詢頻率和CDN高速緩存中的播放清單TTL而導緻的播放清單延遲問題。由于片段在它們實際包含媒體之前幾秒鐘被廣播，如果播放清單可以被CDN聚合請求，就不會影響延遲。用戶端會提前幾秒鐘獲知即将到來的片段并請求它們，這樣就可以在伺服器獲得資料後立即接收資料。
五、LHLS技術方案對比
1、标準LHLS方案：
（1）優勢：基于Apple規範設計的LHLS低延時方案既支援Apple标準規範，又支援靈活擴充，便于使用者播放體驗的優化（尤其是卡頓與延遲的優化），同時支援海外推廣（目前海外主要認可該種方式）；
（2）劣勢：要用到HTTP/2的一些新特性（如：多路複用和server push等），是以需要CDN端支援HTTP/2。隻支援HTTP/1.1的廠商就受到了限制，不能發揮全面的優勢；
2、社群LHLS方案：
（1）優勢：基于http chunked分塊傳輸編碼機制，原生支援預先未知filesize的流傳輸，實作起來較友善；
（2）劣勢：海外推廣認可度存疑；
新方案的實作不僅解決了現有方案的痛點，在不遠的未來還可能孵化出全新的直播業務形态。優酷技術團隊會持續在直播技術優化上發力，在提升優酷視訊的播放體驗的同時，推動整個行業的技術疊代和發展。