FLV 加密直播流前端播放方案 & DRM 深度解析

一、FLV 加密直播的常见前端方案

FLV（Flash Video）作为延迟低（1–3s）、兼容 HTTP-FLV/WebSocket-FLV 传输的直播格式，在国内直播场景占比很高。但 Flash 已死，现代浏览器播放 FLV 必须靠 MSE（Media Source Extensions） 把 FLV tag 实时转封装成 fMP4 喂给 <video>。因此"加密"只能在这条链路的某一段做。主流方案如下：

1. 私有对称加密（自研 DRM / "伪 DRM"）

维度	说明
加密层	推流侧或 CDN 边缘节点对 FLV 的 Video Tag / Audio Tag 的 payload 做 AES-128-CTR / ChaCha20 等对称加密，tag header 保持明文以便解析
密钥下发	独立鉴权接口（带 token / 时间戳 / 设备指纹），HTTPS 返回密钥；可配合一客一密、一流一密、分段轮换（Key Rotation）
解密位置	浏览器侧在 flv.js / mpegts.js 的 demuxer 之后、remux 到 fMP4 之前做解密
典型实现	改造后的 flv.js / mpegts.js + WebCrypto SubtleCrypto（AES-CTR）；高性能场景会走 WebAssembly（把 OpenSSL / mbedTLS 编进 wasm）

优点：实现灵活、延迟低、可直接复用现有 FLV CDN。缺点：密钥、解密逻辑最终都在 JS/Wasm 运行时里，任何有心人都能 hook MSE appendBuffer 或在 wasm 内存里 dump 出明文 ES 流，只能"防君子不防小人"。

2. 标记/扰码类轻量防护

关键帧扰码：只加密 I 帧或 SPS/PPS/VPS，破坏画面完整性但保留结构
Tag 顺序/时间戳扰码：打乱 tag 排列，播放端按约定还原
Referer / Token / HMAC 签名 URL：严格来说不是加密，是访问控制，通常与上面方案组合使用

3. 基于 WebTransport / WebSocket + 自研协议替代 HTTP-FLV

先用 TLS 传输通道加密（相当于传输层的 HTTPS/WSS），再在应用层做二次加密，规避中间代理抓包。仍属于自研方案范畴。

4. "换壳"方案：把 FLV 改造为 CMAF/fMP4 直播

如果真要上商用 DRM，唯一出路是放弃 FLV 封装，改用 LL-HLS / LL-DASH / CMAF，延迟可以做到 2s 以内（接近 FLV），下面第三节会解释为什么必须这么做。

二、DRM 是什么

DRM（Digital Rights Management，数字版权管理） 是一整套端到端的受控播放体系，目标不是"加密"本身，而是保证：

明文媒体数据从解密到最终像素渲染的全链路，都在操作系统/芯片级可信执行环境（TEE）中完成，JS、调试器、截屏工具都拿不到明文。

W3C EME（Encrypted Media Extensions）架构

浏览器里的 DRM 是通过 EME 这套 W3C 标准 API 调用底层 CDM（Content Decryption Module） 实现的：

<video> ──► MSE (加密的 fMP4 / WebM)
   │
   ▼
EME API (requestMediaKeySystemAccess / generateRequest / update)
   │
   ▼
CDM（浏览器/OS 内置的闭源二进制）
   │
   ▼
TEE / 安全视频路径 (Secure Video Path, SVP) ──► GPU ──► 显示器

三大商用 DRM 体系

DRM	厂商	覆盖平台	支持的最高安全等级
Widevine	Google	Chrome / Edge / Firefox / Android / ChromeOS / Android TV	L1（TEE）/ L2 / L3（软件）
PlayReady	Microsoft	Edge(legacy)/IE / Xbox / Windows / 部分智能电视 / 部分机顶盒	SL3000（硬件）/ SL2000 / SL150
FairPlay Streaming (FPS)	Apple	Safari / iOS / iPadOS / macOS / tvOS	绑定 Apple 硬件

三家共享一个底层密码学事实标准：CENC（Common Encryption, ISO/IEC 23001-7），也就是 cenc（AES-128-CTR）和 cbcs（AES-128-CBC subsample）两种加密方案，配合 PSSH（Protection System Specific Header） box 声明授权信息。

工作流程（以 Widevine 为例）

播放器请求 manifest（HLS #EXT-X-KEY / DASH ContentProtection）
解析到 PSSH，EME 生成 License Request
送到运营者的 License Server（内含 Widevine Cloud SDK）鉴权并返回 License
CDM 在 TEE 内解密 License，拿到内容密钥
fMP4 分片送入 CDM，明文 ES 直接走安全视频通路到 GPU，浏览器 JS 永远接触不到明文

三、为什么商用 DRM 不支持 FLV，只支持 HLS/DASH

核心原因不是"不想支持"，而是技术栈和标准在设计时就把 FLV 排除在外。可以从五个层面理解：

1. 封装格式层面：FLV 根本没有"加密盒子"的位置

HLS / DASH / CMAF 使用的 fMP4（ISO BMFF） 标准里有专门的 box：sinf、schm、schi、tenc、pssh、saiz、saio、senc……这些 box 是 CENC 标准的载体，明确告诉 CDM "这段 sample 是用什么算法、什么 IV、subsample 是怎么切的"
FLV 的 tag 结构里没有任何对应字段。FLV 设计于 2002 年的 Flash 时代，整份规范根本没考虑过 CENC/EME 生态，也没有扩展机制去挂载 PSSH

2. 浏览器/CDM 输入层面：CDM 只认 ISO BMFF 或 WebM

Widevine / PlayReady / FairPlay 的 CDM 接受的输入封装就两类：ISO BMFF (fMP4) 和 WebM（FairPlay 只接受 fMP4）
MSE 的 MediaSource.isTypeSupported() 对 DRM 场景只白名单 video/mp4; codecs="..." 和 video/webm，video/x-flv 从来就不是合法 MIME
即使你在 JS 里把 FLV 转封装成 fMP4 再喂给 CDM，CDM 也要求分片本身带 sinf/pssh，而你在 JS 里"后加"的加密盒子 CDM 不信任——因为密钥已经被 JS 看见过，丧失了 TEE 的安全前提

3. 传输协议层面：HLS/DASH 的 Manifest 是 DRM 生态的一部分

HLS 的 #EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.apple.streamingkeydelivery",URI="skd://..."、#EXT-X-SESSION-KEY
DASH 的 <ContentProtection schemeIdUri="urn:uuid:edef8ba9-..."/>（Widevine UUID）
FLV 是单一的连续字节流，没有独立的 manifest 去声明 KeySystem、License Server、Key Rotation 策略，整个授权协商无处安放

4. 商业与合规层面：好莱坞 MPA/Studio 的合规要求

Netflix / Disney+ / HBO 等内容方要求 4K/HDR 必须跑在 Widevine L1 / PlayReady SL3000 / FPS 硬件等级上，且走 CMAF + CENC
FLV 不在任何内容方的合规清单里，即便技术上能打补丁，也拿不到 studio 的内容授权
Google、Apple 也没动力为一个 Adobe 早已弃维（2020 年 Flash EOL）的格式去扩展 CDM

5. 安全模型层面：FLV 的播放链路无法保证 TEE

商用 DRM 的核心价值是"明文永远不进 JS/用户态"
浏览器播 FLV 必须走 flv.js/mpegts.js + MSE，demux 和 remux 都在 JavaScript 里完成，本质上是"用户态软解封装"。即便在 JS 里做了 AES 解密，解密后的 ES 会途经 JS 堆内存，与 TEE/SVP 的安全承诺完全相悖
而 fMP4 + CENC 的链路中，JS 只做"搬运加密分片"的工作，从不接触密钥和明文，这才是 CDM 愿意背书的前提

四、实践选型建议

诉求	推荐方案
秒开 + 超低延迟、内容价值不高（秀场/电商/社交直播）	HTTP-FLV / WebSocket-FLV + 私有 AES 加密 + Token 鉴权
需要版权级保护（付费赛事、院线同步、4K/HDR）	必须弃用 FLV，改走 LL-HLS / LL-DASH (CMAF) + Widevine / PlayReady / FairPlay 三模 DRM，延迟可压到 2s 以内
想在 FLV 基础上"贴"近 DRM 体验	私有加密 + WebAssembly 解密 + 代码混淆 + 设备指纹 + 动态密钥轮换，心理安慰为主
超低延迟 + 强保护	WebRTC + Insertable Streams (SFrame) 做 E2EE，或 CMAF-CTE + DRM

一句话总结：FLV 属于"传输封装 + 容器格式"层面的老协议，没有 CENC 所需的加密元数据结构，也不在浏览器 CDM 的合法输入列表里，更不被好莱坞合规体系承认——这三点任何一条单独拿出来都足以让商用 DRM 对它说不。所以业界的惯例是：要低延迟 + 轻保护用 FLV 自研加密；要真 DRM 就换 HLS/DASH + CMAF。

FLV 加密直播流前端播放方案 & DRM 深度解析 ​

一、FLV 加密直播的常见前端方案 ​

1. 私有对称加密（自研 DRM / "伪 DRM"） ​

2. 标记/扰码类轻量防护 ​

3. 基于 WebTransport / WebSocket + 自研协议替代 HTTP-FLV ​

4. "换壳"方案：把 FLV 改造为 CMAF/fMP4 直播 ​

二、DRM 是什么 ​

W3C EME（Encrypted Media Extensions）架构 ​

三大商用 DRM 体系 ​

工作流程（以 Widevine 为例） ​

三、为什么商用 DRM 不支持 FLV，只支持 HLS/DASH ​

1. 封装格式层面：FLV 根本没有"加密盒子"的位置 ​

2. 浏览器/CDM 输入层面：CDM 只认 ISO BMFF 或 WebM ​

3. 传输协议层面：HLS/DASH 的 Manifest 是 DRM 生态的一部分 ​

4. 商业与合规层面：好莱坞 MPA/Studio 的合规要求 ​

5. 安全模型层面：FLV 的播放链路无法保证 TEE ​

四、实践选型建议 ​