M3U8 的前世今生

依據一手規範說明 HLS 如何使用 UTF-8 M3U 播放清單，以及播放清單、加密與自適應播放各自負責什麼。

2025年8月2日

引言

HLS 廣泛用於直播和隨選視訊，但播放清單的副檔名本身不是串流協定。.m3u8 是常見的 UTF-8 文字播放清單檔案；HLS 規範以擴充 M3U 語法為基礎，定義播放清單標籤及相容用戶端如何請求媒體資源。本文會區分播放清單與協定，並修正常見的歷史與技術誤解。

但你是否好奇過：M3U8 到底是什麼？它從哪裡來？為什麼是它，而不是別的格式，成了串流媒體世界的「通用語言」？

今天，就讓我們一起回溯 M3U8 的前世今生。

一、起源：從 M3U 說起（1990 年代）

HLS 播放清單使用擴充 M3U 語法。M3U 在 HLS 出現前已作為文字播放清單格式使用；現有一手資料無法證明它由特定播放器發明，因此本文不將其起源歸功於任何一款軟體。

1.1 Winamp 與 M3U 的誕生

Winamp 是支援 M3U 播放清單的知名播放器之一，但這不足以證明它發明了 M3U。M3U 是純文字清單，可包含本機路徑或網址，也可用 #EXTINF 等標籤攜帶選用資訊。RFC 8216 沒有定義「M3U」名稱的展開形式，因此本文不把任何一種詞源說法當成定論。

一個最基本的 M3U 檔案長這樣：

#EXTM3U
#EXTINF:233,周杰倫 - 稻香
D:\Music\稻香.mp3
#EXTINF:257,陳奕迅 - 浮誇
D:\Music\浮誇.mp3

簡單得不能再簡單：一行註解標記時長和標題，下一行寫檔案路徑。就這麼樸素的設計，卻奠定了日後一個龐大生態的根基。

1.2 M3U 的局限

通用 M3U 檔案曾使用不同的編碼和慣例。HLS 的要求更明確：RFC 8216 規定播放清單必須使用 UTF-8 編碼，而且不能包含位元組順序標記（BOM）。.m3u8 通常用來表示 UTF-8 播放清單；播放清單本身不包含媒體，也不負責網路傳輸。

M3U 播放清單可以引用本機檔案，也可以引用遠端資源。HLS 為媒體片段、變體串流、加密訊號和相關播放資訊定義了專用標籤。播放、位元率調適和網路傳輸由相容的播放器及媒體服務完成，不是由副檔名單獨提供。

這些局限在本機播放音樂的年代並不是大問題，但隨著網際網路視訊時代的到來，一切都變了。

二、轉折：蘋果與 HLS 的登場（2009 年）

蘋果公司於 2009 年推出 HTTP Live Streaming（HLS）。HLS 使用擴充 M3U 播放清單格式，並由規範定義 UTF-8 編碼及協定專用標籤。

2.1 iPhone 催生的需求

2007 年，初代 iPhone 發布。賈伯斯著名地拒絕在 iPhone 上支援 Adobe Flash——而 Flash 當時是網頁視訊的主要載體。這意味著蘋果需要找到一種不依賴 Flash 的串流媒體方案，讓視訊能在 Safari 瀏覽器和 iOS 裝置上流暢播放。

2.2 HTTP Live Streaming（HLS）的誕生

2009 年，蘋果在 WWDC 上正式推出了 HTTP Live Streaming（HLS） 協定。HLS 的核心設計理念非常優雅：

不發明新的傳輸協定，直接複用 HTTP。

具體來說，HLS 的工作流程是：

將一整段視訊切割成若干個短小的片段（通常是 2-10 秒一個 .ts 檔案）
產生一個索引檔案，記錄每個片段的位址和時長
播放器按順序逐個下載並播放這些片段

播放清單仍是文字文件。.m3u8 副檔名慣例與 UTF-8 文字有關；更精確地說，HLS 使用擴充 M3U 播放清單，「M3U8」不是另一種媒體編碼或傳輸協定。

2.3 為什麼選擇 M3U？

HLS 規範在擴充 M3U 播放清單結構上定義協定語意。實務上要注意：

足夠簡單——純文字，任何編輯器都能開啟和修改
結構可讀——播放清單是文字，可用編輯器檢查
依規範擴充——#EXT-X-STREAM-INF 與 #EXT-X-KEY 等標籤都有明確語意
透過 HTTP 交付——HLS 用戶端透過 HTTP(S) 請求播放清單和媒體資源；伺服器設定、CORS、MIME 類型、快取與授權仍須正確處理

三、M3U8 的關鍵設計：為什麼它能成功？

HLS 使用播放清單描述資源。播放清單本身不會執行以下播放決策；這些工作由相容用戶端和媒體服務完成。

3.1 自適應位元率（ABR）

HLS 多變體播放清單可以列出不同位元率和解析度的變體串流：

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
480p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/playlist.m3u8

多變體播放清單負責宣告可用的呈現版本。播放器可能依據自適應邏輯、測得的交付狀況及設定上限進行選擇或切換；播放清單不能保證特定畫質或一定會切換。

3.2 基於 HTTP 的傳輸

HLS 播放清單和媒體資源透過 HTTP 或 HTTPS 交付。常見的 Web 伺服器和 CDN 可以承載這些檔案，但服務仍須正確封裝媒體、設定回應標頭、確保 URL 可存取，並配置合適的快取和授權規則：

使用一般 HTTP 請求——用戶端不需要專用傳輸連線
可使用現有交付基礎架構——前提是來源站和 CDN 設定正確
HTTPS 可保護傳輸過程——但不會讓受限串流變成公開資源，也不會取消授權要求
快取策略可設定——直播與隨選播放的播放清單和媒體片段可能需要不同的快取策略

3.3 媒體片段設計

HLS 可使用 MPEG-2 Transport Stream 或 fragmented MP4 等規範支援的媒體格式。片段邊界、時間戳和關鍵影格會影響連續播放與跳轉；片段不一定適合作為獨立視訊檔案播放。請檢查播放清單和媒體格式，不要假設所有 HLS 片段都是 .ts：

分段交付——用戶端可隨播放進度請求媒體資源
由播放清單引導讀取——序號、時長、位元組範圍和初始化資訊都會影響所需資源
跳轉取決於媒體和關鍵影格——僅有播放清單項目不能保證任意位置都能成功 seek

3.4 HLS 加密訊號不等於 DRM

RFC 8216 定義了透過 #EXT-X-KEY 在 HLS 播放清單中標記 AES-128 加密媒體片段的方式。播放清單會向相容用戶端說明媒體受到何種保護；M3U8 文字本身並不是加密機制：

#EXT-X-KEY:METHOD=AES-128,URI="https://example.com/key.php",IV=0x1234567890abcdef
#EXTINF:10.0,
encrypted_segment_001.ts

金鑰交付與存取控制必須由服務設定。HTTPS 能保護傳輸過程，但單靠 HTTPS 並不能讓金鑰成為私密內容。HLS AES-128 加密不等同於 FairPlay 或 Widevine 等多 DRM 系統；這些系統各有平台與金鑰管理需求。

四、正確理解 HLS 版本號

#EXT-X-VERSION 是播放清單的相容性版本值，並不存在稱為「HLS v1」到「HLS v8」的產品發布序列。Apple 的歸檔歷史將 Internet-Draft 修訂版、相容性版本值及 Apple 用戶端發布版連結起來。理解這個差異有助於判斷用戶端需要支援哪些標籤。

參考	含義	不應據此推斷
`#EXT-X-VERSION`	播放清單宣告的相容性版本	它不是 HLS 產品代際編號或發布日期
RFC 8216（2017）	已發布的 HLS 協定規範，定義協定版本 7	它沒有提供市場佔比，也不代表所有用戶端支援相同功能
Apple 功能歷史	Internet-Draft 修訂、相容性值與 Apple 用戶端發布版之間的歷史對照	不應簡化成虛構的「HLS v1–v8」年度時間軸

MPEG-DASH 是另一種自適應串流系統，擁有自己的 MPD 清單格式和用戶端生態。比較 HLS 與 DASH 時，應交代目標裝置和服務環境；市場佔比或普遍原生支援等說法需要附上有日期和統計口徑的證據。

比較問題	HLS	MPEG-DASH
播放清單/清單檔	擴充 M3U 文字播放清單	XML Media Presentation Description（MPD）
哪些因素決定能否播放？	裝置、作業系統、瀏覽器、播放器、媒體封裝和 DRM	裝置、作業系統、瀏覽器、播放器、媒體封裝和 DRM
合理的比較方式	在目標用戶端測試指定串流	在目標用戶端測試指定串流

五、M3U8 在現代網際網路中的應用

5.1 視訊點播（VOD）

HLS 隨選視訊工作流程可以將來源媒體封裝為多種呈現版本，並在播放清單中列出這些版本。相容播放器可能依自身的調適邏輯切換呈現版本；實際流程取決於服務和用戶端實作。

5.2 直播串流

在 HLS 直播中，伺服器會依照協定的直播播放清單規則更新媒體播放清單。依播放清單類型而定，較舊的項目可能會隨新媒體產生而移出滑動視窗。用戶端則根據其重新載入時序和播放邏輯更新播放清單。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:5.009,
live_2680.ts
#EXTINF:5.006,
live_2681.ts
#EXTINF:4.998,
live_2682.ts

注意這裡沒有 #EXT-X-ENDLIST 標籤——這告訴播放器「直播還在繼續，請繼續重新整理取得新片段」。

5.3 低延遲場景（LL-HLS）

Low-Latency HLS 加入旨在降低直播延遲的機制，包括部分片段、阻塞式播放清單重新載入和預載入提示。實際端到端延遲取決於編碼器、封裝器、來源站/CDN、播放器和網路設定；不能保證固定達到「2–5 秒」。

部分片段（Partial Segments）——不等整個片段編碼完畢就開始傳輸
預載入提示（Preload Hints）——提前告知播放器下一個片段的位址
阻塞式重新載入——允許播放清單請求等待指定更新

5.4 播放清單中的廣告相關訊號

HLS 可透過定時中繼資料等標籤表達與廣告時段相關的資訊，伺服器端也能重寫播放清單或拼接媒體；實際廣告插入方式取決於系統實作。僅憑以下示意標籤，不能證明廣告已插入或能在用戶端正常播放：

#EXT-X-DATERANGE:ID="ad-1",START-DATE="2025-01-01T00:00:00Z",DURATION=30.0,X-AD-URL="https://ads.example.com/v1"
#EXTINF:10.0,
ad_segment_001.ts
#EXTINF:10.0,
ad_segment_002.ts
#EXTINF:10.0,
ad_segment_003.ts

廣告播放清單、媒體片段、計時和用戶端事件都必須依具體實作驗證；HLS 播放清單格式本身並未提供完整的廣告系統。

六、M3U8 的未來

6.1 CMAF：統一容器格式

Common Media Application Format（CMAF） 允許 HLS 和 DASH 共用相同的視訊片段格式（fMP4），這意味著內容提供商只需編碼一次，就能同時服務兩種協定的播放器。蘋果在 HLS 中已經支援 fMP4 容器，逐步取代傳統的 TS 容器。

6.2 更低的延遲

HLS 後續功能應以已發布規範和目標用戶端實作為準；不要將其他傳輸技術的進展視為 HLS 已承諾的功能。

6.3 AI 與智慧串流媒體

未來的自適應演算法可能結合 AI 預測使用者網路狀況，提前調整位元率和緩衝策略，進一步提升觀看體驗。

6.4 新編解碼器支援

編解碼器能否使用，取決於已發布的 HLS 規範，以及具體裝置、作業系統、瀏覽器和播放器。不要假設 .m3u8 播放清單本身就能讓某種編碼格式相容；應針對目標播放鏈路逐項確認。

七、總結

M3U 是文字播放清單格式；HLS 是使用擴充 M3U 播放清單，並規定用戶端如何讀取媒體資源的串流協定。釐清兩者關係，有助於檢查檔案、理解加密訊號和比較用戶端支援。以下參考資料沒有提供全球市場佔比數據，因此本文不宣稱任何百分比。

參考資料

RFC 8216：HTTP Live Streaming：UTF-8 播放清單要求、#EXT-X-VERSION 與 HLS 金鑰訊號。
Apple：HTTP Live Streaming：HLS 工作流程與開發者資源。
Apple 封存：HLS 功能發布歷史：歷史草案修訂和相容性值。

實質複核日期：2026-10-04