MPEG-DASH 详解，以及它与 HLS 的对比

如果你在 Netflix 或 YouTube 上打开 Chrome DevTools，看到对以 .mpd 与 .m4s 结尾的文件的请求，你正看到 MPEG-DASH 在运作。那份 XML 文件是清单，.m4s 文件是短小的分片 MP4 音视频片段，你的浏览器正在通过普通 HTTP 实时把它们拼接起来。

DASH 是 HLS 的开放标准表亲。Apple 拥有 HLS，MPEG/ISO 标准组织拥有 DASH。HLS 使用 .m3u8 文本播放列表，DASH 使用 .mpd XML 清单。HLS 最初强调 H.264，DASH 则从未偏好任何编解码器。两套协议从不同起点解决同一个问题，2026 年一家深思熟虑的流媒体服务两者都发布。MPEG-DASH——Dynamic Adaptive Streaming over HTTP——是 ISO/IEC 23009-1 标准，用于把视频作为一连串短小 fMP4 分片交付，由 XML 清单（.mpd）描述，并通过普通 HTTP 拉取。

本指南将走完 .mpd 究竟包含什么、DASH 的 Period / AdaptationSet / Representation 层级如何运作、DRM 在何处出现、DASH 与 HLS 的优劣对照，以及当你试图把这种码流保存到硬盘时会发生什么。

核心要点 {#key-takeaways}

• MPEG-DASH 是用于自适应 HTTP 流媒体的 ISO 开放标准——ISO/IEC 23009-1。HLS 则是 RFC 8216。
• .mpd 清单是 XML，不是纯文本。它描述 Period、AdaptationSet 与 Representation——一种严格层级，播放器在启动时和每次切换档位时都要遍历。
• DASH 设计上编解码器无关。 H.264、H.265、VP9、AV1、AAC、Opus——清单声明编解码器字符串，由播放器负责解码。
• 媒体分片是分片 MP4（.m4s），与现代 HLS 使用的 CMAF 分片相同。一套字节即可服务两种协议。
• DRM 使用 MPEG Common Encryption（CENC），使一份加密文件可在 Widevine、PlayReady 或 FairPlay 之间通用——由客户端解密模块决定。
• Apple 平台不原生支持 DASH。 iPhone、iPad、Safari 和 Apple TV 都要求 HLS——只发 DASH 行不通。
• Netflix、YouTube、Disney+、Hulu、Max 都同时发布 DASH 与 HLS；Apple TV+、iTunes、Twitch 则只发 HLS。

简明解释

先把缩写搁一边。流媒体服务面对同一个问题：把一段长视频通过混乱的连接发给观众，让他们能瞬时跳转、在播放中适应带宽变化，并通过通用 HTTP 廉价地完成这一切。整个行业的解法是把视频切成短分片、写一份列出这些分片的清单、让播放器按顺序按需拉取。HLS 用文本播放列表做这件事；DASH 用 XML 清单做这件事。工作相同，“文书”不同。

从播放器视角看，DASH 的方式与 HLS 几乎一致。启动时拉取一份小清单、了解可用的画质与音轨、按带宽与视口选定档位，再拉一连串短分片喂给解码器。画质切换在分片之间发生。直播通过让清单随时间增长来实现。跳转瞬时完成，因为播放器直接跳到覆盖目标时间戳的那一分片。

两种协议在用户层面的差别虽小但真实存在。HLS 播放列表是纯文本；DASH 清单是 XML。HLS 分片历史上是 .ts（MPEG-2 传输流），现在通常是 fMP4；DASH 分片一直是 fMP4，扩展名 .m4s。组织方面也不同：HLS 由 Apple 创立与维护，DASH 出自 MPEG 与 DASH 行业论坛，是一项无单一厂商主导的开放 ISO 标准。配套入门请参阅HLS 详解，从头到尾了解 .m3u8 播放列表的样貌。

DASH 究竟如何运作

一段 DASH 流由一份 XML 清单加上一堆分片 MP4 分片构成，全部通过普通 HTTP 提供。 与 HLS 同形，但在每一层格式不同。

.mpd 清单

DASH 播放器最先拉取的是 Media Presentation Description——即 .mpd。与 HLS 的纯文本播放列表不同，这是一份具有定义模式的 XML 文档。以下是一个轻微修剪的示例：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     type="static"
     mediaPresentationDuration="PT1H30M"
     minBufferTime="PT2S"
     profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period id="0" start="PT0S">
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true"
                   startWithSAP="1" maxWidth="1920" maxHeight="1080">
      <Representation id="v1" codecs="avc1.640028"
                      width="1920" height="1080" bandwidth="5000000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="v1/init.mp4"
                         media="v1/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
      <Representation id="v2" codecs="avc1.4d401f"
                      width="1280" height="720" bandwidth="2800000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="v2/init.mp4"
                         media="v2/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
    <AdaptationSet mimeType="audio/mp4" lang="en">
      <Representation id="a1" codecs="mp4a.40.2" bandwidth="128000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="a1/init.mp4"
                         media="a1/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

每个属性都有具体含义。type="static" 标记此为点播（直播是 type="dynamic"）。mediaPresentationDuration="PT1H30M" 是 ISO 8601 时长。每个 Representation 携带编解码器字符串和带宽预算。SegmentTemplate 是魔法所在：DASH 不像 HLS 那样逐个列出分片 URL，而是让清单声明一个 URL 模式，播放器实时计算 URL。

Period、AdaptationSet 与 Representation

清单内部的严格层级是 DASH 的概念核心：

• Period —— 时间轴上的一段连续切片。多数电影只有一个 Period；广播商使用多个 Period 来插入广告或章节边界。
• AdaptationSet —— 同一内容的可互换编码集合，运行时可彼此替换。典型的电影有一个视频 AdaptationSet、一个或多个音频 AdaptationSet（每语言一个）以及一个或多个字幕 AdaptationSet。
• Representation —— 一个具体的编码。1080p H.264 @ 5 Mbps 是一个 Representation；720p H.264 @ 2.8 Mbps 是另一个；720p VP9 @ 1.5 Mbps 又是另一个。播放器在每个 AdaptationSet 内挑一个 Representation，并可在同一 AdaptationSet 内的任意分片边界切到另一个。

这种三级模型比 HLS 那种扁平的”档位 + 分片”方式更结构化，正是 DASH 在可扩展性上胜出的原因：多音轨、变速轨、缩略图轨、按 Period 插广告等都能干净地接入，而无需发明新的清单语法。

分片与初始化

一个 Representation 的字节有两种。初始化分片 是一个包含 moov 盒子的小型 fMP4 文件——编解码器参数、轨道元数据、解码器配置。播放器对每个 Representation 拉取一次。媒体分片 是真正的音视频，每片通常 2 到 6 秒，视频轨在关键帧边界切开，使播放器能从任意分片的起点开始解码。

当清单设置 startWithSAP="1" 时，每个分片都以 Stream Access Point 开始——这是 DASH 中相当于 HLS 的 EXT-X-INDEPENDENT-SEGMENTS 标志的概念，保证分片可独立解码。没有这个保证时，后续分片可能依赖前面的分片，这样切档就不安全。由于 SegmentTemplate URL 是基于模式的（v1/seg-$Number$.m4s），清单可以用几百字节 XML 描述一部 90 分钟电影。在时长不均时可改用 SegmentTimeline。

Common Encryption（CENC）

DASH 的 DRM 故事走的是 MPEG Common Encryption（CENC）——ISO/IEC 23001-7。CENC 用 CTR 模式 AES-128 加密媒体分片本身，再声明哪些 DRM 系统可以签发该密钥。在 .mpd 里你会看到这样的 ContentProtection 元素：

<ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc"
                   cenc:default_KID="34e5db32-8625-47cd-ba06-68fca0655a72"/>
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
  <cenc:pssh>AAAAW3Bzc2gAAAAA...</cenc:pssh>
</ContentProtection>
<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
  <cenc:pssh>AAACfHBzc2gAAAAA...</cenc:pssh>
</ContentProtection>

第一个块声明 CENC 下的默认密钥 ID。第二个是 Widevine 的 UUID；第三个是 PlayReady 的。你浏览器的内容解密模块读取与其支持的 DRM 相匹配的那一块，将其中嵌入的 PSSH（Protection System Specific Header）数据连同许可证请求一并发送给服务的许可证服务器，并取回解密分片所需的内容密钥。完整图景参阅Widevine 与 PlayReady 如何为高级码流把关。FairPlay 在 DASH 中历来支持稀少——FairPlay 为 HLS 而设计——但 CMAF + CBCS 加密让 FairPlay-over-DASH 的跨 DRM 方案在少数平台上技术上成为可能。

设计上编解码器无关

HLS 最初偏好 H.264（早期 Apple 设备别的解不了），新增编解码器要经过多年的规范过程。DASH 从未挑选编解码器——清单只声明编解码器字符串（avc1.640028、hev1.1.6.L150.B0、vp09.00.50.08、av01.0.05M.08），播放器自检解码器是否支持。这就是 YouTube 能比 Apple 端等价 HLS 支持早数年通过 DASH 发布 AV1 的原因。由于 DASH 播放器只需理解清单层，VidMost 能解析 .mpd、按 SegmentTemplate URL 取每个 fMP4 片段并重封装，而不必关心里面是什么编解码器。

DASH 与 HLS：一场诚实的对照

DASH 与 HLS 以不同取舍解决同一个问题。两者并非有绝对高下。 下面在真正重要的几个维度上分别为它们辩护。

清单格式

DASH 的 .mpd 是带定义模式的 XML——可扩展（新特性走新元素、由模式校验、旧播放器忽略未知部分），但冗长。HLS 的 .m3u8 是带 #EXT-X- 标签的纯文本——一眼可读、易于 grep。结构与机器校验上 DASH 胜出；人类可读性上 HLS 胜出。

延迟

两者起步时都是秒级到数十秒延迟。两者都推出了低延迟扩展：LL-HLS 使用部分分片、阻塞式播放列表重载和预加载提示（Apple 把更早的 HTTP/2 推送设计替换为 EXT-X-PRELOAD-HINT）；LL-DASH 使用 chunked-transfer-encoded 分片以及 CMAF Live 剖面。两者在生产环境中都瞄准 2 到 5 秒的玻璃到玻璃延迟。要追求亚秒级延迟则要切换到 WebRTC。

编解码器支持

DASH 从第一天起就编解码器无关。H.264、H.265、VP9、AV1、AAC、Opus、FLAC、AC-4——清单声明编解码器字符串，由播放器决定。HLS 起步时只支持 H.264，因为初代 iPhone 硬件如此要求。Apple 一直在稳步扩展支持：2017 年起支持 fMP4 上的 H.265，2018 年起支持 Dolby Vision 与 HDR10，自 iPhone 15 代起支持 AV1。现代 HLS 不再锁死 H.264，但协议的编解码器历史比 DASH 慢了一步。

DRM

两者都依赖基于 AES 的分片级加密，但上层的 DRM 系统不同。DASH 通常使用 CENC，搭配 Widevine 与 PlayReady——一份加密文件能为两者所用，因为内容密钥相同，仅许可证请求格式不同。HLS 历史上使用 FairPlay Streaming（Apple 专属），并越来越多地通过 CMAF + CBCS 加入 Widevine。一旦服务切换到 CMAF，同一套加密分片可同时服务两种清单类型和三大主流 DRM 系统。

Apple/iOS 支持

iOS、iPadOS、Safari 与 Apple TV 上 HLS 是强制的。任何 Apple 平台都不原生支持 DASH。 这是 DASH 与 HLS 策略中唯一最大的决定性因素。Safari 中的 DASH 播放只能借助 Media Source Extensions 加上 shaka-player 或 dash.js 之类的 JavaScript 垫片，即便如此也覆盖不到所有 iOS 边缘情况（AirPlay、锁屏控制、画中画）。任何要面向 iPhone 的服务都必须发布 HLS。只发 DASH 行不通。

CDN 兼容性与 CMAF 收敛

两种协议都是纯 HTTP。任何能提供静态文件的 CDN 都能提供 DASH 或 HLS 流——CDN 成本与配置实质相同。过去十年最重要的进展是 DASH 与 HLS 现在共享分片字节。CMAF —— Common Media Application Format，ISO/IEC 23000-19 —— 定义了一种同时满足 DASH 与现代 HLS 的 fMP4 剖面。流媒体服务可以一次编码为 CMAF 分片，再写一份 .mpd 与一份 .m3u8 同时指向完全相同的 .m4s 文件。这正是 2026 年 YouTube、Netflix、Apple 与多数托管视频服务商在做的事。

2026 年谁发布什么

• Netflix —— Web、Windows、Android、智能电视和主机端以 DASH 为主；Safari 与 iOS 以 HLS 兜底。
• YouTube —— Web 与 Android 上 DASH，搭配 VP9 / AV1；iOS、Safari、AirPlay 及大多数 TV 应用上 HLS。
• Apple TV+、iTunes Store —— 只发 HLS。
• Twitch —— 自 2014 年弃用 RTMP 播放栈起，直播和点播都只用 HLS。
• Disney+、Hulu、Max、Amazon Prime Video —— DASH 或 HLS，视客户端而定，往往同一套 CMAF 分片挂在两份清单下。

HLS 拥有 Apple 设备，其余市场与 DASH 共享。大多数主流服务两者都支持，否则就要把一部分受众留在桌上。

想要把视频保存下来意味着什么

理解了 DASH 的运作，下载这件事的实际难题就具体起来了。HLS 用户在尝试保存码流时遇到的每一个问题，在 DASH 上都会遇到，往往更糟：

• 浏览器的”另存为”只会拿到 .mpd。 那是 XML 清单。它不含任何视频字节。在 VLC 里打开它，只有在网络会话仍然有效、分片 URL 尚未过期时才能播放。
• DASH 分片是 .m4s 文件——每个 Representation 一个 init 分片加上数十乃至上百个媒体分片。每个都是无用的分片 MP4 块。要得到可播放的成品，你必须按序拉取 init 与每个媒体分片再重新封装。（如果你不确定 .m4s 里到底是什么，参阅容器与编解码器。）
• 你得解析 XML、按 SegmentTemplate URL 拼路径再重封装。 这意味着写代码理解 $Number$、$Time$、$RepresentationID$、$Bandwidth$ 占位符，拼接 URL，在不暴击 CDN 的前提下并发拉取，再把字节喂给 ffmpeg 或 mp4box。这不是周末脚本，而是真正的软件工程。
• 档位选择很重要。 选错 Representation 就只下到了 1080p 电影的 480p 副本。令牌也会过期——许多 .mpd 与分片 URL 都带签名，几分钟内就失效。

VidMost 把这些都处理掉。它解析 .mpd、挑出最高画质的视频与音频 Representation、并发下载每个分片，并把 CMAF 片段重新封装成一个干净的 MP4。对于受 DRM 保护的 DASH 码流（常见的 Widevine + PlayReady 组合），VidMost 内置的 Widevine L3 支持在 L3 可播放的范围内工作——实际画质上限由服务和 DRM 级别决定，高级平台通常把 L3 码流限制在 480p–720p。你粘贴一个 URL，得到一个 MP4。

常见误区与误解

关于 DASH 有几个反复出现在论坛话题里的混淆。值得澄清。

• “MPEG-DASH 是 Google 的东西。” 不是。DASH 是 MPEG / ISO 开放标准（ISO/IEC 23009-1），由 DASH 行业论坛驱动——一个包括 Adobe、Microsoft、Netflix 与 Qualcomm 的联盟。Google 参与了开发并在 YouTube 上使用它，但没有任何单一厂商拥有该规范。
• “DASH 更新所以更好。” DASH（2012）比 HLS（2009）新，但”更好”取决于你的平台组合。如果受众在 iPhone 上，HLS 凭强制规则胜出。如果受众在 Android 和需要最大编解码灵活性的智能电视上，DASH 胜出。多数服务两者都发布。
• “.mpd 就是视频。” 不是。它是清单。真正的视频在清单引用的 .m4s 分片里。
• “如果一个站点用 DASH，我的 HLS 播放器就放不了。” 对原生播放器为真。但 shaka-player、dash.js、hls.js、video.js 等大多数现代 Web 播放器会通过 Media Source Extensions 把分片喂给浏览器里的 video 元素，从而兼容两者。
• “DASH 一定意味着 DRM。” 不是。许多 DASH 流不加密：直播事件、教育平台和大多数免费 YouTube 内容。DRM 是通过 ContentProtection 元素声明的可选层。

结语

DASH 是 HLS 的”平行宇宙双生子”。两者都把视频切成短分片、由清单描述、通过普通 HTTP 发布。它们的差异——XML 与纯文本、ISO 标准与 Apple 规范、编解码器无关与受历史影响——在行业内部有意义，对观众则鲜有影响。真正重要的是，从全球各大片方拿到内容授权的流媒体服务都已落定在这两种协议上，并越来越多地聚拢到同一套 CMAF 分片之下、挂上两份清单。一旦你能识别 .mpd 请求、理解 Period / AdaptationSet / Representation 层级，现代流媒体的奇怪行为就不再神秘——全都是同一个循环：取清单、选档位、取分片、解码、重复。如果你宁愿完全跳过协议层、直接保存视频，VidMost 可以处理 HLS、MPEG-DASH、fMP4、CMAF 及受 DRM 保护的码流。

相关阅读

• 在线视频究竟是怎么播放的 —— 从摄像头到屏幕的整体流媒体流水线。
• 什么是 HLS 和 M3U8？ —— 兄弟协议的端到端讲解。
• 画质为何会在播放中变化 —— 每个 DASH 和 HLS 播放器内部的 ABR 逻辑。
• 视频容器与编解码器 —— .m4s 分片里到底是什么。
• 什么是 DRM 受保护内容？ —— Widevine、PlayReady 与 FairPlay 如何为那些你无法直接保存的加密档位把关。