音视频学习（八十七）：AVCC、HVCC和VVCC

概念：Annex-B vs. 模式化封装

在深入这三个格式之前，我们需要理解视频流的两种基本组织方式：

• Annex-B (字节流模式)：主要用于直播流（如 TS、HLS）。它使用特殊的“起始码”（如00 00 00 01）来分隔每个数据包（NALU）。
• 模式化封装 (AVCC/HVCC/VVCC)：主要用于点播文件（如 MP4、MOV）。它不使用起始码，而是在每个数据包前加一个固定长度的长度字段（指示该包有多少字节），并将关键的序列信息（SPS/PPS）存放在文件头部的全局配置记录中。

Annex-B

什么是 Annex-B？

Annex-B最初是在 H.264 (AVC) 标准的“附录 B”（Annex B）中定义的，后来也被 H.265 (HEVC) 和 H.266 (VVC) 沿用。

它设计的初衷是为了解决丢失同步的问题。在直播流（如 TS 流）或实时网络传输中，接收端可能随时加入。由于没有 MP4 那样的全局文件头，接收端必须有一种方法在混乱的二进制流中定位到一个视频帧的开始位置。

核心机制：起始码 (Start Code)

Annex-B 的核心特征是在每个NALU（Network Abstraction Layer Unit，网络抽象层单元）前面加上特殊的字节序列，称为起始码。

起始码的两种形式：

1. 00 00 00 01(4 字节)：通常用于一帧的开始，或者关键参数集（SPS、PPS、VPS）。
2. 00 00 01(3 字节)：通常用于一帧内部的多个切片（Slice），以节省带宽。

为什么能定位？

当解码器在比特流中扫描到00 00 00 01时，它就知道：“旧的包结束了，新的 NALU 从这里开始”。这使得播放器可以从流的任何位置切入，只要等到了下一个起始码和关键帧。

防止冲突：防竞争字节 (Emulation Prevention Bytes)

如果视频编码后的数据内容本身就包含00 00 01怎么办？这会导致解码器误判为新的一帧，造成画面崩溃。

为了解决这个问题，Annex-B 引入了防竞争机制：

• 在编码时，如果发现数据中出现了起始码序列，编码器会强制插入一个“特殊字节”03。
• 例如：原始数据00 00 01会被转换为00 00 03 01。
• 解码器在读取时，一旦看到00 00 03，就会自动把03删掉，恢复原始数据。

Annex-B 的结构组成

一个典型的 Annex-B 流结构如下：

• SPS (Sequence Parameter Set)：序列参数集。包含分辨率、帧率等全局信息。
• PPS (Picture Parameter Set)：图像参数集。包含熵编码模式、切片组信息。
• IDR 帧：关键帧。
• P 帧 / B 帧：预测帧。

在 Annex-B 中，SPS 和 PPS 是原位传输的。它们会周期性地出现在流中（通常在每个 IDR 帧之前），确保即使中途进场的观众也能获取解码参数。

示意图

结构示意图

在字节流中，NALU（数据包）是连续排列的，它们之间没有文件索引，全靠起始码分隔。

[起始码] [SPS] [起始码] [PPS] [起始码] [IDR帧/I帧] [起始码] [P帧] [起始码] [P帧] ...

• 起始码 (Start Code):通常是00 00 00 01(4字节) 或00 00 01(3字节)。
• 参数集 (SPS/PPS):在 Annex-B 中，这些配置信息周期性地插入到流中，确保播放器随时接入都能解码。

字节流连续性示意图

00 00 00 01 67 42 00 2a ... (这是SPS) 00 00 00 01 68 ce 3c 80 ... (这是PPS) 00 00 00 01 65 b8 40 20 ... (这是IDR关键帧) 00 00 01 41 e2 01 1e ... (这是非关键帧，使用了3字节起始码)

Annex-B 的优缺点

优点

• 强鲁棒性：适合流媒体传输。即便网络丢包导致一段数据损坏，解码器只需寻找下一个起始码即可恢复同步。
• 无状态：不需要像 MP4 那样先读“文件头”，拿到流就能解。

缺点

• 冗余略高：起始码和防竞争字节占用了额外空间。
• 检索慢：在本地文件中寻找特定帧时，必须逐字节扫描起始码，不像 AVCC 可以通过偏移量表实现毫秒级跳转。

AVCC (Advanced Video Coding Configuration)

AVCC 是针对H.264 (AVC)编码的封装规范，定义在 ISO/IEC 14496-15 标准中。

核心特性

• SPS/PPS 分离：序列参数集 (SPS) 和图像参数集 (PPS) 被提取出来，存储在avcC盒子（Box）中，而不是混在视频帧里。
• 长度前缀：每个 NALU 之前都有一个长度字段（通常是 4 字节），告诉解码器接下来的数据有多大。
• 优点：极大地提高了定位和随机访问的效率，播放器在打开文件时就能知道视频的分辨率、层级等信息。

数据结构（avcCRecord）

一个标准的 AVCC 配置记录包含：

1. Version:版本号（固定为 1）。
2. Profile/Level:编码等级（如 High Profile 4.1）。
3. LengthSizeMinusOne:指示长度字段占几个字节（通常是 3，代表 4 字节）。
4. SPS/PPS 列表：存储具体的参数集数据。

HVCC (High Efficiency Video Coding Configuration)

随着H.265 (HEVC)的出现，配置记录升级为 HVCC（对应盒子通常称为hvcC）。

演进与区别

与 AVCC 相比，HVCC 更加复杂，以适应 H.265 更强大的特性：

• 更多的参数集：除了 SPS 和 PPS，HVCC 引入了VPS (Video Parameter Set)。VPS 描述了多层编码信息（如 3D 视频或可伸缩视频）。
• 数组化存储：参数集以数组的形式存储，支持声明不同的 NALU 类型。
• 兼容性：尽管结构复杂了，但逻辑依然保持“全局配置 + 长度前缀数据”。

HVCC 的核心作用

由于 H.265 的压缩率比 H.264 提高了 50% 左右，HVCC 必须确保解码器在启动前能通过hvcC盒子精确获知是否支持某些高级特性（如 Main 10 profile 的 10bit 颜色）。

VVCC (Versatile Video Coding Configuration)

VVCC 是为最新的H.266 (VVC)编码设计的，对应盒子为vvcC。

VVC 的目标是在 H.265 的基础上再提升 30%-50% 的压缩效率，支持 8K、16K 以及自适应分辨率切换。

• 多参数集并存：除了 VPS、SPS、PPS，VVCC 还可能涉及APS (Adaptation Parameter Set)。
• 更加灵活的切片（Subpictures）：VVCC 支持将视频分割成多个独立可解码的子图，这在 VR 和全景视频中非常有用。
• 严格的声明：鉴于 VVC 解码对硬件性能要求极高，vvcC中的 Profile、Tier 和 Level 声明必须极其精确，以便设备预分配资源。

对比表