3、H265编码基础：从CTU到量化，一次讲透
好，咱们进入H265的世界。说实话，当年我从H264转向H265时，第一感觉是「这玩意儿怎么这么复杂」。但跑过几个项目后，我发现它的核心逻辑其实很清晰——用更精细的划分，换更高的压缩率。
今天这一章，我会把H265最关键的几个概念串起来讲。你不需要死记硬背，理解它「为什么这么设计」更重要。
3.1 H265标准概述——它到底强在哪？
H265，也叫HEVC（High Efficiency Video Coding）。名字里就带着「高效」二字。相比H264，它在同等画质下能省下30%~50%的码率。
我个人的经验是：在WebRTC场景里，带宽吃紧的时候，H265的优势特别明显。同样是1Mbps，H264可能已经开始糊了，H265还能保持不错的细节。
核心提升点：
- 编码单元从16x16扩展到最大64x64
- 支持更多帧内预测模式（35种 vs H264的9种）
- 引入SAO（样点自适应补偿）去块效应
- 并行处理能力更强（Tile、WPP）
但注意，H265不是没有代价。它的编码复杂度大约是H264的2~3倍。我在做移动端适配时，就遇到过低端芯片跑不动H265编码的情况。所以选不选H265，得看你的目标设备。
3.2 CTU/CU/PU划分——从大块到小块
这是H265最核心的变化之一。H264里，宏块大小固定是16x16。H265呢？它引入了CTU（编码树单元），最大可以到64x64。
你想想看，一块平坦的天空，用64x64一个块就能搞定，多省码率。而到了细节丰富的区域，再递归切分成32x32、16x16，甚至8x8。
我的习惯：在WebRTC里，如果画面运动少（比如视频会议），我会倾向于用大CTU（64x64）。如果画面运动剧烈（比如直播游戏），小CTU（32x32或16x16）反而更稳。
CTU往下分，就是CU（编码单元）。CU是真正做预测和变换的基本单位。每个CU可以独立选择帧内或帧间预测。
PU（预测单元）呢？它是在CU基础上，为了做运动补偿而进一步划分的。比如一个32x32的CU做帧间预测，可以拆成两个32x16的PU，分别做运动估计。
我画了张图，帮你理清这个层级关系：
我曾经踩过的坑：在低码率场景下，如果CTU切分太深（比如全是8x8），反而会增加码率。因为每个小块都需要独立的预测信息。所以H265的编码器里，通常有个「率失真优化」来决定切分深度。别自己硬编码固定深度。
3.3 帧内与帧间预测——H265的「猜」术升级了
预测的本质是什么？说白了就是「猜」。用已经编解码的像素，去猜当前块的值。猜得越准，残差越小，码率越低。
帧内预测：35种方向，总有一款适合你
H264只有9种帧内预测模式。H265直接干到了35种——33种角度模式 + DC模式 + Planar模式。
| 预测模式 | 数量 | 说明 |
|---|---|---|
| Planar | 1 | 平滑渐变，适合平坦区域 |
| DC | 1 | 平均值填充，适合纹理简单区域 |
| 角度模式 | 33 | 覆盖从近水平到近垂直的各种方向 |
我在做屏幕共享编码时，发现Planar模式对PPT里的渐变背景特别有效。而角度模式对文字边缘的斜线有奇效。
帧间预测：运动估计更精细了
帧间预测这块，H265最大的变化是——运动矢量精度从H264的1/4像素提升到了1/8像素（亮度分量）。
你可能会问：「1/8像素有意义吗？」有。在低分辨率或慢速运动的场景下，1/8像素的精度能明显减少残差。但代价是计算量暴增。我建议在WebRTC里，如果CPU吃紧，可以限制到1/4像素。
另外，H265还引入了Merge模式和AMVP（高级运动矢量预测）。Merge模式说白了就是「偷懒」——直接用相邻块的运动矢量。对于大面积相同运动的区域（比如背景），能省下不少比特。
实战建议：在WebRTC的H265编码器配置里，我通常会开启Merge模式，但限制最大Merge候选数为2。太多候选反而会引入噪声。
3.4 变换与量化——残差的「压缩」艺术
预测做完，剩下的就是残差了。残差数据通常有空间相关性，变换的作用就是把这些相关性去掉，把能量集中到低频系数上。
变换：从4x4到32x32
H265支持4种变换块大小：4x4、8x8、16x16、32x32。相比H264最大8x8，H265的32x32变换对平坦区域更友好。
我个人的经验是：对于视频会议这种以人脸为主的场景，16x16变换用得最多。而对于屏幕共享（尤其是代码或表格），4x4和8x8更合适，因为文字边缘的高频信息多。
H265用的还是DCT（离散余弦变换），但针对4x4的帧内残差，额外引入了DST（离散正弦变换）。为什么？因为帧内预测的残差在边界处有特殊的分布特性，DST能更好地去相关。
量化：QP的选择是个技术活
量化是编码器里唯一有损的环节。QP（量化参数）越大，细节丢失越多，码率越低。
H265的QP范围是0~51，和H264一样。但同样的QP值，H265的量化步长更精细。所以你在H264里用QP=28，换到H265里可能QP=30就能达到同等画质。
量化矩阵：H265支持自定义量化矩阵。我曾在某个项目中，针对屏幕共享内容定制了高频抑制更强的矩阵，码率降了15%，文字依然清晰。但注意，自定义矩阵需要编码器支持，不是所有WebRTC实现都开放了这个接口。
3.5 本章小结——一张图看懂H265编码流程
最后，我把H265的编码流程串起来，画了张流程图。你对照着看，应该能更清楚每个环节的位置。