3、编码核心原理对比（一）：宏块与编码树单元（CTU）的差异

聊到 H.264 和 H.265 的核心区别，我第一个想到的就是它们处理图像的基本单元。说白了，就是「切蛋糕」的方式完全不同。

H.264 用的是宏块（Macroblock，MB），大小固定为 16x16 像素。H.265 换成了编码树单元（Coding Tree Unit，CTU），大小可以灵活选择，最大能到 64x64。你想想看，这就像切披萨——H.264 只能切成统一大小的方块，而 H.265 可以根据馅料分布，大块切、小块切，灵活多了。

3.1 宏块（MB）：H.264 的「老规矩」

H.264 把每一帧图像划分成若干个 16x16 的宏块。每个宏块独立处理，包含亮度（Y）和色度（Cb、Cr）信息。我记得刚接触 H.264 时，总觉得这个 16x16 的尺寸有点「死板」。后来做项目才发现，它其实也有好处——硬件实现简单，内存访问模式固定。

宏块内部还可以进一步划分成更小的子块，用于运动估计：

• 16x16：适用于平坦区域，比如天空、墙壁。
• 16x8、8x16：适用于有水平或垂直边缘的区域。
• 8x8：适用于纹理较复杂的区域。
• 8x4、4x8、4x4：适用于细节丰富的区域，比如草地、头发。

但注意，无论怎么划分，宏块本身始终是 16x16 的「大框」。子块只是在这个框内做运动补偿。我曾经在优化一个低码率视频编码器时，发现 16x16 的宏块在 4K 分辨率下显得「力不从心」。为什么呢？因为大块平坦区域（比如蓝天）用 16x16 编码，块数太多，码流开销反而上去了。

3.2 编码树单元（CTU）：H.265 的「新武器」

H.265 引入了编码树单元（CTU），取代了宏块。CTU 的大小可以配置为 16x16、32x32 或 64x64。我个人习惯在 4K 及以上分辨率时使用 64x64，在 1080p 时用 32x32。为什么？因为大 CTU 能更好地利用图像的局部相关性。

CTU 可以递归地划分为更小的编码单元（CU），划分方式是一棵四叉树：

• 一个 64x64 的 CTU 可以分成 4 个 32x32 的 CU。
• 每个 32x32 的 CU 又可以分成 4 个 16x16 的 CU。
• 以此类推，直到最小的 8x8 CU。

这种树形结构的好处是：平坦区域用大 CU，纹理复杂区域用小 CU。你想想看，这比 H.264 的固定宏块灵活太多了。我在项目中遇到过这样一个场景：一段视频中，上半部分是静态的蓝天，下半部分是动态的树叶。用 H.265 的 CTU，蓝天部分自动选择了 64x64 的大 CU，树叶部分则分裂到 8x8 的小 CU。最终码率比 H.264 降低了约 35%。

3.3 核心差异对比

我把两者的关键差异整理成了一张表，方便你对照：

对比维度	H.264 宏块（MB）	H.265 编码树单元（CTU）
基本单元大小	固定 16x16	16x16 / 32x32 / 64x64（可配置）
划分方式	固定网格，子块仅用于运动估计	四叉树递归划分，CU 大小可变
最小子块	4x4	8x8
适用分辨率	标清、720p 以下	1080p、4K、8K
编码效率	基准	同等质量下码率降低 30%~50%
硬件复杂度	低，内存访问规整	高，需要树形遍历和动态内存分配

嗯，这里要注意：H.265 的 CTU 虽然灵活，但代价是编码器的复杂度大幅上升。我曾经调试过一个 H.265 编码器，CTU 划分的决策树深度达到 4 层，每个节点都要计算率失真代价。如果不做优化，编码速度会慢得让人抓狂。

3.4 从宏块到 CTU：为什么必须变？

你可能会问：H.264 的宏块用了这么多年，为什么 H.265 非要改成 CTU？

原因很简单——分辨率爆炸。4K 视频的分辨率是 3840x2160，如果用 16x16 的宏块，一帧就有 51840 个宏块。每个宏块都需要独立的编码参数（预测模式、运动矢量、量化参数等），这些参数本身就要占用码流。说白了，宏块太多，参数开销就把码率吃掉了。

CTU 的 64x64 尺寸，在 4K 下每帧只有 3240 个 CTU。参数数量直接减少到原来的 1/16。再加上大 CU 能更好地利用空间冗余，压缩率自然就上去了。

3.5 知识体系结构图

下面这张 SVG 图展示了宏块与 CTU 的核心差异和演进关系：

从这张图可以看得很清楚：H.264 的宏块是「一刀切」的固定网格，子块划分只影响运动估计。而 H.265 的 CTU 是「自适应」的四叉树结构，编码单元的大小可以根据图像内容动态调整。这就是 H.265 能在同等质量下节省 30%~50% 码率的根本原因之一。