DASH低延时方案：DVB与DASH IF两种规范解析

DASH的低延时方案确实存在两种主流规范，分别由DVB（Digital Video Broadcasting，数字视频广播） 和**DASH IF（DASH Industry Forum，DASH行业论坛）**主导制定。两者均基于MPEG-DASH核心标准扩展，核心目标都是将传统DASH直播20-30秒的延迟压缩至3-4秒（甚至更低），适配线性电视、体育赛事等对实时性要求较高的场景，但在制定背景、适用场景、技术细节等方面存在差异，且均完全向下兼容普通DASH直播。以下从核心维度详细解析两种方案：

一、两种方案的核心背景与定位

低延时DASH（LL-DASH）的技术探索始于2017年，DVB与DASH IF曾联合开展低延时DASH相关研究，后续分别基于自身领域需求制定了独立规范，形成了"同源异流"的格局：

1. DVB-DASH低延时规范

DVB是由欧洲电信标准化组织、欧洲电子标准化组织等联合发起的国际组织，核心聚焦数字电视与广播服务的标准化。其低延时方案于2019年10月在《DVB-DASH蓝皮书》（A 168版本）中正式发布，2020年通过ETSI（欧洲电信标准协会）标准化发布（TS 103 285 v1.3.1）。该规范的核心定位是服务广播电视场景，解决"基于互联网的线性电视交付与传统广播延迟对齐"的问题，同时支持通过插入互联网内容实现直播个性化，是传统广电行业向互联网流媒体转型的关键技术支撑。

2. DASH IF低延时规范

DASH IF是由Akamai、谷歌、微软等流媒体企业组成的行业联盟，核心目标是推动MPEG-DASH的互操作性，加速其从技术规范向商业落地转化。其低延时规范于2020年正式发布（《Low-latency Modes for DASH》），后续不断迭代更新（如2025年发布的L3D扩展文档）。该规范的核心定位是服务全行业互联网流媒体场景，覆盖Web、移动端、智能电视等多终端，强调跨厂商、跨平台的互操作性，适配电竞直播、在线教育等多元化互联网直播需求。

二、两种方案的共性：核心技术路径一致

尽管定位不同，但两种低延时方案的核心技术逻辑完全一致，均基于"分片拆分为小Chunk+增量传输"的思路突破延迟瓶颈，且均强制依赖CMAF（通用媒体应用格式）作为封装基础（需注意：CMAF本身不直接降低延迟，但其提供的Chunk化封装工具是低延时实现的关键）：

Chunk化拆分：不再等待完整的DASH分片（传统分片4-10秒）生成，而是将分片拆分为更小的"帧组Chunk"（通常1秒以内），且每个Chunk内的帧不依赖后续Chunk即可独立解码，编码器生成一个Chunk就可立即输出，大幅缩短分片生成延迟；
增量传输：借助HTTP/1.1的分块传输编码（CTE），服务器可将未完成的分片（含已生成的Chunk）实时推送至播放器，播放器无需等待完整分片，接收Chunk后即可解码播放，实现"边传边播"；
MPD实时同步：通过扩展DASH的MPD（媒体呈现描述）文件，实时标记"分片是否开始可用"，让播放器精准感知直播边缘位置，避免无效等待。例如DVB和DASH IF均要求MPD包含UTCTiming元素，实现客户端与服务端的时钟同步，确保延迟计算准确。

三、两种方案的关键差异：细节适配不同场景

两种规范的差异集中在"适配场景导向的技术细节"，而非核心逻辑，具体差异可总结为以下4点：

1. 低延时模式的信号标识不同

播放器需通过MPD文件中的特定标识判断是否启用低延时模式，两者定义了不同的标识规则：

DVB-DASH：定义了专属的EssentialProperty（必要属性）和SupplementalProperty（补充属性）元素，若MPD中存在这两个元素，且schemeIdUri属性为"urn:dvb:dash:lowlatency:critical:2019"、value属性为"true"，则判定为低延时流；
DASH IF：通过SegmentTemplate元素的"availabilityTimeComplete"属性标识，当该属性设为"false"时，表明分片可部分获取（即支持Chunk增量传输），判定为低延时流。

2. 分片获取方式的推荐偏好不同

两种规范均支持两种DASH分片获取方式，但DVB-DASH给出了明确的推荐倾向，DASH IF则保持中立：

方式1：SegmentTemplate@media（使用 $Number$ 占位符）+ SegmentTemplate@duration（指定分片时长）；
方式2：SegmentTemplate@media（使用 $Time$ 和 $Number$ 占位符）+ SegmentTimeline元素（精准描述分片时间线）；
差异点：DVB-DASH明确推荐方式1，认为其更适配广播电视的线性传输场景；DASH IF未做推荐，允许开发者根据实际场景选择。

3. 适用场景与生态侧重不同

两者的场景差异源于制定主体的属性：

DVB-DASH低延时：更侧重传统广电与互联网融合场景，如广电运营商的IPTV直播、地面数字电视与互联网同步播出等，强调与DVB现有生态（如DVB-I服务发现）的兼容性，在欧洲、亚太等广电行业渗透率高的地区应用广泛；
DASH IF低延时：更侧重纯互联网流媒体场景，覆盖Web端（通过dash.js播放器）、移动端（如Android ExoPlayer）、智能电视等多终端，适配电竞、在线教育、户外文旅等多元化互联网直播需求，在全球互联网企业中应用更普遍。

4. 扩展功能的侧重点不同

两者均在MPD中扩展了延迟相关配置，但细节不同：

DVB-DASH：在MPD的ServiceDescription元素中定义了Latency和PlaybackRate子元素，可精准配置延迟的最小值（min）、最大值（max）和目标值（target）（单位：毫秒），要求播放器严格遵循该范围适配缓冲策略；
DASH IF：除了支持延迟范围配置，还扩展了低延时场景下的ABR（自适应码率）算法优化指南，推荐使用L2A-LL、LoL等专为低延时设计的ABR算法，并已在开源播放器dash.js中集成相关实现，更侧重解决互联网复杂网络环境下的流畅度问题。

四、总结：选择逻辑与应用建议

DVB与DASH IF的低延时方案并非"竞争关系"，而是"互补关系"，核心选择逻辑取决于应用场景：

若场景为传统广电转型互联网直播（如IPTV、广电线性节目互联网分发），需与DVB生态兼容，优先选择DVB-DASH低延时规范，确保与现有广电设备、服务的互操作性；
若场景为纯互联网流媒体直播（如电竞、在线教育、互联网体育赛事），需覆盖多终端（Web、移动端），优先选择DASH IF低延时规范，依托其丰富的企业生态和开源工具链（如dash.js、ExoPlayer）快速落地；
技术实现层面，两种方案可共用大部分核心组件（如支持CMAF的编码器、支持分块传输的CDN），仅需在MPD配置、播放器参数（如缓冲阈值、ABR算法）上根据规范调整，开发成本差异较小。