2.2 序列与帧级元数据对照

2.2 序列与帧级元数据对照

本节摘要：解码器在碰第一块像素之前，先要读"说明书"：H.264 把全局参数放 SPS/PPS，HEVC 沿用并加了 VPS；AV1 把序列级参数收进 Sequence Header OBU，把逐帧变化放 Frame Header，把色彩、HDR 这类旁支信息交给 Metadata OBU。本节按"谁在什么时候需要知道什么"来对照三套元数据体系。

元数据的三次分层

先建立一个判断框架：任何编码标准的元数据都要回答三类问题——这一路码流是什么（分辨率、位深、色彩空间）、这一帧怎么解（帧类型、量化参数偏移、参考帧安排）、应用层要知道什么（HDR 亮度上限、胶片颗粒参数、时间码）。四代标准对这三类的拆分位置不同，这个拆分位置直接决定解码器状态机的复杂度。

H.264 的答案是最经典的二分法：SPS 管全局（图像尺寸、色度格式、档次级别），PPS 管一组图像共用的编码参数（熵编码模式、切片组）。IDR 帧前必须刷新 SPS/PPS，否则流中断。HEVC 在此之上加了 VPS（视频参数集）以支撑多层的可伸缩扩展，工程上最常被抱怨的也是这几个参数集的同步问题。AV1 干脆三分：序列级进 Sequence Header，帧级进 Frame Header，应用级旁路进 Metadata OBU。

Sequence Header：一次声明，长期有效

AV1 的 Sequence Header 集中声明"整条流不变的东西"：seq_profile（Main/High/Professional）、seq_level_idx、帧宽高、still_picture 标志、是否使用滤波清单、色彩描述（color_config：位深、单色标志、色彩原色与传递函数标识）。只要这些参数不变，它就不必重复出现；一旦变化（比如直播中切换分辨率），编码器重新插入一个 Sequence Header OBU，解码器据此重置状态。

对照 H.264 的实践差异在这里显现：SPS 的 VUI（视频可用性信息）在历史上经常被编码器省略或写错，播放器只好靠猜，这就是"灰屏""偏色"类故障的经典来源。AV1 把色彩声明做成强类型的 color_config，字段少、语义明确、位置固定，实践中踩坑面小得多。

# Sequence Header 关键字段速览（伪结构）
seq_profile          : 3 bits   # Main / High / Professional
seq_level_idx        : 5 bits   # 2.0 到 6.3
frame_width_minus_1  : 16 bits  # 最大 65536
frame_height_minus_1 : 16 bits
use_128x128_superblock : 1 bit  # 超级块尺寸选择
enable_filter_intra / enable_palette ...  # 工具开关
color_config {
  high_bitdepth / mono_chrome / color_primaries / transfer_characteristics / matrix_coefficients
}
film_grain_params_present : 1 bit
​

注意 use_128x128_superblock 这个字段：序列头里就定了整条流用 64 还是 128 的超级块，编码器按内容特性二选一。这从码流结构层面印证了第 3 章将要展开的划分体系差异。

Frame Header 与 Metadata：逐帧的账本和旁路的便签

Frame Header 承载"这一帧与上一帧不同的决定"：帧类型（KEY/INTER/INTRA_ONLY/S帧）、量化参数基值与增量、环路滤波强度、Tile 布局、参考帧槽位的刷新安排。对照 H.264，这些信息散落在切片头的各处；AV1 把它们集中在帧头且按"变化才写"的原则用增量编码压缩信令开销。

Metadata OBU 则是本册认为最值得称道的组织方式：HDR 的内容亮度上限（CLL）、色彩容量标识（CICP）、胶片颗粒参数、缩放信息、私有数据，全部走独立 OBU，与压缩数据平行传输。播放器可以只解析自己关心的类型，转码器可以原样透传，CDN 可以按类型路由——H.264 时代 SEI 消息"人人都要解析、人人都不敢信"的窘境被结构性化解。

💡 工程检查清单里值得加一条：交付 AV1 内容时确认 Metadata OBU 的 HDR 元数据与容器层（MKV/MP4）声明一致。两处不一致时，不同播放器会各信一处，故障表现为"有的设备过曝、有的设备发灰"。

从元数据对照看解码器状态机

把三套体系放进解码器的视角，状态机复杂度排序大致是：H.264（SPS/PPS/VUI/SEI 多入口、时机敏感）> HEVC（再多一层 VPS）> AV1（入口少、类型化、时机宽松）。这解释了一个现象：同样从零写解码器，AV1 的工程难点不在元数据管理而在工具集实现，而 H.264 的工程难点一半在"参数集什么时候生效"这种时序细节上。

追问两则

问：直播场景序列头出问题怎么办？
答：直播观众是中途加入的，所以推流端必须周期性重复插入 Sequence Header（以及关键帧），保证任意时刻加入的解码器都能拿到完整"说明书"。这对应 H.264 直播里周期性重发 SPS/PPS 的惯例——不同标准的工程直觉在这里惊人地一致，只是 AV1 把它做成了显式的 OBU，插入动作更干净。

问：Metadata OBU 会不会被转码链路弄丢？
答：会，而且这是真实事故来源。转码器若只重编视频载荷、不透传旁路元数据，HDR 与颗粒参数就静默丢失，表现为"转码后画面发灰、质感变塑料"。工程规约是把元数据 OBU 的透传列为转码流水线的验收项，与画质指标同级对待。

本节要点回顾

• 三类问题：全局是什么、本帧怎么解、应用层要什么，四代标准对三类的拆分位置不同。
• 强类型化：AV1 用 Sequence Header 加 Metadata OBU 替代 SPS/PPS/VUI/SEI 的松散组合，偏色灰屏类故障的土壤被铲掉大半。
• 变化才写：Frame Header 大量使用增量信令，逐帧开销被刻意压低。
• 旁路思想：元数据与压缩数据平行传输，转码透传与按类型路由都因此变得简单。

下一节把"说明书"里最影响选型的两个字段——Profile 与 Level——放到四代标准里对照。