EME是W3C制定的标准化接口，作为浏览器与DRM系统（如Widevine、PlayReady）间的“联络员”，负责检测支持、绑定解密能力、发起许可证请求，但不加密、不解密、不发密钥；真正保护依赖服务端加密、许可证服务器授权及CDM执行解密。
HTML5 媒体资源的版权保护，核心依赖 Encrypted Media Extensions（EME） 这一标准化接口，但它本身不加密、不解密，也不发密钥——它只是浏览器和内容解密模块（CDM）之间的“联络员”。真正起保护作用的是服务端的加密处理、许可证分发机制，以及前端对 EME API 的正确调用。
EME 不是 DRM，而是 DRM 的“调度接口”
EME 是 W3C 制定的 JavaScript API 规范，目标是统一网页与各类 DRM 系统（如 Widevine、PlayReady、FairPlay）的交互方式。它的作用很明确：
- 检测浏览器是否支持某 DRM 方案（
navigator.requestMediaKeySystemAccess） - 创建并绑定解密能力（
mediaKeys）到<video>元素 - 发起许可证请求、接收响应，并交由 CDM 完成实际解密（通过
mediaKeySession）
也就是说，EME 不实现加解密算法，也不存储密钥，更不验证用户身份——这些都由服务端和 CDM 各自完成。
视频必须提前加密，且带 DRM 元数据
要让 EME 生效，视频文件本身得是已加密的，且包含对应 DRM 系统所需的初始化数据（如 PSSH box）。常见做法是：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 用
shaka-packager或mp4-dash工具对原始视频进行多 DRM 打包 - 生成含多个 DRM 头信息（如 Widevine、PlayReady）的 MP4 或 DASH 清单（.mpd）
- 确保视频流中每个片段都携带加密标识（
cenc初始化类型）
没加密的视频，即使调用 EME API，CDM 也无密钥可解——播放器会直接报错或静音。
许可证服务器是授权控制的关键环节
EME 在前端触发 license request，但决定“给不给密钥”“给什么密钥”的，是后端许可证服务器。它需要：
- 接收 EME 发出的二进制 license request（通常是 POST 到指定 URL）
- 校验请求合法性：比如解析 JWT token、验证用户订阅状态、检查设备 ID 或地理围栏
- 按策略返回加密后的 license 响应（如 Widevine 的 JWPL 或 PlayReady 的 XML 许可证）
这个环节决定了能否实现“仅限 VIP 播放”“禁止投屏”“72 小时内有效”等精细化权限控制。
运行环境有硬性安全要求
所有 EME 操作强制要求 HTTPS（或 localhost），HTTP 页面下 API 会直接不可用。这是因为：
- 密钥交换过程必须防中间人窃听
- CDM 只在安全上下文中启用（浏览器策略限制）
- 部分 DRM 方案（如 FairPlay）还要求 TLS 证书可信、域名备案等额外校验
本地开发调试时可用 http://localhost，但上线部署必须走 HTTPS，否则整个 DRM 流程无法启动。
