背景：现有录制引擎与团队现状¶

用途：给参与「云上直播录制」技术选型的人做上下文交接。来源标注：[口述] = 团队成员当面提供；[文档] = 从产品方案文档推得；[调研] = 外部调研结论；[待确认] = 尚无可靠答案。日期：2026-07-28

一、一句话现状¶

我们在 Windows 桌面端已经有一套成熟的流媒体录制产品，录制能力是靠魔改 Chromium 源码实现的。现在想把这套能力搬上云，让用户"发起后关机走人"。云端这块团队没有任何经验，正在做技术选型。 [口述]

二、现有桌面产品的技术栈¶

2.1 整体形态¶

层	技术	说明
平台	Windows 桌面端	唯一支持的平台 [口述]
UI / 应用框架	Qt / C++	[口述]
浏览器内核	CEF（Chromium Embedded Framework）	内嵌浏览器，负责真实播放 [口述]
编码 / 封装	FFmpeg	[口述]

2.2 录制是怎么做到的（核心）¶

做法：改 CEF 里 Chromium 的源码，把浏览器内核里的音视频数据"劫"出来。 [口述]

用户在内嵌浏览器里真实播放
        ↓
Chromium 内核解码（DRM 内容此时已被 CDM 解密）
        ↓
【魔改点】在内核里插回调，把 YUV 视频帧 + 音频数据回调到上层
        ↓
上层（Qt/C++）拿到裸数据
        ↓
FFmpeg 编码 + mux
        ↓
输出媒体文件

为什么这条路走得通——这是理解整件事的关键：

浏览器要把画面显示出来，就必须先把内容解码成明文的 YUV 帧。DRM 内容也一样：CDM（内容解密模块）解密之后，帧就是普通的 YUV 了。我们取帧的位置在"解密之后、渲染之前"，所以根本不需要去拿 DRM 的密钥——密钥的活儿浏览器自己干了，我们只是在它干完之后把结果接住。

这一点对云端方案的含义极大，见第五节。

2.3 团队的能力边界¶

强：Chromium 源码级改造、CEF 集成、FFmpeg 音视频处理、Windows 桌面应用工程化 [口述]
无经验：云端基础设施、容器编排、Linux 上的浏览器无显示器运行、大规模并发调度 [口述]

三、产品文档里另有一条描述，与上面不一致¶

产品方案文档（附录二）对现有引擎（IRecorder）的描述是：

靠"浏览器真实播放时在网络层拦截 HLS / DASH 分片、重新封装成 MP4"（无损、非屏录、非重编码）

这和第 2.2 节口述的实现是两条不同的技术路线，且差异是根本性的：

	分片拦截路线（文档描述）	YUV 回调路线（口述描述）
取数据的位置	网络层，拿到的是原始分片（.ts / .m4s）	内核解码后，拿到的是裸 YUV 帧
处理方式	直接 remux 封装	重新编码再封装
画质	无损（原始码流原样搬运）	有损（解码→再编码，一定有损失）
CPU 开销	极低（基本只是 IO）	高（解码 + 编码两头都要算）
遇到 DRM 怎么办	拿到的是加密分片，必须另外搞到密钥才能解	不需要密钥，CDM 已经替我们解了
站点适配成本	每个站的清单格式都要适配	通用——浏览器能播就能录

最可能的解释：引擎里同时有这两条路线——非 DRM 走分片拦截（无损、省 CPU），DRM 走 YUV 回调（有损、但绕开了拿密钥的难题）。这是很常见的架构。但目前没有确认。

为什么必须确认：这个问题的答案会同时改写三件事——DRM 在云端的可行性判断、单机并发密度和成本模型、以及"无损"这个定价卖点站不站得住。已开票 14 · 录制链路口径确认。[待确认]

四、参考对象：PlayOn Cloud¶

团队指定 PlayOn Cloud 作为分析对象。[口述] 调研结论（详见票 02）：

它是屏录 + 重编码，不是解密流。锁 1x 实时、封顶 1080p、无 4K。
只录点播，不录直播。 ——产品文档"直播是空白市场"这个前提，确认成立。
它的屏录路径正在被关闭：2026 年 7 月起 Chrome 140+ 强制 HDCP 2.3 保护输出，PlayOn 录 Netflix 已经黑屏。
它真正赚钱的是存储订阅，不是录制积分——这和产品文档"溢价放录制层、存储层做大宗商品价"的思路正好相反。
可借鉴的是架构（用户入口 / 云端执行环境 / 录制流水线 / 云端交付四层），不能照搬业务（它录点播，内容已存在、时长确定；我们录直播，可能不开播、时长不定、结束判断复杂、有并发峰值）。

五、这套背景对云端方案意味着什么¶

5.1 好消息：DRM 在云端可能不是难题，而且产品文档把问题问错了¶

产品文档 R4 写的是「云端能否播放并解密 DRM（CDM / 领 key / HDCP / 风控）」——这是"分片拦截路线"才会遇到的问题描述。

如果 DRM 走的是 YUV 回调路线，那么"领 key"这个问题根本不存在。真正的问题变成三个完全不同的东西：

CDM 在云端环境能不能正常工作？ 已查：--headless 架构上不支持 Widevine（Chromium 官方倾向 wontfix），必须用 Xvfb + 完整 Chrome/CEF，也就是"有头但没显示器"。[调研，票 01]
VMP 会不会拦住我们？已答（2026-07-29）：不会，因为已经绕过了。 做法是 hook widevinecdm.dll 调用的系统文件打开函数，把签名校验时的文件句柄替换成官方 Chrome 的 .exe 和 .sig 文件句柄——CDM 读到的是货真价实的 Google 签名文件，验证通过；实际在跑的是魔改后的 CEF。[口述，票 07]

但这套手法是 Windows 专有的，每个环节在 Linux 上都不同：libwidevinecdm.so 而非 .dll、LD_PRELOAD 而非 API hooking，而且Linux Chrome 可能根本不带 .sig 文件（VMP 历史上可能是 Windows/macOS 专有机制）。这是目前压着操作系统选择的头号未知，票 19 正在调研。 3. 解密后的帧能不能取到？ 这里有个好消息：Widevine L1 会把解密后的帧放进受保护内存（取不到），而 L3 是纯软件解密，帧在普通内存里（能取到）。桌面 Chrome 用的就是 L3——这正好解释了现有产品为什么能工作。而云 VM 也永远是 L3（L1 需要硬件 TEE，云租户拿不到）。所以这个机制在云上大概率照样成立。[调研 + 推理]

结论：R4 应该重新表述。 它不是"能不能领 key"，而是"CDM 能不能在 Xvfb 环境里跑起来 + VMP 怎么过"。而这两个问题的难度，比文档假设的低得多。

5.2 坏消息：如果主力是 YUV 路线，成本模型要推倒重算¶

之前的成本估算建立在"分片拦截、几乎不耗 CPU、可能连解码都能跳过"这个假设上，估出来 8 vCPU 机器能塞 8–20 路。

YUV 回调路线下这个假设不成立：必须真实解码，还要额外真实编码。1080p 实时编解码大致要 1.5–2 个 vCPU 一路，也就是 8 vCPU 机器只能塞 4 路左右。

粗算对比（c7i.2xlarge，8 vCPU，$0.357/时）：

路线	估计并发	计算成本
分片拦截（跳解码）	8–20 路	$0.02–0.045/路·时
YUV 回调（解码 + 编码）	约 4 路	约 $0.09/路·时

贵 2–4 倍。 而且"无损"这个定价卖点在 YUV 路线下不成立——文档 §七的溢价理由（"能录直播 + 无损"）少了一半。[推理，需票 11 实测]

5.3 移植方向：CEF 和 Qt 跨平台，但魔改的部分要重来¶

CEF 和 Qt 本身都是跨平台的，但改过的那部分 Chromium 源码（YUV / 音频回调）必须在 Linux 上重新出 build 并验证 DRM 链路。这不是改配置，是明确的工程量。[票 10]

选 Linux 而不是 Windows 的理由（都是硬约束）[调研，票 04]：

Windows 容器根本跑不了 GUI 应用（Session 0 隔离）→ 只能整机 VM，密度差
Windows License 溢价 30–100%
Windows Server 默认没有音频端点，要额外装 VB-Cable 之类

5.4 真正的拦路虎不在技术栈上¶

调研的最终结论是：现有引擎能不能上云，是这件事里相对容易的部分。 真正可能让产品不成立的是出网——机房 IP 被 GeoGuard 在 CDN 层按 ASN 拦截，改走住宅代理则单次录制成本超定价 25–40 倍。详见判断-产品价值与技术选型.md。

六、给新加入者的阅读顺序¶

本文（背景）
云上直播录制 · 产品方案（初版）（产品意图）
判断-产品价值与技术选型.md（当前判断与推理链）
map.md（决策地图，看当前卡在哪张票）

七、本文里还没有答案的问题¶

#	问题	归属
1	DRM 录制到底走 YUV 回调还是分片拦截？两条路线是否并存、怎么分流？	票 14
2	~~现有引擎面对 VMP 是怎么过的~~ 已答：hook 文件句柄指向官方 Chrome 的 exe/sig。剩下的是：Linux 上还成不成立？	票 19
2b	现有桌面端实际能录哪些 DRM 站点、录不了哪些？Amazon Prime 到底能不能录？	票 07
3	现在桌面端实际能录到什么分辨率？（若只有 720p，说明本来就在 L3 天花板上）	票 07
4	有没有做过 Linux / macOS 的构建尝试？结果如何？	票 07
5	团队有没有人做过容器编排 / 云上运维？还是要外招或外包？	未开票，属人力规划