H264编码基础：从标准到实战
做WebRTC开发这些年，我接触最多的视频编码就是H264。说实话，它虽然“老”，但生态太成熟了。浏览器、手机、摄像头，几乎都支持。今天咱们就把它最核心的几个概念掰开揉碎讲清楚。
H264标准到底在说什么？
H264，也叫AVC（Advanced Video Coding），是ITU-T和ISO/IEC联合搞的标准。它的目标很明确：用更少的带宽传更清晰的画面。
我刚开始接触时，觉得标准文档又厚又难啃。后来发现，你不需要背所有细节。抓住几个关键点就够了：
- 分层结构：视频编码层（VCL）负责压缩，网络抽象层（NAL）负责传输
- 帧内预测：利用空间冗余，同一帧内像素互相参考
- 帧间预测：利用时间冗余，前后帧互相参考
- 变换量化：把像素数据转到频域，丢掉人眼不敏感的信息
说白了，H264就是一套“怎么把视频变小，还能看清”的方法论。
NAL单元结构：视频的“快递包裹”
在WebRTC里，视频数据最终都是通过RTP包传出去的。而H264的NAL单元，就是这些包的“内容载体”。
每个NAL单元长这样：
+---------------+-------------------------------+
| 起始码(0x000001) | NAL头(1字节) | RBSP数据 |
+---------------+-------------------------------+
NAL头只有1个字节，但信息量很大：
| 位 | 含义 | 说明 |
|---|---|---|
| bit 7 | forbidden_zero_bit | 必须为0，否则表示语法错误 |
| bit 6-7 | nal_ref_idc | 重要性标识，00=不参考，11=最重要 |
| bit 0-4 | nal_unit_type | 单元类型，1-5是VCL，6-12是非VCL |
我在项目中遇到过一个问题：对方发来的视频花屏，排查半天发现是NAL单元类型解析错了。嗯，这里要注意，nal_unit_type 的值决定了这个单元是I帧、P帧还是参数集。搞错了，解码器直接罢工。
常见NAL类型速查
- 1：非IDR的片（P帧/B帧）
- 5：IDR片（关键帧）
- 7：序列参数集（SPS）
- 8：图像参数集（PPS）
- 9：访问单元分隔符
帧类型：I/P/B帧，谁是谁的参考？
这是面试常考题，也是实际开发最容易踩坑的地方。
I帧（关键帧）：完整编码的一帧，不依赖其他帧。解码器可以从I帧开始解码。缺点是体积大。
P帧（前向预测帧）：只编码与前一帧的差异。体积小，但依赖前面的I帧或P帧。
B帧（双向预测帧）：参考前后两帧。压缩率最高，但解码延迟大。
你想想看，WebRTC这种实时通信场景，B帧其实不太受欢迎。为什么？因为它需要等后面的帧到了才能解码，会增加延迟。我一般建议在WebRTC里只用I帧和P帧，或者最多用低延迟的B帧变种。
实战建议：在WebRTC中，I帧间隔通常设为2-3秒。太频繁浪费带宽，太少则丢包后恢复慢。我曾经把I帧间隔设到10秒，结果网络抖动一次，画面卡了快10秒才恢复——教训深刻。
SPS/PPS参数集：解码器的“说明书”
SPS（序列参数集）和PPS（图像参数集）是H264里最重要的非VCL单元。没有它们，解码器根本不知道该怎么解码。
SPS 包含整个视频序列的全局参数：
- Profile和Level（决定编码能力）
- 分辨率（宽、高）
- 帧率
- 参考帧数量
PPS 包含每帧的编码参数：
- 熵编码模式（CABAC还是CAVLC）
- 量化参数初始值
- 去块滤波开关
在WebRTC里，SPS和PPS通常放在I帧前面一起发送。如果丢失了，解码器就无法解码后续所有帧。我见过一个线上问题：SPS偶尔丢包，导致视频间歇性黑屏。解决方案是把SPS/PPS放在RTP的FEC保护里，或者定期重复发送。
注意：SPS和PPS的NAL头中，nal_ref_idc 必须设为11（最高优先级）。有些编码器默认设成00，会导致接收端忽略这些参数集。我曾经排查过这个问题，花了两天时间才发现是编码器配置写错了。
知识体系总览
下面这张图，把H264编码基础的核心概念串起来了。我建议你保存下来，以后遇到问题可以快速回顾。
实战中的几个坑
最后分享几个我踩过的坑，希望能帮你少走弯路：
- NAL单元边界识别：H264有两种封装格式——Annex B（用起始码0x000001分隔）和AVCC（用长度字段）。WebRTC里两种都可能遇到，解析时一定要判断清楚。
- SPS/PPS重复发送：有些编码器只在编码开始时发一次SPS/PPS。如果网络丢包，接收端就永远拿不到。我习惯在每5个I帧里重复一次SPS/PPS，稳妥。
- Profile和Level匹配：编码器设了High Profile，但解码器只支持Baseline，画面直接绿屏。在WebRTC里，建议统一用Constrained Baseline Profile，兼容性最好。
嗯，H264的基础就这些。别看概念多，实际用起来就是“NAL头解析 + 帧类型判断 + 参数集管理”这三板斧。搞懂了，后面H265的适配就轻松多了。