给 FFmpeg 的 MOV muxer 加上 Common Encryption（cbcs）支持（六）：与 LLM code review 协作的体会

这个 patch 前后过了好几轮 AI review。回头总结一下，哪些做法有效、哪些是

坑。

review 能抓到什么

LLM code review 在几类问题上命中率很高：

• 整数边界：unsigned 转 int 回绕、数组下标、乘加溢出；
• 分派遗漏：某个 codec 分支写了明文却带加密信号；
• 资源泄漏：某条错误路径忘了 free；
• 测试缺陷：拒绝测试对任意非零退出都放行；
• 规范细节：字段顺序、参考计数上限、HRD 计数上限。

它也给过“噪音”：有些 claim 没有复现，有些归因到错误的 commit，有些把

SHOULD 当成 MUST。所以每条 finding 都要自己在代码里核实，不能照单全收。

对我们最有用的一条经验

round-trip 通过 ≠ 正确。 加密和解密用同一套 subsample 假设时，任何

边界都能自洽。真正能发现问题的，要么是独立参考实现，要么是审查 bitstream

语义。这条几乎解释了前面所有 Major finding。

提交怎么组织

我们最终把历史整理成 12 个提交，每个都是完整、可编译、FATE 通过的状态：

• 先按“一个逻辑变更一个提交”写；
• review 的 fix 不要堆在尾巴上，而是 fold 回它指向的那个 commit；
• 因为代码还没合入 upstream，本地 rebase + 自己 force-push 是安全的。

折叠时最容易踩的坑是测试 ref 的归属：改密文边界会改 ref 文件，但 ref

文件是在测试提交里引入的，不是功能提交。fold 时要么把 ref 变更移到对应

测试提交，要么先删后补。

和“抢坑”的人协作

过程中有开发者拿着早先的 5.1 patch 来表示愿意合作。那版 patch 的思路是

导出 libavcodec 内部函数给 muxer 用，shared 构建不可行。我们礼貌感谢、

说明现状、把讨论钉在我们自己的 PR 上，并请他帮忙 review slice header

边界和共享 conformance 流。既不防御，也不把技术路线让出去。

最后的状态

最终实现的要点：

• cbcs：AES-CBC + 1:9/5:5/10:0 模式，constant IV；
• 标准 version-1 tenc 布局；
• H.264/HEVC 自包含 slice header 解析，slice data 才加密；
• AV1 tile 完整保护；
• AC-3/E-AC-3 整样本加密，音频无 senc；
• VVC/LCEVC/APV/字幕/数据分区 AVC 明确拒绝；
• 12 项 FATE 覆盖，逐提交可编译可测。