HTTP Live Streaming 詳解

HTTP Live Streaming 是 Apple 實現的基於 HTTP 的自適應比特率流通信協議,使用 HLS 可以直播(live)和點播(on-demand)音、視頻。由於 HLS 採用了 HTTP 協議,使用普通 web 服務器和內容分發網絡(Content Delivery Network,簡寫 CDN)即可。HLS 專爲可靠性而設計,可以根據網絡狀況動態播放當前可播放最佳質量音視頻。

目前,iOS、macOS、tvOS、PC、Android 等均支持 HLS 協議,HLS 是應用最爲廣泛的流協議。

HLS 支持以下功能:

  • 直播(Live broadcasts)和點播(video on demand,簡寫 VOD,即預錄內容)。
  • 具有不同比特率的多個備用流。
  • 根據網絡變化對流進行智能切換。
  • 數據加密和用戶身份驗證。

下圖顯示了 HTTP Live Stream 的組成部分:

Apple 提供了幾個支持 HTTP Live Streaming 的框架,包括AVKitAVFoundationWebKit

1. 術語

在學習 HLS 之前,需要先了解幾個相關概念。

1.1 MPEG

動態圖像專家組(Moving Picture Experts Group,簡稱 MPEG)原本是一個研究視頻、音頻編碼標準的組織,成立於1988年,致力於開發視頻、音頻壓縮編碼技術。現在我們所說的MPEG泛指該小組制定的一系列視頻編碼標準正式審覈程序。至今已制定了MPEG-1、MPEG-2、MPEG-3、MPEG-4、MPEG-7、MPEG-21、MPEG-H、MEPG-DASH等標準。

1.2 MPEG-2

MPEG-2 由 ITU 定義,也稱爲 H.222 / H.262,是運動圖像和相關音頻信息的通用編碼標準,它描述了視頻、音頻有損壓縮的組合方法,該方法允許使用當前可用的存儲媒體和傳輸寬帶來存儲、傳輸電影。常用在數字衛星電視、數字有線電視,以及 DVD 視頻光盤中。

MPEG-2 標準作爲 ISO / IEC 12818 的一部分發布。MPEG-2 包含多個標準,每個部分涵蓋整個規範的某個方面。例如,Part 1 系統描述音視頻同步和多路複用;Part 7 部分描述了有損數字音頻壓縮的音頻編碼標準,稱爲高級音頻編碼(Advanced Audio Coding,簡稱 AAC)。AAC 被設計爲 MP3 格式的後繼產品,在相同的比特率下,其聲音質量通常比 MP3 更好。

1.3 MPEG-4

MPEG-4 定義了音視頻數字數據的壓縮方法。於1998年推出,並指定了一組音頻、視頻編碼格式的標準和相關技術。MPEG-4 由 ISO/IEC MEPG 組織在 ISO / IEC 14496 標準發佈。MPEG-4 標準壓縮的數據可用於網絡流媒體、CD 分發、電話、可視電話和廣播電視。

與 MPEG-2 類似,MPEG-4 也包含多個部分,每個部分涵蓋整個規範的某個方面。例如,Part 2 描述了視覺數據的壓縮格式;Part 10 描述了視頻信號的壓縮格式,在技術上與 ITU-T H.264 標準相同。

1.4 H.264

H.264 被稱爲高級視頻編碼(Advanced Video Coding,簡稱 AVC,也稱爲 H.264、MPEG-4 Part 10、MPEG-4 AVC),是一種面向塊、基於運動補償的視頻編碼標準。在2004年時 H.264 已成爲高精度視頻錄製、壓縮、發佈最常用格式之一。第一版標準的最終草案於2003年5月完成。

H.264 / MPEG-4 AVC 項目的目的是爲了創建一個更佳的視頻壓縮標準,在更低的比特率下依然能提供良好視頻質量,同時不會大幅度增加設計的複雜性。廣泛用於網絡流媒體、各種高清晰度電和衛星。

1.5 H.265

H.265 被稱爲高效率視頻編碼(High Efficiency Video Coding,簡稱 HEVC),是 MPEG-H 規範的第二部分。H.265 是一種視頻壓縮標準,被視爲 H.264 標準的繼任者。與AVC相比,HEVC 在相同視頻質量下數據可以壓縮 25% 至 50%,或相同比特率下可顯著提高視頻質量。HEVC 支持高達 8192*4320 的分辨率,HEVC 的高保真 Main10 配置文件已經集成到幾乎所有支持的硬件中。HEVC 正在與 IETF 的 AV1 編碼格式競爭。

1.6 AC-3

AC-3 是音頻編碼(Audio Coding)的縮寫,是杜比數字音頻編碼器(Dolby Digital audio codec)的同義詞。除 Dolby TrueHD 外,音頻均爲有損壓縮。通常,AC-3 幾乎只用於視頻,並且通常需要特殊許可的軟件或硬件才能進行編碼、解碼。除非用於電影、DVD和藍光項目,否則沒有理由使用AC-3。

1.7 AAC

AAC 被稱爲高級音頻編碼(Advanced Audio Coding),用於有損數字音頻壓縮的音頻編碼標準,被設計爲 MP3 格式的繼任者。在相同比特率下,AAC 通常比 MP3 可以獲得更好的聲音質量。AAC 是 iOS、Android 等系統的默認或標準音頻格式。

2. HLS 架構

這一部分介紹 HLS 主要組件如何協同工作以傳遞流媒體。從概念上講,HTTP Live Streaming 包含三部分:服務器組件、分發組件和客戶端軟件。

在常見配置中,硬件編碼器接受輸入的音視頻,將其編碼爲 HEVC 視頻、AC-3 音頻,輸出片段化(fragmented)MPEG-4 文件或 MPEG-2 傳輸流,分段器(segmenter)軟件將 stream 分割成系列短媒體文件,然後將短媒體文件放在 web 服務器上。segmenter 還會創建並維護一個包含媒體文件列表的索引文件(index file)。索引文件的 URL 在 web 服務器上發佈,客戶端讀取索引文件,按順序讀取列出的媒體文件並播放,各片段間沒有任何暫停或間隔。

2.1 服務器組件

服務器組件負責獲取媒體輸入流並對其進行數字編碼,將其封裝成適合傳輸的格式,併爲分發做準備。

對於直播,服務器需要媒體編碼器(可以是現有的硬件),以及一種將編碼的媒體分割成片段並保存爲文件的方法,該方法可以是由 Apple 提供的 media stream segmented,也可以是第三方解決方案。

2.2 分發組件

分發系統是 web 服務器或 web 緩存系統,通過 HTTP 將媒體文件和索引文件傳輸到客戶端。HTTP Live Streaming 協議不需要對服務器模塊進行任何自定義即可用於傳輸內容,且 web 服務器只需要很少的配置。要實際使用 HTTP Live Streaming,需要將 HTML 頁面或 app 作爲接收器,還需要使用 web 服務器,以及將實時流編碼爲 HEVC 或 H.264視頻、 ACC 或 AC-3 音頻的分段 MPEG-4 媒體文件。

2.3 客戶端軟件

客戶端軟件負責確定所請求媒體資源類型、下載所需資源、重新組合資源,最後將媒體連續的呈現給用戶。目前,Windows 10、macOS 10.6+、iOS 3.0+、Android 4.1+ 等均原生支持 HLS,大部分瀏覽器也支持HLS。點擊這裏可以查看各瀏覽器起始支持 HLS 版本。

客戶端軟件使用標誌流媒體位置的 URL 獲取 index file,index file 指定可用媒體文件位置、解密密鑰和可選流。選定流後,客戶端按順序下載可用媒體文件,每個文件包含一段連續的 stream。當擁有足夠數據後,客戶端播放重組的 stream。

客戶端負責獲取解密密鑰、身份認證,根據需要解密媒體文件。

這些過程會一直持續,直到在 index file 遇到 EXT-X-ENDLIST tag。如果沒有 EXT-X-ENDLIST tag,則 index file 是直播的一部分。在直播期間,客戶端會定期拉去 index file 的新版本,並在新版本的 index file 中查找新的媒體文件和加密密鑰,並將這些 URL 添加到隊列。

3. 部署基礎的 HTTP Live Stream

部署 HTTP Live Stream 需要滿足以下三點:

  • HTML 網頁或客戶端作爲接收者。
  • Web 服務器或 CDN 作爲主機。
  • 一種將媒體文件或直播流編碼爲包含 HEVC 或 H.264 視頻、 AAC 或 AC-3 音頻的 MPEG-4 片段文件的方式。儘管也可以將 MP3 音頻或 MPEG-2 用於傳輸 H.264 視頻,但通常不推薦使用這些格式。

3.1 創建 HLS 媒體接收器

分發 HTTP Live Streaming 媒體最簡單的方法是使用 M3U8 播放列表文件作爲視頻源,創建包含 HTML5 <video> 標籤的網頁,對於不支持 HTML5 視頻元素的瀏覽器,或不支持 HTTP Live Streaming 的瀏覽器,可以在 <video> 和</video> 標籤之間添加降級代碼。例如,可以使用 QuickTime 插件回退到漸進式下載或 RTSP 流。以下示例顯示了常見 HTML 網頁代碼:

<html>
    <head>
        <title>HTTP Live Streaming Example</title>
    </head>
    <body>
        <video controls="controls" autoplay="" src="https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8" type="video/x-m4v">
        </video>
    </body
></html>

如果你在開發 iOS app,則可以使用AVKit框架直接播放:

    func playHLSVideo() {
        guard let videoURL = URL(string: "https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8") else {
            return
        }
        let player = AVPlayer(url: videoURL )
        let playerViewController = AVPlayerViewController()
        playerViewController.player = player
        present(playerViewController,
                animated: true) {
                    playerViewController.player?.play()
        }
    }

3.2 配置服務器

普通的 web 服務器即可提供 HTTP Live Streaming。對服務器進行常規配置,然後將要提供文件的 MIME 類型與文件擴展名相關聯。下表顯示了 HTTP Live Streaming 的 MIME 類型:

擴展名 MIME 類型
.m3u8 vnd.apple.mpegURL
.ts video/MP2T
.mp4 video/mp4

如果 web 服務器需要遵守 MIME 類型約束,則可以提供以 .m3u 結尾 MIME 類型爲 audio/mpegURL 的文件,以實現兼容性。

索引文件通常很長,經常被重新下載,但由於他們是文本文件,因此可以非常高效地進行壓縮。通過啓用 M3U8 索引文件的實時 gzip 壓縮來減少服務器開銷。HTTP Live Streaming 客戶端會自動進行解壓縮。

對於點播類型視頻,索引文件格式如下:

#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://example.com/movie1/fileSequenceA.ts
#EXTINF:10.0,
http://example.com/movie1/fileSequenceB.ts
#EXTINF:10.0,
http://example.com/movie1/fileSequenceC.ts
#EXTINF:9.0,
http://example.com/movie1/fileSequenceD.ts
#EXT-X-ENDLIST

各標記用途如下:

EXTM3U:表示此播放列表是擴展爲 M3U 的文件列表。通過將第一行標記改爲 EXTM3U,可以將這種類型的文件與基本的 M3U 文件區分開。所有 HLS 播放列表都必須以此標籤開頭。

EXT-X-PLAYLIST-TYPE:提供使用於整個播放列表的文件是否可變信息。此標籤內容爲 EVENT 或 VOD。如果標籤爲 EVENT,則服務器不能改變、刪除索引文件的任何部分,但可以向尾部拼接。如果標記爲 VOD,則播放列表不可更改。

EXT-X-TARGETDURATION:指定媒體文件最大時長。

EXT-X-VERSION:表示播放列表文件的兼容版本。播放列表媒體和服務器必須符合該版本協議的 IETF Internet-Draft 最新規定。

EXT-X-MEDIA-SEQUENCE:要播放的第一個媒體文件序列號。播放列表中的每個媒體文件 URL 都有一個唯一的整數序列號,URL 的序列號是其前面的 URL 序列號加一,序列號與文件名無關。

EXTINF:記錄標記,描述緊隨其後的 URL 所標識媒體文件。每個媒體文件 URL 之前都必須有一個 EXTINF 標記。該標記包含一個 duration 屬性。duration 屬性是一個整數或浮點數,指定媒體段的持續時間(以秒爲單位),該值必須小於等於目標持續時間。

始終使用浮點 EXTINF 時長(協議版本 3 中增加的),這將使客戶端在流中搜素時減少出現錯誤。

EXT-X-ENDLIST:標記媒體文件結束,不會再添加新的媒體文件到播放列表。

上面的 VOD 播放列表使用完整路徑描述媒體文件。儘管可以使用絕對路徑,但更推薦使用相對路徑。相對路徑是相對於播放列表文件的位置,使用絕對路徑會導致更多文本,且相對路徑比絕對路徑更可移植。下面是使用相對路徑的同一播放列表:

#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
fileSequenceA.ts
#EXTINF:10.0,
fileSequenceB.ts
#EXTINF:10.0,
fileSequenceC.ts
#EXTINF:9.0,
fileSequenceD.ts
#EXT-X-ENDLIST

直播和 event session 播放列表會有所不同,具體可以查看:Live Playlist (Sliding Window) ConstructionEvent Playlist Construction

對於點播來說,整個媒體文件已經存在。因此,索引文件是靜態的,只會被下載一次。對於直播來說,索引文件不斷更新,當新媒體資源可用時,會替換掉原來媒體資源。對於 event session 來說,新媒體文件可用時會拼接到索引文件結尾,與點播不同的是,不能移除索引文件任何內容,只能向文件尾部拼接新的媒體片段,event session 允許用戶跳轉到已經播放過片段任一時刻,即等效於點播+直播,常用於演唱會、運動會。

3.3 驗證流

Apple 提供的 HTTP Live Streaming Tools 包含 Media Stream Segmenter、Media File Segmenter、Media Subtitle Segmenter、Variant Playlist Creator、Media Stream Validator、 HLS Report、ID3 Tag Generator 幾種工具。

Media Stream Validator 工具模擬 HTTP Live Streaming 會話,並驗證索引文件和媒體片段是否符合 HTTP Live Streaming 規範。其會執行多次檢查以確保流傳輸可靠,如果發現錯誤、問題,會在診斷報告中列出。在提供流服務前,請始終運行驗證程序。

mediastreamvalidator 命令如下:

$ mediastreamvalidator https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8

上述命令執行完畢後,會產生一個 validation_data.json 的診斷報告,但其內容並不方便閱讀,可以使用下面的 python script 將其轉換爲 html 格式:

$ hlsreport.py validation_data.json

生成的 validation_data.html 如下圖所示:

mediastreamvalidator 命令即可以驗證 HTTP URLs 的資源,也可以驗證本地資源。

使用 mediastreamvalidator 命令時如需幫助,輸入mediastreamvalidator -h命令即可查看文檔。

此前,HLS 缺點一直是高延遲。但 Apple 在 WWDC 2019 發佈了新的解決方案,可以將延遲從8秒降低到1至2秒。具體可以查看Introducing Low-Latency HLS

參考資料:

  1. HTTP Live Streaming
  2. Validating HTTP Live Streams
  3. How is AAC better than AC3?
  4. What is the difference between AAC and AC3 in quality? How can it be determined?

本文地址:https://github.com/pro648/tips/wiki/HTTP-Live-Streaming-詳解
歡迎更多指正:https://github.com/pro648/tips/wiki

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章