第2章 集成方案选型决策树

在HLS与DASH之间做出选择并非简单的“好坏”对比，而是需要根据项目的具体约束条件进行多维度权衡。本章构建一个结构化的决策树框架，帮助开发者和架构师在设备兼容性、延迟要求、DRM支持和CDN成本四个核心维度上快速定位最优方案。

2.1 决策核心维度概述

下面是四个决定性的评估维度及其对选型的直接影响。每个维度都关联着一组可量化的指标或明确的约束条件。

2.2 决策树流程详解

下面的流程图展示了选型的逻辑路径。每个节点对应一个关键的判断条件，根据条件的真/假决定接下来的考察路径。

【选型起点】 
    |
    ├── 判断#1：目标平台是否以Apple设备为主？
    |   ├── 是 → HLS优先（原生支持，无需回退）
    |   └── 否 → 进入判断#2
    |
    ├── 判断#2：是否需要FairPlay DRM？
    |   ├── 是 → HLS（FairPlay与HLS绑定）
    |   └── 否 → 进入判断#3
    |
    ├── 判断#3：端到端延迟要求是否低于4秒？
    |   ├── 是 → CMAF + 低延迟Chunked模式（同时支持HLS与DASH）
    |   └── 否 → 进入判断#4
    |
    ├── 判断#4：CDN成本是否为主要约束？
    |   ├── 是 → fMP4分段（DASH优先，打包更小）
    |   └── 否 → 平衡策略：HLS与DASH双协议部署

2.3 设备兼容性深入扫描

设备兼容性往往是第一个筛选条件。在实施之前，需要制作一个清晰的兼容性矩阵。

2.4 延迟要求与CDM配置

延迟与DRM的交互是决策树中最需要妥协的部分。实现低延迟的同时保持多重DRM兼容性，关键依赖CMAF容器与Chunked Encoding。

2.4.1 延迟-兼容性权衡模型

2.4.2 DRM配置示例（CMAF + MPEG-CENC）

下面的命令展示如何将一份CMAF流同时打包为HLS（支持FairPlay）和DASH（支持Widevine/PlayReady）：

# 使用 Bento4 工具打包单个CMAF源为多DRM
mp4dash \
    --encryption-key=1a2b3c4d5e6f7890:aabbccddee001122 \
    --encryption-iv=00000000000000000000000000000000 \
    --hls \                              # 输出HLS播放列表
    --hls-key-url=https://license.example.com/fairplay \
    --hls-encryption-system=com.apple.fps.1_0 \
    --output-dir=./output_multi_drm \
    source.cmfv

在此配置下，HLS使用AES-128加密并通过FairPlay解密；DASH则使用MPEG-CENC标准（框中通常包含多个DRM系统ID）。打包器会自动生成对应的.m3u8和.mpd。

2.5 CDN成本量化策略

CDN成本通常按累计出账带宽或总请求数计费。不同分段格式对成本有显著影响。

2.5.1 分段格式成本对比

针对CMAF Chunked模式的高成本问题，建议在CDN层面开启请求合并（Request Coalescing）或使用分块传输编码，避免每个chunk都独立发起连接。

2.5.2 缓存在边缘节点的优化

# CDN缓存控制策略示例（Varnish VCL）
sub vcl_recv {
    # 对于fMP4分段文件，缓存时间设为1小时
    if (req.url ~ "\.m4s$" || req.url ~ "\.cmfv$") {
        set beresp.ttl = 3600s;   # 1小时
        set beresp.grace = 60s;   # 允许60s过时内容
    }
    # 对于.mpd文件，缓存时间设为1分钟（更短，以支持动态码率切换）
    if (req.url ~ "\.mpd$") {
        set beresp.ttl = 60s;     # 长缓存可能导致切换延迟
    }
}

2.6 决策树总结：选择路径速查

下方SVG图整合了四个维度的关键判断节点，形成本课程选型部分的参考框架。