HLS直播協議在B站的實踐

　　 01 背景

　　在音影片直播領域，各種新技術與新標準層出不窮，直播場景也愈發複雜。為了更好的面對未來的挑戰，我們需要亟需下一代直播協議來支援這些新標準的落地，B站在此方面進行了探索，率先在國內推行HLS(fmp4)協議在國內直播領域大規模落地。本期我們主要分享HLS在B站落地方面的工程實踐經驗。

　　 02 現狀與問題

　　傳統直播技術使用的傳輸協議主要是RTMP/HTTP-FLV。其中RTMP是有Adobe公司開發的，雖然不是國際標準，但在當年Flash流行的年代影響下，成為了業界事實標準。

　　基於RTMP/FLV協議的直播，是國內比較成熟的直播架構體系，在行業中已經投入使用近10年。一個典型的直播架構圖如下：

　　基於RTMP/FLV協議從技術上也比較成熟，整個生態支援度非常完善。但從長遠考慮，RTMP也存在各種無法解決的問題，這讓我們對未來相容性有很大的擔憂。

　　首先，RTMP/FLV標準已經超過10年沒有更新，在相容性層面已經面臨著很大挑戰，比如對h265的支援，當前業界是透過hack的方式進行追加，但如ffmpeg都需要打補丁之後才能支援，各種系統工具支援性較差。甚至也會出現各家hack的方式不同，導致系統無法對接。如果涉及到出海的業務，由於無法對齊國際標準，難以與海外公司展開技術合作。

　　其次，主流的瀏覽器原生不支援FLV，需要在web端進行一次額外的轉封裝操作，會有額外開銷，在使用者裝置負載較高時，可能會影響觀看體驗。

　　最後，在直播場景中，非常適合p2p的應用，可以極大降低頻寬成本，但在流式協議上構建P2P成本較高，通常也會犧牲標準的相容性。

　　在對現有主流的直播協議做了充分調研後，HLS(fmp4)協議進入了我們的視野。相比較上述RTMP協議的一些缺點，HLS(fmp4)出現完美解決上述這些問題。

　　fmp4標準一直處於MPEG標準的維護中，對各種編碼器和新技術， 如AV1，VVC支援度非常完善。主流瀏覽器也支援fmp4格式，省去了中間轉封裝的開銷，可以減少網頁端處理壓力。

　　其次，CDN部署更容易，因為HLS是基於檔案傳輸，傳統的靜態檔案CDN只需要少量配置更改就可以支援相關業務，對傳輸內容不敏感。

　　另外，fmp4在DRM支援性上非常好，可以對版權內容做更好的保護。

　　最後，利用切片檔案實現P2P較為方便，檔案P2P方案在業界成熟， 也可以做到比較好的分享率，在直播場景中P2P可以有效節省頻寬成本。

　　綜合以上各方面，我們確定了要將HLS(fmp4)協議作為支撐未來新技術落地的主要方向。

　　 03 HLS直播協議簡介

　　HLS全稱為 HTTP Live Streaming，是由蘋果公司提出基於HTTP的流媒體網路傳輸協議。其基本原理是將直播的流式資料透過切割成一個個小檔案，將這些小檔名記錄成到一個索引檔案中，播放器先請求索引檔案，然後再取到對應的切片的檔案，透過請求一個個小檔案實現連續的播放。

　　流程如下圖：

　　一個典型的索引檔案(也稱為M3U8播放列表)如下：

　　隨著直播流的進行，播放列表中的切片檔案會進行不停更新，播放器不停的請求索引檔案和切片檔案下載到媒體資料，進行解碼播放，這樣就實現了畫面直播。

　　HLS協議主要有兩種版本，mpegts版本和fmp4，顧名思義，他們主要的區別在於封裝容器的不同，前者基於mpegts封裝，mpegts因為有出色的糾錯能力，常用於廣播電視衛星傳輸。而後者在2017年8月正式進入ISO RFC8216標準，fMP4(分段式MP4)的封裝格式正式被HLS支援。

　　fMP4不是一種新的封裝格式，而是在傳統MP4格式基礎上增加若干新特性。傳統的MP4因為檔案結構所限，所有的索引和資料都是放在一起的，在播放時兩者缺一不可，無法實現流式直播。fMP4主要是將MP4檔案切割成更細的粒度，播放器可以載入一小部分資料之後就可以進行播放，這樣就可以實現直播。

　　下圖展示了MP4與fMP4的內部結構的區別：

　　 04 直播架構設計

　　4.1 生產架構設計

　　在直播生產架構設計上，首先要保證穩定性和可靠性。我們重點做了以下幾點：

　　在生產端使用了叢集化進行切片的生產, 切片會在記憶體和檔案物件儲存進行雙寫

　　熱備能力, 隨時可以調整內部回源鏈路, 防止鏈路故障

　　從記憶體到持久化物件儲存, 分級回源策略

　　可分散式部署, 利用HTTP302進行分散式排程

　　由於HLS協議問題，對磁碟IO要求非常高，我們使用Linux系統提供的記憶體對映盤去寫檔案，無論是寫檔案還是檔案回源的讀取速度都非常理想。但由於記憶體只能存有很少的切片，所以能儲存的切片比較少，只用作實時直播回源，同時切片也會非同步寫入檔案物件儲存，用來做直播回放，在回源鏈路發生故障時，會自動進行降級，利用檔案物件儲存暫時對外提供回源服務。

　　4.2 回源架構設計

　　在回源架構方面，我們設計了一套動態回源方案。CDN在回源時需要根據我們的回源服務進行回源地址的查詢，相比較固定的回源配置，我們可以實時上下線某些節點，也可以減少回源鏈路上面的延遲，在排程上比較靈活，同時容災能力也極大提升。

　　除了提供動態回源查詢服務之外，我們也充分利用了http302特性，允許使用http302進行回源跳轉，在故障發生時可以做到自適應降級。

　　 05 HLS啟播最佳化

　　在HLS標準當中，每一個單獨的切片檔案都是一個GOP，但直播場景中使用者推流的GOP大小都不固定，如果完全按照標準去實現的話就可能會導致切片長度過大，客戶端下載時間過長，從而導致啟播時間比較久。

　　在我們的實踐中，首先採用了1s長度的切片，可以儘可能縮短因為產生切片所造成延遲，這樣會出現一個問題，就是每一個切片可能不是一個GOP， 如果按照預設的客戶端拉播放列表中最後三個切片進行播放，一旦倒數第三個的第一幀不是關鍵幀就會導致啟播很慢或無法啟播。在HLS標準中#EXT-X-START:TIME-OFFSET=0標籤會告知客戶端，從列表的第一個切片開始播放。

　　此時我們只需要保證列表的第一個切片的第一幀為關鍵幀，客戶端就可以快速載入到關鍵幀。

　　此外，利用了fmp4和CMAF(一種基於mp4上的封裝技術，與fmp4非常類似)的封裝特性，在一個切片檔案中可以進行了更小粒度的封裝(chunk)，使得客戶端在下載幾幀資料後就可以開始進行解碼播放。如上圖，對於第一個切片檔案，客戶端只需要下載第一個chunk拿到第一幀，就可以完成啟播。這樣就完成了不在破壞標準相容性的基礎上實現了啟播的最佳化。

　　由於採用了1s一個切片的方式，相比較RTMP/FLV來講，整體延遲只增加了1s，是一個可以接受的範圍。相比較傳統的HLS來講，首幀提速2-3倍，配合客戶端的追幀策略也可以使延遲得到很好的控制。

　　 06 直播回放實現

　　由於HLS協議，是將流媒體進行切片，我們只需要將切片的儲存時間延長，就可以讓使用者訪問到之前的內容。具體的實現方法是，在直播生成索引檔案的過程中，只需要同時生成對應的時間戳的索引檔案，例如直播時索引檔案叫index.m3u8，此時同時生成一份utc.m3u8，在使用者選擇回放時服務端會返回對應時間點的索引檔案。這樣就完成了直播回放的功能。除了需要檔案儲存更長的時間外，其他無需改動，實現比較容易。

　　除了用作直播回放之外，更可以用做錄影進行長久儲存，對稽核相關業務也可以很好的支援，同時省卻了專門維護錄影業務的麻煩。

　　 07 回源預熱最佳化

　　HLS與RTMP/HTTP-FLV在回源上最大的不同在於，HLS是短連結, RTMP/HTTP-FLV是長連結。兩種各有優缺，長連結只建立一次連結，開銷較低，但在抗網路抖動性比較差, 遇到抖動時間短，且抖動強的狀況，連結可能就直接斷開，就會造成使用者觀看黑屏，但對於短連結，由於可以快速重試，時間短而劇烈抖動，可以比較快速進行恢復，某些情況下甚至使用者端可能不會有感知到卡頓，但短連結需要頻繁請求響應，對伺服器CPU消耗較高。

　　HLS在回源鏈路上，全鏈路都支援了HTTP1.1，保證底層共享長連結，避免頻繁TCP建聯的開銷。另一方面，我們利用了CMAF和HTTP Chunk傳輸特性，在服務端允許檔案的邊寫邊發，在切片還未完全落盤之前就可以允許CDN提前回源，存幾幀資料就發幾幀，直到指定切割點後，資料傳送完成之後，斷開請求，CDN已經儲存了這份檔案的快取，這時切片服務再去更新M3U8播放列表。當客戶端播到最新一個分片時，CDN由於提前進行過回源，已經快取了對應檔案。這種資源預熱策略，尤其是針對頻繁請求小分片的檔案，可以有效提升回源質量。

　　 08 展望總結

　　得益於底層fmp4提供的豐富的擴充套件性，我們正在技術和業務上做更多的嘗試，如直播DRM的應用，自適應清晰度，數字水印，杜比世界/全景聲直播等，後續也會有相關文章介紹，請持續關注我們。

　　出於對新技術和新業務的探索，B站前幾年在業內率先引入SRT協議，如今我們在業內大規模落地HLS(fmp4)，從直播上行到下行完成了技術探索，為我們後續技術演進做了深厚的積累，也標誌我們可以嘗試慢慢擺脫老舊的RTMP協議限制，真正的擁抱下一代直播技術！