做多端视频业务的人迟早会碰到这个问题：同一份内容，在 Android 上好好的，到 iPhone 上要重做一遍，到电视上又得重写。
根子在 DRM 没有统一标准。
四个生态，四套规则
现在主流的 DRM 方案有四家，各管一摊：
- Google 的 Widevine，覆盖 Chrome、Android，以及不少智能电视
- Apple 的 FairPlay，覆盖 Safari、iOS、iPadOS、macOS、tvOS
- Microsoft 的 PlayReady，覆盖 Edge、Windows、Xbox
- 华为的 WisePlay，覆盖华为设备生态
它们互不通用。同一份加密内容要能在这四个生态里播放，就需要适配四条许可证路径。它们的差异不在配置层面，而在实现层面，等于四套东西。
落到工程上就是：四个端，四套技术栈，四份工作量。
一个平台的四种接法
DRM-X 6.0 这版 Universal Player SDK 预览版把四端要接的东西摊得比较开，可以当作一个具体样本看：
| 端 | 技术栈 | DRM 路径 |
|---|---|---|
| Android / Android TV | Kotlin + Media3 | Widevine |
| iOS / iPadOS | Swift + AVFoundation | FairPlay |
| Apple TV (tvOS) | Swift | FairPlay |
| 三星智能电视 (Tizen) | JavaScript + AVPlay | 平台支持的路径 |
这四端在同一个平台里整合，后端侧的密钥管理和许可证下发是统一的。也就是说，复杂度集中在客户端适配，服务端保持一条链路。这是做多端架构时比较理想的切分方式。
电视端是最容易被低估的那块
很多团队做多端规划时想的是手机、平板、电脑。电视往往被放到最后，然后发现是个坑。
原因在于智能电视的浏览器基本不支持 EME。没有 EME 就调不起 CDM，拿不到 DRM 许可证，加密内容解不开。想在电视端播加密内容，只有写原生应用这一条路。
三星 Tizen 就是典型。它有独立的应用体系和播放接口 AVPlay，跟 Web 那套不通用。这次的 Tizen SDK 是 JavaScript 写的，全高清点播播放和字幕切换已经在实体三星智能电视上验证通过。
如果你的用户画像里有大屏场景（教育、赛事、长视频），电视端的排期别往后压。
下载能力不是所有端都有
一个实践里很容易踩的点：加密下载这个能力，在这次的实现里只出现在 Android 和 iOS，电视端没有。Apple TV 的示例目前也以在线流媒体为主。
这属于业务取舍。电视端做离线缓存的场景本来就少，各家存储策略差异又大，统一封装成本划不来。
但做产品规划时要心里有数：如果你的方案里有"电视端离线看"这条需求，得换思路。
直播让一致性更难做
点播内容的密钥可以固定，直播必须按窗口轮换。一场播几小时，密钥固定等于一旦泄漏整场失守。
这次的直播方案是 AWS 那条链路：MediaLive 编码、MediaPackage v2 打包加密、CloudFront 分发，中间用 SPEKE 2.0 做密钥交换，支持 Widevine、FairPlay、PlayReady 三条分发路径。
实测在原生 iPhone 上跑通了加密 4K 直播流的解码播放，三星 Android 设备上完成 1080p 直播播放和密钥轮换测试。
规格上限是 3840 × 2160。这里必须重复一句源文档里的说明：实际分辨率取决于播放设备、编解码器、网络状况和内容策略。4K 是链路能力，不是每个终端的实际输出。
多端验收怎么做
基于上面的差异，验收不能只测一个端。建议按这个顺序：
先把目标机型分布拉出来，按解码能力分档，尤其是需要 HEVC 硬解的那一档。然后逐个端过一遍关键功能，播放、字幕、下载（如果端支持）、直播。最后把分辨率预期按端写清楚，别用一个统一标准去卡所有终端。
关于成本
四端适配的工作量是实打实的，别低估。这次 SDK 的获取门槛也需要提前知道：客户版下载需要有效的专业版或企业版订阅，但文档、App 截图、Android 评估 APK、三星电视评估安装包是公开的，可以先评估再决定。
平台选择和多端 SDK 的文档入口在 https://docs.drm-x.com/zh-Hans/sdk/native-apps
文中提及的第三方产品与商标归各自权利人所有，相关标识仅用于说明技术关系，不代表任何背书或合作关系。
