HEVC编码基础：核心概念、编码流程与H.264对比
2.1 HEVC标准的核心设计目标
HEVC（High Efficiency Video Coding，又称H.265）由ITU-T VCEG与ISO/IEC MPEG联合组成的JCT-VC组织制定，于2013年正式发布。它的核心目标非常明确：在同等主观画质下，相比H.264/AVC节省约50%的码率。这一目标并非简单的参数调优，而是对整个编码框架进行了系统性重构——从块划分方式、帧内预测方向、运动补偿精度到环路滤波与熵编码，每一层都引入了新的工具。
理解HEVC，首先要抓住一个关键变化：编码树单元（CTU）与四叉树划分。H.264使用固定大小的宏块（16×16），而HEVC引入了更大且可递归划分的CTU（默认64×64），并允许通过四叉树结构灵活切分为不同尺寸的编码单元（CU）。这种设计让编码器能够根据图像局部纹理复杂度自适应选择块大小：平坦区域用大块编码，细节丰富区域用小块编码，从而大幅提升编码效率。
- CTU（Coding Tree Unit）：编码的根节点，通常为64×64像素，可递归四叉树划分。
- CU（Coding Unit）：决定采用帧内还是帧间预测的基本单元，最小可至8×8。
- PU（Prediction Unit）：在CU基础上进一步划分，用于实际预测操作，支持非对称划分。
- TU（Transform Unit）：负责残差变换的单元，最大支持32×32变换块。
2.2 HEVC编码流程：从原始帧到码流
HEVC编码器的整体流程延续了混合编码框架（预测+变换+熵编码），但每个模块内部都有显著升级。下面按编码器处理顺序梳理关键步骤：
- 块划分（CTU Partition）：将输入帧划分为多个CTU，每个CTU通过率失真优化（RDO）递归决定四叉树划分结构，得到最优CU布局。
- 帧内预测（Intra Prediction）：HEVC提供35种帧内预测模式（33种角度模式 + DC + Planar），相比H.264的9种大幅增加，能更精细地预测纹理方向。
- 帧间预测（Inter Prediction）：采用更先进的多参考帧运动估计，运动补偿精度支持1/4像素，且运动矢量预测（MVP）机制更高效。
- 变换与量化：残差信号经DCT变换（帧内亮度残差可用DST），变换块尺寸从4×4到32×32自适应选择，量化参数（QP）范围扩展至0~51。
- 环路滤波：包括去块效应滤波（DBF）和样本自适应偏移（SAO）。SAO是HEVC新增工具，通过为每个CTU添加偏移量减少振铃伪影。
- 熵编码：采用CABAC（上下文自适应二进制算术编码），并针对HEVC的块结构优化了上下文模型与二进制化过程。
2.3 HEVC与H.264关键差异对比
| 对比维度 | H.264/AVC | HEVC/H.265 | 对硬件的影响 |
|---|---|---|---|
| 块结构 | 宏块固定16×16 | CTU最大64×64，四叉树递归 | 需要动态块划分引擎，存储与调度更复杂 |
| 帧内预测模式 | 9种（4×4亮度） | 35种（含Planar/DC/33角度） | 预测方向计算量增加，需并行比较器阵列 |
| 变换块尺寸 | 4×4 / 8×8 | 4×4 ~ 32×32 | 需要多尺寸DCT/DST引擎，支持蝶形复用 |
| 运动补偿精度 | 1/4像素（6-tap） | 1/4像素（8-tap + 7-tap） | 插值滤波器抽头数增加，带宽需求上升 |
| 环路滤波 | 仅去块效应滤波 | DBF + SAO | SAO需额外统计与补偿逻辑 |
| 熵编码 | CAVLC / CABAC | CABAC（优化） | CABAC吞吐要求更高，需多桶并行架构 |
| 参考帧管理 | 最多16帧 | 最多16帧（DPB更大） | DPB存储带宽需求增加 |
2.4 典型编码场景与硬件加速切入点
以4K@60fps视频编码为例，假设分辨率为3840×2160，帧率60fps，像素时钟约500MHz。若使用H.264编码，在中等码率下（约40Mbps）需要约2~3 TOPS的计算能力；而HEVC在同等画质下码率可降至20Mbps，但计算复杂度反而提升约2~4倍，尤其在运动估计和SAO环节。因此，纯软件编码难以满足实时需求，硬件加速成为必然选择。
在实际的硬件编码器设计中，通常将HEVC编码流程划分为多个硬件模块：
硬件编码器典型流水线（以Xilinx FPGA为例）
----------------------------------------------
输入帧 → 帧缓冲（DDR4） → CTU划分引擎 → 帧内/帧间预测
→ 残差生成 → DCT/DST变换 → 量化 → 熵编码（CABAC）
→ 重建环路（反量化/反变换 + 预测补偿） → DBF → SAO → 参考帧存储
2.5 案例复盘：从H.264迁移到HEVC的硬件设计教训
某团队在开发H.264编码器后，计划快速推出HEVC版本。他们最初保留了原有的宏块级流水线，仅将块大小改为64×64，并添加了SAO模块。结果在FPGA原型验证时发现：
- 问题1：CTU划分深度不同导致各流水级处理时间差异极大，最坏情况下（全16×16划分）一个CTU的处理时间是平坦区域（64×64）的6倍，流水线频繁停顿。
- 问题2：SAO需要统计每个CTU的像素分类信息，但原架构中重建像素以光栅扫描顺序输出，SAO统计模块不得不等待整个CTU完成重建，增加了延迟。
- 问题3：CABAC的上下文建模依赖相邻块信息，在四叉树结构下，相邻块的位置关系不再像宏块那样规整，导致上下文读取逻辑复杂化。
最终他们重新设计了以CTU为中心的调度架构，将RDO预判决与精细编码分离，并采用双缓冲机制处理SAO统计。经过重构后，编码器在同等主频下吞吐量提升了约40%，才达到4K@30fps的实时目标。这个案例说明：HEVC硬件加速不是简单替换模块，而是需要从块调度、存储层次和流水线结构上重新设计。
- HEVC的核心优势来自CTU四叉树划分、35种帧内预测、SAO滤波和优化的CABAC。
- 编码流程中，CTU划分的RDO是硬件设计最大难点，需要预判决与精细两级策略。
- 与H.264相比，HEVC在块结构、变换尺寸、滤波和熵编码上均有本质变化，硬件架构必须适配。
- 从H.264迁移到HEVC时，切忌只改参数不改架构，应重点重构块调度与流水线。