dash.js项目中多DRM系统下setProtectionData失效问题分析

在dash.js项目中，开发者在使用setProtectionData方法配置ClearKey DRM时遇到了一个特殊场景下的兼容性问题。本文将深入分析该问题的技术背景、产生原因以及解决方案。

问题背景

当MPD(媒体呈现描述)文件中包含多个DRM系统时，dash.js的setProtectionData方法可能会出现失效的情况。具体表现为：

1. MPD文件中同时包含PlayReady、Widevine和ClearKey三种DRM保护方案
2. 开发者尝试通过setProtectionData方法配置ClearKey密钥
3. 系统却自动选择了PlayReady而非开发者指定的ClearKey

技术分析

DRM系统选择机制

dash.js在选择DRM系统时遵循以下逻辑：

1. 首先解析MPD文件中的ContentProtection元素
2. 根据schemeIdUri识别可用的DRM系统
3. 检查浏览器支持的DRM系统列表
4. 最终确定使用的DRM方案

问题根源

当MPD文件中同时包含商业DRM(如PlayReady/Widevine)和ClearKey时，dash.js会优先选择商业DRM系统。这是因为：

1. ClearKey在MPD中没有被明确声明（缺少urn:uuid:e2719d58-a985-b3c9-781a-b030af78d30e方案标识）
2. 商业DRM系统通常具有更高的优先级
3. dash.js默认不会将cenc:default_KID属性识别为ClearKey标志

解决方案

方案一：修改MPD文件

最直接的解决方案是在MPD文件中明确添加ClearKey的内容保护声明：

<ContentProtection value="ClearKey1.0" schemeIdUri="urn:uuid:e2719d58-a985-b3c9-781a-b030af78d30e">
</ContentProtection>

方案二：使用网络拦截器

对于无法修改MPD文件的情况，可以使用dash.js v5.0.0引入的网络拦截器功能：

1. 拦截MPD请求
2. 动态添加ClearKey的内容保护声明
3. 返回修改后的MPD内容

方案三：自定义DRM选择逻辑

高级开发者可以通过扩展ProtectionController来实现自定义的DRM选择逻辑，例如：

1. 重写keySystemSelection方法
2. 根据cenc:default_KID属性识别ClearKey内容
3. 强制使用ClearKey系统

安全考虑

值得注意的是，商业内容提供商通常不会同时使用商业DRM和ClearKey，因为：

1. ClearKey本质上不是真正的DRM系统
2. 其密钥是明文的，安全性较低
3. 商业DRM系统提供了更高级的安全保护

开发者在使用ClearKey时应充分评估其安全风险，特别是在生产环境中。

总结

dash.js在多DRM系统环境下的行为符合其设计原则，但可能与某些特殊使用场景存在兼容性问题。通过理解其内部机制，开发者可以采取适当的解决方案来满足特定需求。对于无法修改MPD的情况，网络拦截器提供了一种灵活的解决方案，而自定义DRM选择逻辑则为高级用户提供了更大的控制权。