企业官网建设流程全解析

DASH这个词，做Web的看到第一反应多半是Python的数据可视化框架dash，输入localhost:8050就能画图表那种；但如果你跟我一样常年泡在流媒体服务端和播放器开发里，DASH代表的是Dynamic Adaptive Streaming over HTTP，中文一般叫“动态自适应流传输协议”。从2012年成为MPEG国际标准开始，它已经在视频网站、直播平台、OTT机顶盒里默默扛了十几年，现在几乎你能想到的主流点播和直播场景，背后都跑着这套逻辑。

这篇文章我不打算写成一个干巴巴的标准文档，而是用实际开发者的视角，把DASH的起源、MPD文件到底怎么解析、以及围绕它的那些开源项目串一遍。无论你是刚接手播放器开发的初级工程师，还是想给现有视频系统加自适应码率能力的后端，都应该能从里面拿到可以直接用的东西。

1. DASH的起源：从“被Apple牵着走”到国际标准

1.1 流媒体传输的进化：渐进式下载为什么不够用

要理解DASH为什么会出现，得先回头看流媒体传输的苦日子。早年的网络视频根本没有“流”的概念，常见做法是渐进式下载，也就是用户点开一个MP4链接，浏览器从头开始下载这个文件，下载多少播多少。这种模式实现简单，一个静态文件服务器就能搞定，但它有几个致命问题。

第一个问题是码率死板。一个文件一旦编码完成，它的码率就固定了。用户带宽2Mbps和20Mbps面对的是同一个文件，前者疯狂卡顿，后者浪费带宽但画质依然很糊。第二个问题是拖拽体验差，用户拖动进度条到末尾，浏览器得先把中间一大段数据下载完才能播放，等待时间长得让人抓狂。第三个问题更隐蔽，CDN缓存粒度太大，整个文件作为一个缓存单元，热门视频的存储成本高得惊人。

我当时第一次接触自适应流技术，是Apple推出HLS（HTTP Live Streaming）的时候。HLS的思路很有意思：把视频切成一个个时长很短的小文件，叫TS分片，同时生成一个索引文件m3u8，播放器先读索引，再根据当前带宽选择不同码率的分片来下载。这一下子解决了上面提到的三个问题，视频可以被切成细粒度的分片缓存，码率可以动态切换，拖拽只需要从对应的分片开始拉。

HLS在2009年发布，之后迅速在iOS生态里站稳脚跟。但问题也随之而来，它是Apple自家主导的标准，其他厂商用起来心里总有点膈应。而且HLS早期强制要求使用TS封装和H.264编码，这对要接入其他编码格式或者特定封装格式的厂商来说，约束太大了。

1.2 MPEG-DASH的诞生与它想解决的事

2011年到2012年之间，MPEG组织联合多家公司推出了DASH，正式标准编号是ISO/IEC 23009-1。它和HLS走的是同一条大道，都是把视频切成Segment，通过一个描述文件告诉播放器有哪些码率可选、每个码率的Segment在哪里，本质上都是“HTTP + 分片 + 自适应”的组合。但DASH从设计之初就特别强调一件事：封装格式、编码格式、DRM方案全部解耦，爱用什么用什么。

这是DASH和HLS最本质的差别。DASH的Segment可以是MP4片段，也可以是TS片段；视频编码可以是H.264、H.265、AV1，甚至VP9；音频编码可以是AAC、Opus、AC-3。它只定义“怎么组织和描述这些媒体”，不规定“打包成什么容器、用什么编码”。这种中立性让它获得了更广泛的行业支持，尤其在Web和Android阵营里，DASH几乎成了默认选项。

用大白话讲，HLS像是Apple开的一家自营餐厅，菜单和食材都由Apple定；DASH则更像一个开放的美食节，谁都可以摆摊，前提是遵守统一的摊位登记规则。两者的目标都是让食客（播放器）根据自己胃口（带宽）选择合适分量的套餐（Segment）。

1.3 DASH与HLS：同门不同路的两个流派

很多刚入门的朋友会纠结，DASH和HLS到底选哪个。我给的答案通常是：看你的播放器生态。从技术指标上看，两者已经非常接近，DASH在编码和封装灵活性上略胜一筹，HLS则在Apple全系设备上拥有原生支持，不需要任何额外SDK就能在Safari里直接播放，而DASH在iOS上基本依赖第三方播放器。

兼容性的现实是这样的：如果你的目标平台是Android、Web、智能电视、机顶盒，DASH会是更顺畅的路，因为这些平台要么原生支持，要么有成熟的开源播放器（后面会详细讲）；如果你的目标平台以iPhone、iPad、Mac为主，HLS通常是省事的选择。很多大型平台的做法是两个都出，同一份视频源同时切片成DASH和HLS，交给CDN分发，播放器按平台自动选择，这在行业内已经是非常成熟的方案了。

从协议组织形态上看，DASH背后是MPEG这个国际化组织，HLS背后是Apple。DASH允许各家在标准框架内做扩展，比如后面要讲的低延迟DASH，就是在这个开放框架里长出来的新分支。对开发者来说，理解DASH相当于理解了一套更通用的自适应流媒体底层逻辑，以后再去看HLS、CMAF，会觉得很多概念都是相通的。

2. DASH的工作机制：分片、自适应与MPD三层模型

2.1 一次DASH播放请求的全过程

我第一次给一个小型视频站接入DASH时，习惯性打开Chrome的Network面板，想看看播放器到底发起了哪些请求。看完之后整个链路一下就清楚了，整个过程比想象中简单，但每一步的设计都很精妙。

播放器拿到一个URL，这个URL指向的不是视频本身，而是一个叫MPD的XML文件。MPD的全称是Media Presentation Description，翻译过来是“媒体呈现描述”。播放器先通过HTTP GET请求这个MPD，把它下载下来并解析。MPD里面写了这个视频总共有多少个时间段，每个时间段里有哪些码率、哪些语言、哪些分辨率，以及每一段媒体的访问地址模板。

解析完MPD之后，播放器会根据当前网络的带宽估算，从中选一个合适的码率，然后下载对应码率的初始化Segment，比如MP4格式里的init.mp4，这个初始化Segment不含音视频数据，只包含编解码器和封装所需的元信息。初始化Segment加载完毕后，播放器开始逐个下载媒体Segment，比如4秒一个的分片，边下载边解码边播放。

播放过程中，播放器会持续监测下载速度、缓冲区水位这些指标。如果发现当前码率下缓冲快要耗尽，下一次请求就会自动降一个档位，去请求低码率的Segment；如果带宽充裕，缓冲堆积很快，播放器又会试探性地提升档位，去请求更高画质的Segment。这一切都发生在用户无感知的情况下，正是“自适应”这三个字的含义。

把整个流程类比成看地图找路：MPD就是整张地图，告诉你总共有几条路（不同码率）、路上有哪些加油站（Segment列表），播放器根据当前车辆的油量（带宽和缓冲）选择最合适的一条路前进，走了一段之后发现路况变了，再切换路线。导航本身很复杂，但地图和路标的设计保证了切换过程足够流畅。

2.2 MPD：整场播放的“地图”与“菜单”

MPD在DASH体系里的地位极其关键，它是播放器与服务器之间唯一的“契约”。服务器端怎么切片、怎么命名、怎么组织码率层次，全部要通过MPD告诉播放器；播放器能不能找到合适的码率、能不能正确拼接片段、能不能在直播场景里持续获得新内容，也取决于它有没有正确解析MPD。

MPD本身是一个XML文档，根节点就是MPD，命名空间通常是urn:mpeg:dash:schema:mpd:2011。根节点上有一堆重要属性，比如type区分是点播还是直播，mediaPresentationDuration标识媒体总时长，minBufferTime告诉播放器至少需要缓冲多少秒才能开始播放，profiles声明这个MPD遵循的是哪个具体配置档。

MPD内部是明显的三层嵌套结构：Period是最外层的时间段，一个MPD里可以有多个Period，比如视频正片之前插入一段广告，就可以把广告和正片分成两个Period；每个Period下可以有一个或多个AdaptationSet，AdaptationSet表示同一类媒体内容的集合，比如视频流、音频流、字幕流各自是一个AdaptationSet；在AdaptationSet内部，同一个内容的不同码率会被拆成多个Representation。

给新同事解释时我喜欢这么说：Period相当于一张光盘里的多个章节，AdaptationSet是章节里的音轨和视频轨，Representation则是同一段视频的“标清版、高清版、超清版”。播放器在播放过程中做的切换，全部发生在Representation级别，它属于同一个AdaptationSet，所以切换时画面内容是对齐的，只是画质和码率不同。

2.3 Period、AdaptationSet、Representation：三层结构到底在说什么

一层层拆开看会更清楚。Period有一个关键属性start，表示这个时间段从什么时候开始，单位是秒。如果有多个Period，MPD里还允许用duration属性来显式指定每个Period的时长。在点播场景中，Period通常只有一个；在直播或插播广告的场景中，多个Period交替出现，播放器播完上一个Period后自动进入下一个。

AdaptationSet这一层解决的是“同一时间点的不同媒体形式”问题。一个典型的视频MPD里至少会有两个AdaptationSet，一个contentType="video"，一个contentType="audio"，如果语言多，音频AdaptationSet还会按lang属性区分。AdaptationSet还可以声明公共属性，比如segmentAlignment="true"表示所有Representation的分片边界对齐，这个属性对无缝码率切换至关重要；maxWidth、maxHeight这些字段则是为了让播放器在解析时能快速筛选出适合自己屏幕尺寸的集合。

Representation是真正和码率画质绑定的那一层，每个Representation都有唯一的id，有bandwidth表示码率，有width、height表示分辨率，有codecs描述编码方式，有mimeType描述封装类型。播放器做自适应切换，就是在同一个AdaptationSet的不同Representation之间根据码率来回跳，因为同属一个AdaptationSet，所以切换时画面内容和时间轴是连续的，不会出现跳帧或者音画错位。

这三个层级还有一个好处是便于CDN组织和播放器预加载。播放器可以先解析MPD，只下载AdaptationSet和Representation的元数据，就能在极短时间内制定出完整的下载策略，而不用真正去下载任何视频数据，所以MPD本身通常只有几KB到几十KB，加载成本极低。

3. MPD文件深度解析：字段、时间线与Segment模板

3.1 用FFmpeg生成一个最小可用的DASH流

看再多理论不如亲手搓一个MPD出来。我平时最常用的工具是FFmpeg，它的dash封装器生成MPD非常方便。假设你有一个input.mp4，想输出四档视频和两档音频的DASH流，下面这个命令可以起到很好的起点作用：

ffmpeg -i input.mp4 \ -map 0:v:0 -map 0:v:0 -map 0:v:0 -map 0:v:0 \ -map 0:a:0 -map 0:a:0 \ -b:v:0 800k -b:v:1 1400k -b:v:2 2400k -b:v:3 4000k \ -s:v:0 640x360 -s:v:1 1280x720 -s:v:2 1920x1080 -s:v:3 2560x1440 \ -b:a:0 128k -b:a:1 192k \ -use_timeline 1 -use_template 1 \ -seg_duration 4 \ -adaptation_sets "id=0,streams=v id=1,streams=a" \ -f dash output/out.mpd

这里解释几个关键参数：-map把同样的视频流映射到四个输出里，分别配不同码率和分辨率；-seg_duration 4表示每4秒切一个Segment；-use_template 1告诉FFmpeg生成使用SegmentTemplate模式的MPD，后面会讲这个模板的含义；-adaptation_sets把视频流归到id=0的AdaptationSet，音频流归到id=1的AdaptationSet。

运行完之后，output目录里会出现一个out.mpd文件，以及一系列init-stream*.m4s和chunk-stream*.m4s文件。后缀m4s就是MPEG媒体Segment的常见扩展名。把这个目录整个丢到Nginx或者任何一个静态文件服务器上，再用dash.js加载http://你的服务器/output/out.mpd，一个能自适应切换码率的播放器就搭起来了。

3.2 MPD关键字段逐项拆解

把FFmpeg生成的MPD打开看，开头大概是下面这样。我稍微精简了一下，但保留了所有核心节点：

<?xml version="1.0" encoding="UTF-8"?> <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" mediaPresentationDuration="PT32.0S" minBufferTime="PT1.5S"> <Period id="0" start="PT0S"> <AdaptationSet id="0" contentType="video" segmentAlignment="true" startWithSAP="1" maxWidth="2560" maxHeight="1440"> <Representation id="0" mimeType="video/mp4" codecs="avc1.640028" bandwidth="800000" width="640" height="360"> <SegmentTemplate timescale="12800" duration="51200" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number$.m4s" startNumber="0"> </SegmentTemplate> </Representation> <Representation id="1" mimeType="video/mp4" codecs="avc1.64002A" bandwidth="1400000" width="1280" height="720"> ... </Representation> </AdaptationSet> <AdaptationSet id="1" contentType="audio" segmentAlignment="true" startWithSAP="1"> <Representation id="2" mimeType="audio/mp4" codecs="mp4a.40.2" bandwidth="128000" audioSamplingRate="44100"> <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/> ... </Representation> </AdaptationSet> </Period> </MPD>

逐个说关键属性。type="static"表示这是一个点播内容，如果是直播则是dynamic。mediaPresentationDuration="PT32.0S"是ISO 8601格式的时长，PT32.0S表示32秒，播放器可以用它来显示总进度条。minBufferTime="PT1.5S"表示播放器至少要缓冲1.5秒才能开始，这是对播放体验和启动延迟之间的一个平衡值。

AdaptationSet上的startWithSAP="1"很多人不理解。SAP全称是Stream Access Point，说人话就是“随机访问点”，1表示每个Segment开头都是一个关键帧。这个属性非常重要，它保证了播放器无论从哪个Segment开始下载，都能立刻解码出画面，拖拽跳转和码率切换都依赖这一点。凡是做过视频切片的都知道，关键帧对齐是自适应流的基础，没有这个前提，切换码率时画面就会花掉。

SegmentTemplate是这一段的核心。timescale="12800"表示时间戳的基准频率，意思是这个流里所有时间戳都以每秒12800个单位来计数；duration="51200"表示每个Segment的持续时间为51200个时间单位，换算成秒就是51200除以12800等于4秒。media属性里的$RepresentationID$和$Number$是占位符，播放器会把它们替换成对应的Representation ID和递增的Segment序号，从而拼出真实的请求URL。

3.3 SegmentTemplate与SegmentTimeline：时间戳计算实例

FFmpeg在-use_timeline 1的情况下，还会在SegmentTemplate内部输出一个SegmentTimeline节点，它的作用是把每个Segment的实际时长用列表方式显式列出来。这样做的好处是允许Segment时长不完全相同，比如末尾不足4秒的最后一个Segment，就会被单独列出来。看一个典型的SegmentTimeline：

<SegmentTemplate timescale="12800" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number$.m4s" startNumber="0"> <SegmentTimeline> <S t="0" d="51200" r="7"/> <S t="409600" d="25600" r="0"/> </SegmentTimeline> </SegmentTemplate>

这里的S代表一个或一组Segment。t是起始时间戳，d是时长，r是重复次数。第一行t="0" d="51200" r="7"表示从时间戳0开始，有8个时长51200的Segment，也就是8个4秒的段；第二个S从时间戳409600开始，时长25600，重复0次，即只有1个2秒的段，这是视频末尾不足4秒的残段。所有段的时长加起来是8乘4秒加2秒等于34秒，和MPD根节点的时长对得上。

很多播放器在计算播放进度时，会优先依赖SegmentTimeline而不是mediaPresentationDuration，因为Timeline是逐段精确列出的，不会出现舍入误差。如果你的服务器是自己切片而不是用FFmpeg生成的，Timeline的t和d必须严格匹配实际Segment的时间戳，一旦对不上，播放器轻则进度条错乱，重则直接拒播。我在排查实际问题时遇到最多的，就是这里时间基准没换算对。

3.4 SegmentBase / SegmentList / SegmentTemplate怎么选

MPD里描述Segment位置的方式有三种，除了前面反复提到的SegmentTemplate，还有SegmentList和SegmentBase。三者各有适用场景，选错了会给播放器带来不必要的麻烦。

SegmentTemplate最适合内容多、结构规律的情况，无论是点播的长视频还是持续生产的直播流都适用。因为它的URL是模板加序号或时间戳拼出来的，不需要在MPD里把几万个Segment的URL全部列出来，MPD文件体积可控，而且直播场景的Segment数量无限增长也没有关系。

SegmentList会把每个Segment的URL和时长显式列在MPD里。好处是明确直观，坏处是Segment多了MPD文件会变得很大。它适合Segment数量很少的点播内容，比如几秒的短视频或者试看片段，此时MPD体积和解析开销都可以忽略。

SegmentBase只用来描述一个单独的媒体文件，通过HTTP Range请求从文件里按字节范围拉取初始化数据和媒体数据。适合文件不太大、又不想切片的场景，比如大片花絮或者单曲MV，播放器只需要知道初始化段的字节偏移量和媒体数据的字节范围，就能像读普通MP4一样播放。

我自己的经验是，没有特殊需求的情况下优先用SegmentTemplate + SegmentTimeline，FFmpeg默认就这么出，兼容性也最好。手动生成MPD再切片的项目，也建议尽量往这个形态靠，播放器端踩坑最少。

4. 围绕DASH的开源项目与工具链大全

4.1 播放器端：dash.js、Shaka Player、ExoPlayer怎么选

DASH的落地离不开播放器。Web端最主流的是dash.js，这是一个由Mozilla发起、现在由Dash-IF社区维护的开源播放器，基于Media Source Extensions实现，意味着它可以在不支持原生DASH的浏览器里通过JavaScript加MSE把DASH流拼出来。dash.js的文档和示例都做得比较全，遇到问题也容易在GitHub上找到解决方案，我建议Web端优先考虑它。

Google出的Shaka Player也是一个重量级选手，它同时支持DASH和HLS，而且打包了非常完整的ABR算法和控制接口。Shaka Player底层同样基于MSE，但它的架构更模块化，适合想深度定制播放逻辑的团队。如果说dash.js是开箱即用，Shaka Player就是留了更多旋钮给你调。

Android原生开发里，Google的ExoPlayer（现在已经改名为Media3）是把DASH支持做进框架里的，内置了完善的DASH、HLS、SmoothStreaming支持，只需要在构建MediaItem时指定MPD的URL，剩下的事情框架全包了。iOS端就没这么舒服了，AVPlayer原生只保证HLS体验，DASH需要借助第三方SDK或者封装层，这也是很多跨端团队在iOS上选择HLS的原因。

如果你只是想快速验证一个MPD能不能播，VLC和FFplay都支持DASH，命令行直接拉MPD地址就能播。不过这两个工具对DASH的支持都偏实验性质，我见过好几个合法的MPD在VLC里播不出来，但在dash.js里完全没有问题，所以它们只适合临时验证，不适合作为正式播放器的参考实现。

4.2 服务端与生产工具：FFmpeg、MP4Box、Bento4

服务端怎么把一条视频变成DASH流，工具选择直接影响效率。FFmpeg是首选，功能全面，原生支持-f dash输出，一次命令就能完成转码、切片、生成MPD全流程，小团队和个人项目几乎不需要别的工具。它的参数也比较直观，前面已经给过示例。

如果你对切片控制要求更高，比如需要精确控制Segment边界、需要DRM加密、需要生成CMAF格式，GPAC项目里的MP4Box是一个强大的补充工具。MP4Box可以做非常细粒度的流操作，把已有的fmp4文件重新分片、修改时间戳、生成多种profile的MPD，甚至能把HLS和DASH的清单一起生成。它的学习曲线比FFmpeg陡一些，文档也不够亲民，但功能确实硬核。

Bento4是一个C++写的MP4工具库，它的mp4-dash.py脚本是一个纯Python脚本，可以调用Bento4命令行工具来生成DASH和HLS流。如果你所在团队主要用Python做自动化，Bento4会更顺手一些，而且它对各类MP4细节的掌控程度非常高，适合处理奇怪的输入文件。我自己在遇到FFmpeg处理不了的畸形MP4时，经常先丢给Bento4修一遍再进FFmpeg。

还有一类工具是给线上服务用的。DASH的MPD和Segment本质上是静态文件，所以Nginx、Apache这些普通Web服务器就能胜任分发工作，不需要专门的流媒体服务器。做直播时，可以用nginx-rtmp-module或SRS接收RTMP推流，再通过FFmpeg实时转成DASH分片写入静态目录。这套链路非常成熟，很多中小型直播平台都是这么搭的。

4.3 验证与调试：从MPD校验到抓包定位

写MPD容易，写对MPD难。好在社区里有现成的验证工具。Dash-IF官方提供了一个MPD Validator，在线提交MPD文件就能检查XML结构是否合法、字段取值是否越界、SegmentTemplate是否能正确匹配到真实文件。我每次改完MPD生成逻辑，都会先把所有测试MPD过一遍校验器，能省掉很多线上播放器报错。

播放阶段排障最常用的还是抓包看请求时序。打开Chrome DevTools的Network面板，刷新页面观察MPD请求之后播放器发出的请求序列。正常的播放器行为是：请求MPD，接着请求当前码率的init段，然后按时间顺序请求media段，并且会周期性评估是否切换Representation。如果看到播放器反复请求同一个Segment，或者长时间停在init段不进入media段，问题大概率出在MPD的时间轴和实际文件不一致上。

除了Network面板，FFmpeg自带的ffprobe也可以用来检查Segment封装是否正常，比如执行ffprobe -show_packets chunk-stream0-1.m4s就能看到这个Segment内部的包信息，时间戳、关键帧位置一目了然。这些基础工具组合起来，足够覆盖绝大多数DASH排障场景。

5. 实战避坑：DASH开发中我踩过的那些坑

5.1 MPD解析失败：先查这几个地方

我遇到过最尴尬的一次MPD解析失败，是线上播放器突然大面积报Unable to parse MPD，查了半天才发现是CDN给MPD文件设置了错误的Content-Type，返回的是text/plain而不是application/dash+xml。虽然很多播放器不严格校验Content-Type，但某些严格模式的客户端会直接拒绝。这个坑看起来低级，但在真实线上环境里出现的频率远比你想象的高。

第二个高频原因是MPD文件本身没更新。很多团队用CDN缓存MPD，点播内容还好，直播内容的MPD是持续更新的，如果CDN把MPD缓存了几分钟，播放器就永远拉不到最新的Segment。排查时先加Cache-Control头，让直播MPD不缓存，或者设置很短的缓存时间。点播MPD也建议设置较短的缓存，至少不要超过几个Segment的总时长。

第三个高频原因是跨域问题。Web播放器加载MPD和Segment时，如果服务器没有返回正确的CORS头，浏览器会拦截请求。这里一定要把Access-Control-Allow-Origin配好，而且不只是对MPD生效，对后面所有的init和media Segment请求也要生效。很多人只给MPD加了CORS头，Segment全被拦截，播放器表现就是一直转圈。

5.2 画面撕裂与切换卡顿：Segment对齐问题

自适应切换最怕的就是花屏和跳帧。大多数情况下，问题都出在Segment内部没有从关键帧开始。DASH规范要求每个Segment都是一个完整的可独立解码单元，也就是Segment开头必须是流访问点。如果切片工具没有强制关键帧对齐，播放器从低码率切到高码率时，高码率Segment的开头可能是一个P帧，解码器找不到参考帧，画面就花了。

解决思路是两步：第一，编码阶段设置强制关键帧间隔，让关键帧间隔和Segment时长一致，甚至更小。这一点在FFmpeg里可以通过-force_key_frames "expr:gte(t,n_forced*4)"来实现，每4秒一个关键帧，正好匹配4秒一个Segment。第二，确保MPD的startWithSAP属性正确设置为1，表示每个Segment都从协议层保证了随机访问能力。

另一个导致切换卡顿的原因是AdaptationSet没有启用segmentAlignment="true"。没有这个标记，播放器不知道各个Representation的Segment边界是否对齐，切换时要等边界凑齐，表现就是明显卡顿。添加这个属性后，播放器可以在Segment边界处做无缝切换。

5.3 直播场景：dynamic MPD的更新机制

直播用的DASH和点播有个显著区别：MPD的type要从static改为dynamic，并且会带一个availabilityStartTime字段表示直播流的正式开播时间。直播流的Player会周期性地重新请求MPD，频率由minimumUpdatePeriod字段控制，默认为几秒。每次刷新后，MPD会追加新的Segment时间轴信息，播放器根据新的Timeline继续往后拉。

直播排障时的典型案例是：播放器播放十几秒后停住，不继续播放。这种情况通常是MPD没有更新，或者更新后SegmentTimeline里的时间戳没有递增。你在服务端检查生成MPD时，可以用curl多拉几次，对比新MPD和旧MPD的SegmentTimeline节点，确认每次都有新Segment被追加。还要注意timeShiftBufferDepth这个字段，它决定DVR窗口有多长，超出窗口的旧Segment会被服务器删除，播放器如果请求了过期Segment会收到404。

自己做直播服务时还有一个容易忽略的点：mediaPresentationDuration在直播场景不应该出现，因为直播总时长是未知且无限的。有些初学的同事为了省事直接照抄点播生成的MPD，导致播放器以为这是一个有限时长的视频，播完就停了。直播类型应该省略mediaPresentationDuration，只依赖SegmentTimeline来推进播放。

5.4 低延迟DASH（LL-DASH）：CFL与块的真相

短视频、直播带货这类场景对首屏延迟要求极高，传统DASH和HLS动辄5到10秒的延迟实在扛不住，于是低延迟DASH（LL-DASH）成了很多人关注的方向。LL-DASH的核心思想是CMAF（Common Media Application Format），配合Chunked Transfer Encoding，让播放器能在完整Segment还没生成完的时候，就拿到Segment开头的部分数据进行解码播放。

具体机制是：服务器不再等到整个Segment生成完再发送，而是边生成边通过HTTP chunked方式把数据块推给播放器，每收到一个媒体块就立刻送进解码器。这样理论上的端到端延迟可以压到1到2秒级别。播放器端也需要相应支持，比如dash.js的Low Latency模式开启后，会用更激进的预测策略请求Segment，并且能处理部分到达的媒体数据。

实战中LL-DASH的坑比传统DASH多得多，最典型的是CDN不支持chunked传输，或者缓冲策略没有配合调整，导致延迟不仅没降下来，反而因为频繁请求把服务器压垮。我的建议是：如果团队没有强烈的低延迟需求，第一版先老老实实做标准DASH，把播放稳定性调好，再考虑引入LL-DASH优化延迟。低延迟是一套系统工程，不只是换个MPD类型那么简单。

5.5 常见问题速查表

最后一个不算是“坑”的坑，但我想把它整理成一张速查表。DASH开发和排障中会遇到的问题其实非常集中，把这些高频问题背下来，能少踩很多弯路：

这些年做流媒体项目，我最大的体会是，DASH的复杂度其实不在协议本身，而在“时间”这件事上。MPD里的每一个时间戳、每一个字节范围、每一个Segment序号，背后都是一套严谨的物理时间映射。只要把时间轴理清楚，把Segment的对齐和关键帧处理好，DASH的稳定性会比想象中高很多，剩下的很多播放器适配问题都会自动消失。

最后再分享一个小技巧：遇到播放器表现异常时，先别急着改代码，用curl把MPD拉下来，再用FFmpeg的ffprobe把对应Segment解开，逐层对比MPD声明和实际媒体数据是否一致。我踩过的坑里，十有八九都是两者不一致造成的。DASH是个“契约协议”，服务器和播放器各守半边，只要契约文件真实可信，播放永远都是顺理成章的事。