H.265/HEVC 编码深度解析：从 CTU 划分到帧间预测的压缩效率优化

H.265/HEVC 作为当前流媒体行业主流编码标准，承诺在相同画质下比 H.264 节省约 50% 码率。本文从编码单元 (CTU) 划分、帧内预测、帧间预测、码率控制四个层面，拆解 H.265/HEVC 提升压缩效率的核心机制，并基于 FFmpeg 实测数据，对比 H.264/H.265/AV1 在不同分辨率与内容下的码率-画质表现。

一、H.265/HEVC 编码原理概览

H.265/HEVC（High Efficiency Video Coding）由 ITU-T VCEG 与 ISO/IEC MPEG 联合制定，2013 年发布第一版标准，目标是 4K/8K、超高清视频的传输与存储。其核心思想是把 H.264 中的 16×16 宏块 (Macroblock) 扩展为 64×64 的编码树单元 (CTU, Coding Tree Unit)，并通过更灵活的划分、更丰富的预测模式提升压缩效率。

H.265 的编码流程可以拆为四步：

视频帧 → CTU 划分 → 预测 (帧内/帧间) → 变换/量化 → 熵编码 → 码流
↓
划分深度 0-3
最小 CU 8×8

每帧图像会被切成若干 CTU（最大 64×64），每个 CTU 可以继续按四叉树递归划分为 CU (Coding Unit)。划分结果直接影响压缩效率：平坦区域适合大 CU，运动复杂区域适合小 CU。H.265 引入了多达 35 种帧内预测模式（H.264 只有 9 种），帧间预测也从 H.264 的 7 种运动矢量预测模式扩展到 AMVP（Advanced Motion Vector Prediction）和 Merge 模式。

二、CTU 四叉树划分机制

2.1 划分粒度

H.264 中宏块大小固定为 16×16，最小子块到 4×4。H.265 引入了可配置的 CTU 深度：

四叉树划分的核心收益是自适应：同一帧内不同区域可以根据内容选择不同粒度，告别 H.264 “一刀切” 的 16×16 粒度。

2.2 FFmpeg 中的划分控制

通过 x265 编码器的命令行参数可以控制划分行为：

# CTU 大小限制在 32（默认 64）
ffmpeg -i input.mp4 -c:v libx265 -x265-params "ctu=32" output.mp4

# 限制最大划分深度（默认 4，对应 CTU 64）
ffmpeg -i input.mp4 -c:v libx265 -x265-params "max-tu-size=4" output.mp4

# 启用早期终止，跳过不可能的划分深度
ffmpeg -i input.mp4 -c:v libx265 -x265-params "early-skip=1" output.mp4

max-tu-size=4 表示最大 TU 深度为 4，对应 CTU 64 划分到 8×8；降低该值可以减少编码时间但会损失一定压缩效率。early-skip=1 会在预测残差足够小时提前终止四叉树递归，是 H.265 编码速度优化的重要开关。

2.3 划分的计算开销

四叉树划分是 H.265 编码器最耗时的环节之一。一个 1080p 帧包含约 8160 个 CTU（1920×1080/(64×64) 向上取整），每个 CTU 需要遍历 4 个深度，理论上每帧需评估约 30000+ 划分组合。x265 通过 SATD（Sum of Absolute Transformed Differences）作为快速判据，将单帧划分决策控制在毫秒级。

三、帧内预测：35 种模式的细节博弈

3.1 模式分类

H.265 的帧内预测包含 35 种模式：

• DC 模式（1 种）：用周围参考像素的平均值填充
• Planar 模式（1 种）：水平+垂直双线性插值，适合平滑渐变
• 角度模式（33 种）：从水平到垂直方向的角度预测，编号 2-34

33 种角度分布不是均匀的，从 0°（DC）到 90°（垂直）覆盖全方向，对纹理的方向性敏感。

3.2 不同尺寸 CU 的模式选择

大尺寸 CU 之所以限定为 4 种模式，是因为 64×64 全模式搜索在 4K 编码时计算量过大会导致实时性崩溃。编码器通过 RDO（率失真优化）选出代价最小的模式：

J = D + λR
D：失真（原始块与重建块的 SAD/SSD）
R：编码比特数
λ：拉格朗日乘子，与 QP 挂钩

3.3 帧内预测的代码验证

x265 提供 –log-level full 输出每帧的帧内模式分布：

ffmpeg -i input.mp4 -c:v libx265 -x265-params "log-level=full" -t 5 out.mp4 2>&1 | grep "Intra mode"

输出形如：

Intra mode L 64×64: DC=2 Planar=85 Ang=915
Intra mode L 32×32: DC=15 Planar=120 Ang=1850

通过统计可以看到大尺寸 CU 普遍使用 Planar 和 DC 模式（平坦背景），而小尺寸 CU 才进入角度模式的密集分布。

四、帧间预测：AMVP 与 Merge

4.1 块结构升级

H.264 的帧间预测最小块是 4×4，最大 16×16。H.265 引入 PU (Prediction Unit) 概念，最小块保持 4×4，但允许非对称划分（如 32×8、8×32），更好地贴合运动对象的真实形状。

H.265 PU 划分类型（部分）：
PART_2N×2N 对称方块
PART_2N×N 水平二等分
PART_N×2N 垂直二等分
PART_2N×nU 上 1/4 + 下 3/4 非对称
PART_2N×nD 上 3/4 + 下 1/4 非对称
PART_nL×2N 左 1/4 + 右 3/4 非对称
PART_nR×2N 左 3/4 + 右 1/4 非对称

非对称划分对竖向运动（如人物站立、车辆行驶）的场景压缩效率提升显著，避免了 H.264 中 16×16 一刀切导致的运动边界冗余。

4.2 AMVP 与 Merge 模式

H.265 帧间预测的核心创新是 AMVP（Advanced Motion Vector Prediction）：

• 候选列表：编码器从已编码块中获取最多 2 个运动矢量候选
• MV 预测：根据候选 MV 计算当前块的预测 MV
• MVD：编码预测 MV 与真实 MV 的差值（MVD = MV_real – MV_pred）
• 码率节省：直接编码 MVD 而非完整 MV，节省运动矢量比特数

Merge 模式是 AMVP 的特例：直接继承候选块的完整运动信息（MV + 参考帧索引），MVD=0，码率最低。Merge 模式适合"刚体运动"（整块平移、无旋转缩放）场景。

4.3 FFmpeg 帧间参数

# 关闭 Merge 模式（一般不要这么做，仅作性能测试）
ffmpeg -i input.mp4 -c:v libx265 -x265-params "no-merge=1" output.mp4

# 限制 Merge 候选数（默认 5）
ffmpeg -i input.mp4 -c:v libx265 -x265-params "max-merge=3" output.mp4

# 启用亚像素运动估计（默认开启，pme 算法）
ffmpeg -i input.mp4 -c:v libx265 -x265-params "pmode=1:pme=1" output.mp4

实测 1080p 视频时，关闭 Merge 模式后码率平均上升 8-12%，但编码速度提升约 15%。Merge 模式对背景静止或缓慢运动的场景效率最高。

五、码率控制：CQP、CRF、ABR、2PASS

5.1 四种模式对比

H.265 编码器（x265）支持 4 种码率控制模式：

5.2 推荐参数

直播场景（延迟敏感）：

ffmpeg -i input.mp4 -c:v libx265 -preset ultrafast -x265-params "bitrate=4000:vbv-bufsize=8000:vbv-maxrate=4500" -f flv out.flv

点播场景（画质优先）：

ffmpeg -i input.mp4 -c:v libx265 -preset slow -crf 22 -x265-params "pass=2:bitrate=4000" output.mp4

vbv-bufsize 与 vbv-maxrate 配合用于流媒体带宽约束编码，防止瞬时码率超出 CDN 限制。

六、实测对比：H.264 vs H.265 vs AV1

测试条件：Intel i7-12700H、5 段 1080p 30fps 视频（电影、动画、运动、屏幕录制、风景），CRF 23（统一质量基准），SSIM 评估画质。

几个关键发现：

七、H.265 的限制与坑

7.1 专利费问题

H.265 专利由多家公司持有（HEVC Advance、Velos Media 等），商业使用需要授权。2020 年起部分专利到期但核心专利仍受保护。开源项目 x265 在 GPLv2 下使用，商业产品需评估专利风险。2020 年开放的 VVC/H.266 暂未广泛部署，主要因为生态成熟度不足。

7.2 浏览器与设备兼容性

服务器端转码并通过 HLS 投递是兼容性的最稳妥方案。直接用 HEVC MP4 在 Web 端播放仍然不通用。

7.3 编码速度瓶颈

H.265 编码速度通常是 H.264 的 1/3-1/5。即使 x265 preset fast，实时编码 1080p30 仍需 i7 级 CPU。专业场景（直播、流媒体点播转码）通常采用硬件编码器（NVIDIA NVENC、Intel QSV、苹果 VideoToolbox），但硬件编码器只支持部分参数（无 Merge、无高级 AMVP），压缩效率比 x265 软编低 15-25%。

7.4 存储与传输的实际收益

码率节省 50% 在传输和存储上的实际收益需要乘以"内容可压缩性"。高动态范围（爆炸、运动、烟花）内容，H.265 节省幅度可能只有 25%；低动态范围（屏幕录像、PPT、动画），H.265 节省幅度可达 60%。不能简单按"一半码率"预估容量。

八、选型建议 FAQ

Q1：我的项目应该选 H.264 还是 H.265？

看用户设备的解码能力。Web 端为主用户（尤其 iOS Safari、Chrome 老版本）选 H.264；客户端应用（手机 App、TV 应用、桌面软件）能控制解码端，优先 H.265；4K/8K 内容必须 H.265 或更新编码。

Q2：CRF 23 在 H.264 和 H.265 是同画质吗？

不严格相同。x264 CRF 23 与 x265 CRF 23 的 SSIM 差异约 0.005-0.01，x265 略优。实际生产中两者分别调整：x264 推荐 CRF 18-23，x265 推荐 CRF 20-28。

Q3：H.265 2PASS 编码的耗时是 1PASS 的几倍？

理论 2 倍，实际 1.8-2.2 倍（第一遍分析 + 第二遍编码）。如果点播内容不要求极致画质，单遍 ABR 加 vbv-bufsize 已足够。

Q4：H.265 SVC（可分级编码）有什么实际应用？

SVC 允许同一码流中提取不同分辨率/帧率/质量的子流，理论上适合自适应码率（ABR）流媒体。但实际部署中，HLS/DASH 多码流方案更成熟，SVC 主要用于视频会议（WebRTC、Tencent Meeting）和监控领域。

Q5：x265 与硬件编码器（NVENC/QSV）选哪个？

直播：硬件编码器（延迟低、功耗小、CPU 占用少）。点播/归档：x265 preset slow（压缩效率高 15-25%）。混合方案：硬件编码器初编 + x265 二遍转码，平衡速度与质量。

Q6：未来会被 AV1 取代吗？

短期不会。AV1 编码端软硬件生态（libaom/SVT-AV1/rav1e 性能、硬件编码器普及度）还在追赶。YouTube/Netflix 已部署 AV1，但 5 年内 H.264+H.265 仍是绝对主流。WebCodecs API 同时支持 H.264、H.265、AV1、VP9 多编解码器，正是这种长期共存格局的反映。

写在最后

H.265/HEVC 不是一个"万能编码器"，它是为高分辨率场景设计的折中方案：相比 H.264 多 50% 压缩效率、相比 AV1 多 5-10 倍编码速度、相比 H.264 多 3-5 倍解码功耗。编码器选型本质是在画质、码率、速度、兼容性四个维度做加权决策——而这些权重因业务场景差异极大。

理解 CTU 划分、帧内/帧间预测、码率控制的原理，不是为了"调参调出最佳画质"，而是在遇到实际压缩问题时能快速定位瓶颈：是划分粒度选错、是预测模式被禁用、还是码率控制策略没匹配场景。工具会更新换代，但编码的"预测-残差-熵编码"基本结构 30 年没变过。

工程实践中还有一个常见诉求：把视频压到指定的文件大小（上传平台限制、邮件附件阈值、节省存储成本）。这个需求用 CRF 模式难以精确控制，必须切换到 2PASS 或 ABR 模式并指定目标码率，再根据源视频时长反算总比特数。不同分辨率/帧率下"目标体积"对应的码率范围差异很大（如 1080p 30fps 1 分钟压到 10MB，平均码率约 1.4Mbps），需要结合实际场景反复调试。