给 FFmpeg 的 MOV muxer 加上 Common Encryption（cbcs）支持（二）：tenc 与 constant IV

第一篇提到，cbcs 的难点大多不在 AES 本身。这一篇讲第一个典型问题：

tenc 盒子的字段顺序，以及 constant IV。

tenc 到底长什么样

tenc（TrackEncryptionBox）用来告诉解密方这个轨道怎么加密。ISO/IEC

23001-7 里 version 1 的 tenc 布局是：

FullBox（version/flags）
reserved (1 byte)
default_Crypt_Byte_Block + default_Skip_Byte_Block（打包进 1 byte，各 4 bit）
default_IsProtected (1 byte)
default_Per_Sample_IV_Size (1 byte)
default_KID (16 bytes)
若受保护且 Per_Sample_IV_Size == 0：
    default_Constant_IV_Size (1 byte)
    default_Constant_IV

注意几个容易写错的地方：

• 模式字节在 IsProtected 之前，而且是 nibble-packed：高 4 位是 crypt，低 4 位是 skip。
• Per_Sample_IV_Size == 0 表示使用 constant IV，这时后面才有 Constant_IV_Size 和 Constant_IV。

我们最早一版把模式字段写到了 KID 之后，字段顺序错了。因为 muxer 和

demuxer 是同一套代码、用同一个假设，所以自己 round-trip 完全正常，但换

一个遵循标准的解析器就解不出来了。这是整个系列反复出现的一个教训：

自洽不等于合规。

constant IV 而不是 per-sample IV

cbcs 与 HLS SAMPLE-AES 配套时，通常要求 constant IV，而不是每个样本

带一个 IV。也就是 Per_Sample_IV_Size = 0，IV 写在 tenc 里，整条轨道

复用同一个 IV。

这对写码器有两个影响：

1. 不再往 senc 里写 per-sample IV。
2. 每个 subsample 的 CBC 链都从同一个 IV 开始。

我们最终改成：cbcs 走 constant IV，cenc 保持原来的 per-sample

AES-CTR IV，两者互不干扰。

解析端也要对称

muxer 写对了还不够，demuxer 的 mov_read_tenc 也得按标准顺序读。我们同时

处理了几个边界：

• 最小 tenc 尺寸要够 24 字节（无条件字段），不能只 23。
• 读 Constant_IV_Size 之前先确认 atom 里还有这 1 字节。
• 读 constant IV 之前确认 25 + constant_iv_size 不越界。

这些看起来是小事，但每个都能被一个“缩短的 tenc”触发越界读取。LLM

review 把这些边界逐个标出来了。

小结

tenc 是 cbcs 对外暴露的“契约”。字段顺序、打包方式、constant IV 的

信号，三者必须严格按标准。下一篇进入真正的重头戏：视频样本里，哪些字节

加密、哪些必须明文。