6.2.5 Profile/Level 体系与规格导读
为什么需要 "身份证" 体系
H.264 的工具箱如此丰富，以至于没有一台设备能（或需要）全部支持：手机芯片的算力、内存与功耗预算，和工作站不可同日而语。如果放任编码器自由组合工具，解码端将无所适从。H.264 的解决方案是把 "能用什么工具" 与 "能扛多大负荷" 拆成两个正交的维度——Profile（档次） 与 Level（等级），合称解码器的 "身份证" [8]。
Profile：工具集的划分
| Profile | 定位 | 关键工具增减 |
|---|---|---|
| Baseline（基线） | 视频通话、移动等低延迟场景 | I/P 帧；仅 CAVLC；无 B 帧 |
| Main（主） | 标清/高清广播 | 增加 B 帧、CABAC、隔行编码 |
| Extended（扩展） | 早期流媒体 | 增加 SP/SI 切换帧，便于码流切换与容错 |
| High（高） | 蓝光、高清分发（FRExt，2005） | 增加 8×8 变换、自定义量化矩阵 |
| High 10 | 专业制作 | 支持 10 bit 位深 |
| High 4:2:2 / 4:4:4 | 广播级/母版 | 更高色度采样格式 |
日常接触到的 H.264 视频，绝大多数是 High Profile；而实时通话场景（包括 WebRTC 的 H.264 模式）则普遍落在 Baseline 系——B 帧带来的解码重排延迟，在互动场景是不可接受的。这个取舍在第七章讨论 WebRTC 时还会回响。
Level：负荷的上限
Profile 定了 "能用哪些工具"，Level 则定 "最多用多狠"：它约束解码器必须支持的最大宏块处理速率、最大帧尺寸、最大码率、最大参考帧缓冲（DPB）容量与运动矢量范围。几个常见的锚点 [8]：
- Level 3.1 → 720p @ 30 fps
- Level 4.0 → 1080p @ 30 fps
- Level 5.1 → 迈入 4K
编码器在码流的 SPS（Sequence Parameter Set，序列参数集） 中声明 Profile 与 Level，解码器据此判断 "这路码流我吃不吃得下"。我们在用 ffprobe 查看视频信息时看到的 High 4.0 之类字样，就是这个体系（practice_7 会亲手验证）。
规格导读：如何查阅 ITU-T H.264
学到这里，已经值得亲手翻一翻官方规格了。ITU-T 的公开政策相当友好：H.26x 系列规格全文可在 ITU 官网免费下载（H.264 文档约 800 页）。面对这样一份大部头，推荐的路径不是从头读到尾，而是按需取用 [8]：
- 第 7 章 语法与语义（Syntax & Semantics）：码流的 "词法"。7.3 的语法表用类 C 伪代码精确描述每个语法元素的比特排布；描述符
ue(v)/se(v)即无符号/有符号 Exp-Golomb 编码，ae(v)即 CABAC 编码——7.4 则逐字段解释语义 - 第 8 章 解码过程（Decoding Process）：规格的心脏。从 NAL 单元解析、slice 解码、帧内/帧间预测到去块滤波，每一步都以精确到像素的公式给出——6.2.2~6.2.4 的全部规则在这里都有严格定义
- 附录 A（Profiles and Levels）：Profile/Level 的完整定义与数值表
- 附录 B（Byte Stream Format）：NAL 单元如何打包成字节流（
0x00000001起始码），这是理解第七章封装的入口
阅读时的两个抓手值得记住。其一，一切从 Slice 开始：一帧图像由一个或多个 Slice 组成，Slice 头里的 slice_type（I/P/B）决定了后续解码走哪条路。其二，参数集先行：SPS/PPS 这两个 NAL 单元承载了分辨率、Profile、量化默认参数等全局信息，码流解析的第一步永远是先读懂它们。
这套 "语法表 + 解码过程" 的文档范式，在 H.265、H.266 中一脉相承——会读 H.264，就拿到了整个 H.26x 家族的总钥匙。
下一节，我们带着这把钥匙走进 4K 时代：H.265/HEVC。