4、视频编解码基础：H.264/H.265编码原理、I/P/B帧、码率控制、GOP结构

各位同学，咱们今天聊聊视频编解码的基础。说实话，做嵌入式GPU加速，不懂视频编码原理，就像开车不看路——能跑，但迟早要翻车。我当年刚接触这个领域时，也踩过不少坑，今天把这些经验掰开揉碎了讲给你们听。

4.1 H.264与H.265：两代编码标准的核心差异

先说说H.264和H.265。很多人觉得H.265就是H.264的升级版，压缩率更高。这话没错，但太笼统了。我个人的理解是：H.264是「块匹配」的极致优化，而H.265是「区域划分」的革命。

H.264的核心是宏块（Macroblock），固定16x16像素。你想想看，一块蓝天白云，用16x16的块去编码，效率其实还行。但遇到复杂纹理，比如树叶、草地，16x16就不够灵活了。

H.265引入了编码树单元（CTU），大小可以从64x64一直细分到4x4。我在项目中遇到过这样一个场景：用H.264编码4K视频，码率飙到40Mbps还糊；换成H.265，同样码率下画质明显提升。说白了，H.265的灵活性让它在高分辨率场景下优势巨大。

4.2 I/P/B帧：三种帧类型的实战理解

帧类型这块，很多教材讲得文绉绉的。我换个说法：I帧是「定海神针」，P帧是「偷懒高手」，B帧是「左右逢源」。

I帧（关键帧）：完整编码一帧图像，不依赖其他帧。我建议在视频会议场景中，I帧间隔不要超过2秒。为什么？因为网络丢包时，解码器需要等到下一个I帧才能恢复画面。我曾经调试过一个摄像头产品，I帧间隔设了5秒，结果网络一抖，画面卡住5秒才恢复——用户直接投诉。

P帧（前向预测帧）：只记录与前一帧的差异。说白了，就是「我只画变化的部分」。比如一个静止的背景，P帧几乎不占带宽。但要注意：P帧的错误会向后传播。如果某个P帧数据丢了，后面的P帧都会受影响。

B帧（双向预测帧）：参考前后两帧，压缩率最高。但代价是编码延迟大。我在做实时直播系统时，就刻意减少了B帧数量。因为B帧需要等待后面的帧编码完才能解码，延迟受不了。

4.3 码率控制：CBR vs VBR vs CRF

码率控制，说白了就是「怎么分配带宽」。我见过太多新手一上来就设固定码率，结果画面要么糊成马赛克，要么浪费带宽。

CBR（固定码率）：每秒钟输出固定比特数。适合网络带宽稳定的场景，比如视频监控。但缺点很明显：画面简单时浪费，复杂时不够用。我记得有一次做安防项目，CBR设了4Mbps，结果夜晚画面全是噪点，码率却用不满。

VBR（可变码率）：根据画面复杂度动态调整。适合存储场景，比如录播。但峰值码率可能很高，对嵌入式设备的缓冲区是个考验。

CRF（恒定质量）：我个人最喜欢的方式。设定一个质量值（0-51，越低质量越好），编码器自动分配码率。比如CRF=23，画面质量稳定，码率自然浮动。但要注意：CRF无法控制最终文件大小，不适合有存储限制的场景。

4.4 GOP结构：决定压缩效率的关键

GOP（Group of Pictures），就是一组连续的帧。结构通常写成 MxNy，比如 M3N12 表示每3帧一个P帧，每12帧一个I帧。

GOP长度直接影响压缩率和随机访问能力：

• 短GOP（如0.5秒）：随机访问快，适合快进快退。但压缩率低。
• 长GOP（如4秒）：压缩率高，但一旦丢包，恢复时间也长。

我建议在嵌入式场景中，GOP长度设为2-3秒。为什么？因为嵌入式设备的解码缓冲区通常较小，太长的GOP会导致内存压力。另外，GPU加速时，GOP内的帧依赖关系会影响并行度。B帧越多，并行解码越难做。

// 一个典型的GOP结构示例（H.264）
// I帧 -> P帧 -> B帧 -> B帧 -> P帧 -> B帧 -> B帧 -> ...
// 显示顺序: 0  1  2  3  4  5  6
// 编码顺序: 0  3  1  2  6  4  5
// 注意B帧的编码顺序与显示顺序不同

嗯，这里要注意：B帧的编码顺序和显示顺序是错位的。GPU做硬件解码时，需要重新排序帧缓冲区。我刚开始做时没注意这个，结果画面时序全乱了，视频像抽风一样跳来跳去。

4.5 嵌入式GPU加速的实战要点

最后聊聊怎么把这些理论用到嵌入式GPU上。我个人总结了三条铁律：

1. I帧用硬件编码器，P/B帧用GPU：硬件编码器插I帧快且稳，GPU做运动估计和变换量化效率高。
2. GOP长度与GPU显存挂钩：显存小的设备，GOP别超过2秒。否则参考帧太多，显存爆了。
3. 码率控制优先选VBR：嵌入式场景带宽波动大，CBR容易丢帧，CRF又不可控。VBR配合码率峰值限制，最稳妥。

好了，这一章就到这里。下一章咱们会深入GPU的硬件架构，看看怎么用CUDA或OpenCL来加速这些编码算法。有什么问题，欢迎在群里讨论。