HTTP 視訊串流

最後更新: 2022-11-26 21:49:55 +0800 +0800
tags: Http | Streaming | Video
原文以英文撰寫。您正在閱讀AI翻譯版本。

HTTP 視訊傳遞的範圍從可搜尋的單一檔案，到由短媒體片段組成的自適應序列。HTTP 傳輸表示與驗證器；容器組織帶有時間資訊的軌道；編解碼器則對音訊與視訊取樣進行編碼。將這些層分離，可以更容易診斷範圍處理、快取與播放失敗問題。

漸進式下載 #

瀏覽器可以透過 <video> 元素播放自包含的媒體檔案。瀏覽器可以從一般的 GET 要求開始，也可以只要求一個位元組範圍：

http 
GET /media/talk.mp4 HTTP/1.1
Host: media.example
Range: bytes=0-

當所選表示支援範圍要求時，伺服器會回傳 206 Partial Content、所選區間以及完整表示的長度：

http 
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Range: bytes 0-1048575/73400320
Content-Length: 1048576
ETag: "talk-v3"

一個可滿足的單一範圍必須恰好包含 Content-Range 所描述的位元組。無法滿足的範圍會回傳 416 Range Not Satisfiable，並帶有 Content-Range: bytes */73400320。忽略 Range 的伺服器可以透過 200 OK 回傳完整表示，但不得將完整回應本文標記為部分回應。

驗證器與快取重新驗證 #

範圍要求只適用於單一表示版本。傳送強 ETag 或 Last-Modified，並允許用戶端在恢復下載或搜尋時使用 If-Range：

http 
Range: bytes=32243712-32955076
If-Range: "talk-v3"

如果驗證器仍然相符，伺服器可以回傳要求的範圍。否則，伺服器會回傳目前的完整表示，以避免合併兩個編碼版本中的位元組。一般條件式要求使用 If-None-Match 或 If-Modified-Since，並可能收到 304 Not Modified。根據內容的可變性定義 Cache-Control：以內容定址的片段可以是不可變的，而直播內容的資訊清單需要較短的 freshness 時間。

編解碼器、容器、檔案與串流 #

H.264、AV1、AAC 或 Opus 等編解碼器會轉換取樣資料。ISO Base Media File Format 或 WebM 等容器會儲存一個或多個已編碼軌道、時間戳記、索引與中繼資料。一個檔案可以包含多個編解碼器，同一個編解碼器也可以出現在多個容器中。

透過範圍要求傳遞的有限 MP4 檔案屬於漸進式下載，即使播放在下載完成前就已開始。直播來源在擷取時是連續的，但 HTTP 傳遞仍會公開有限資源，例如持續移動的資訊清單與媒體片段。對於漸進式 MP4，應將初始化中繼資料與索引中繼資料放在用戶端可先於媒體位元組取得的位置，通常透過 fast-start 處理將 moov 中繼資料移到檔案開頭附近。

HLS 與 DASH #

HTTP Live Streaming（HLS）使用媒體播放清單與多變體播放清單。MPEG-DASH 使用 Media Presentation Description。兩者都描述多個表示版本與可定址的媒體片段。播放器會估算輸送量與緩衝區狀態，然後選擇其編解碼器、尺寸、位元率與裝置能力符合目前條件的表示版本。

不同表示版本之間的片段邊界應保持對齊，使切換時能維持時間軸。較小的片段可以降低直播延遲，但會增加要求、資訊清單與 CDN 的負擔。低延遲模式會加入更短的部分片段，並要求來源站到播放器之間具有更嚴格的時間控制；但兩種協定都不會消除編碼器與播放器的緩衝。

CDN 會將資訊清單與片段作為一般 HTTP 資源進行快取。使用帶有版本的片段 URL、正確的 Content-Type、驗證器與快取指令。避免使用會無意中分割快取鍵的 Cookie 或查詢字串。直播播放清單必須足夠快地過期，以顯示新片段；已完成的隨選視訊片段則可以使用較長的不可變生命週期。

預先載入、可搜尋性與延遲 #

HTML 的 preload 屬性是一項提示，可取值為 none、metadata 或 auto。使用者設定、節省資料政策、自動播放規則與實作決策都可能覆寫它。應用程式不得假設 preload="auto" 會下載整個檔案。

搜尋需要將播放時間映射到可存取的位元組或片段。容器索引支援以範圍為基礎的檔案搜尋；HLS 或 DASH 時間軸會識別對應的片段。直播視窗可能捨棄舊片段，因此超出所公告視窗的搜尋必須失敗，或移動到最早的可用位置。

啟動延遲包括資訊清單或中繼資料擷取、連線建立、初始片段傳輸、解碼，以及播放器的安全緩衝區。端對端直播延遲還包括擷取、編碼、封裝、CDN 傳播與播放緩衝。應測量每個階段，而不是將所有延遲歸因於網路頻寬。

伺服器檢查清單 #

  • 對漸進式檔案一致地支援 HEAD、完整 GET、有效的單一或多段位元組範圍，以及 416 回應。
  • 在節點之間保留表示驗證器，並回傳精確的 Content-Length、Content-Range 與媒體 Content-Type 值。
  • 授權每個範圍與片段要求；快取的部分回應不得繞過完整物件的存取政策。
  • 測試接近開頭與結尾的搜尋、並行範圍、過期的 If-Range、CDN 快取命中、頻寬變化，以及直播播放期間的資訊清單重新整理。

當單一表示與一般搜尋可以滿足產品需求時，使用漸進式檔案。當用戶端需要自適應位元率、直播發佈、多種表示版本或以片段為導向的 CDN 工作流程時，使用 HLS 或 DASH。

參考資料 #

評論

在 GitHub 上閱讀或評論（發表評論需要登入）