M3U8 的前世今生
从一手规范了解 HLS 如何使用 UTF-8 M3U 播放列表，以及播放列表、加密与自适应播放各自负责什么。
引言
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