H.265（High Efficiency Video Coding，也称 HEVC）是一种视频编码标准，目标是在接近相同主观画质下比 H.264（AVC） 使用更低码率，代价是编码端和解码端的算法复杂度更高。
它常见于 4K/8K 视频、带宽受限的流媒体、监控录像和移动设备录像。对没有 硬件解码 支持的设备来说，H.265 通常比 H.264 更容易把 CPU 打满。
核心问题
原始视频数据量很大。编码器需要把相邻像素、相邻帧之间的重复信息压缩掉；解码器需要按码流中的指令把画面重建出来。
H.265 的设计重点是：在更高分辨率下，用更灵活的块结构、更强的预测方式和更细的滤波来节省码率。它不是简单把 H.264 换个文件后缀，而是在“如何把一帧拆块、如何预测、如何表达残差、如何滤波”上都做了更复杂的选择。
核心对象
| 对象 | 作用 | 与 CPU 成本的关系 |
|---|---|---|
| picture / frame | 被编码的一帧图像 | 分辨率越高，待处理像素越多 |
| CTU（Coding Tree Unit） | H.265 的基本大块，最大通常可到 64x64 亮度样本 | 比 H.264 的 16x16 macroblock 更灵活，但遍历和调度更复杂 |
| CU / PU / TU | 编码单元、预测单元、变换单元 | 决定块如何继续切分、如何预测、如何做变换 |
| reference picture | 已解码并可被后续帧引用的参考帧 | 影响帧间预测和内存访问 |
| motion vector | 指向参考帧中相似区域的位移 | 解码时用于运动补偿，不是普通图像坐标复制 |
| residual | 原始块和预测块之间的差值 | 经过反量化、反变换后加回预测块 |
| entropy bitstream | 熵编码后的压缩比特流 | 解码时需要按上下文逐符号解析 |
| in-loop filter | 解码环路内滤波，例如 deblocking 和 SAO | 改善块边界和量化伪影，但增加计算 |
核心机制
H.265 解码器的典型流程可以拆成：
- 从容器中取出 H.265 码流单元，解析参数集、slice、tile 等结构。
- 用熵解码还原块划分、预测模式、运动向量和量化后的残差系数。
- 按 CTU 开始处理一帧，递归拆成不同大小的 CU、PU、TU。
- 对每个预测块做帧内预测或帧间预测，得到
prediction_block。 - 对残差系数做反量化和反变换，得到
residual_block。 - 把预测块和残差块相加，生成初步重建块。
- 对重建图像做 deblocking、SAO 等环路滤波。
- 把完成的帧输出，同时把可引用的帧保存在参考帧队列里。
一个最小重建公式是：
reconstructed_block = prediction_block + inverse_transform(inverse_quantize(coefficients))coefficients是码流里经过量化和熵编码保存的残差系数，不是原始像素。inverse_quantize(...)把量化后的整数系数放回近似尺度；这是有损压缩的一部分，不能恢复被量化丢掉的信息。inverse_transform(...)把频域或变换域的残差信息转回像素块上的差值。prediction_block来自同一帧邻近像素的帧内预测，或来自参考帧的帧间预测。+是逐像素相加，再经过裁剪得到合法像素范围。
这条公式解释了为什么解码器不是“播放压缩文件”这么简单：它要为每个块解析语法、生成预测、重建残差、处理边界和维护参考帧。
为什么软解码通常比 H.264 更耗 CPU
在同分辨率、同帧率、相近画质和没有硬解的前提下，H.265 软解码通常比 H.264 更耗 CPU，主要来自几类开销：
- 块结构更灵活：H.265 用 CTU/CU/PU/TU 分层结构，块大小和划分形态比 H.264 更丰富，解码调度和边界处理更复杂。
- 预测模式更多：帧内预测方向更多，帧间预测和运动补偿也有更多细节，虽然解码器不做编码端的搜索，但仍要执行码流指定的预测过程。
- 熵解码和上下文更多：H.265 的 CABAC 语法和上下文建模更复杂，串行依赖更强，难以完全并行化。
- 环路滤波更多：除 deblocking 外，H.265 还引入 SAO（Sample Adaptive Offset）等滤波步骤，改善画质但增加每帧计算。
- 高位深和高分辨率更常见：很多 H.265 内容是 10-bit、4K 或 HDR；CPU 压力常常同时来自编码标准和内容规格。
H.265 的优势是降低码率，例如同等主观画质下可能比 H.264 少用不少带宽或存储。但省下的是 I/O 和传输，不代表 CPU 解码一定更省。
体积与画质关系
如果比较的是“看起来差不多的画质”，H.265 文件体积通常会比 H.264 小，常见经验范围大致是少二三成到接近一半。这个结论依赖编码器、preset、码率控制、分辨率、帧率、画面内容和主观质量标准。
需要区分三种比较方式：
| 比较方式 | 结论 |
|---|---|
| 同画质目标 | H.265 通常体积更小 |
| 同文件体积或同码率 | H.265 通常画质更好 |
| 同编码速度或低延迟设置 | H.265 优势可能缩小，甚至被差的硬件编码器抵消 |
“小很多”通常在 4K、高分辨率、运动规律、噪声较少的视频上更明显；在低分辨率、强噪声、胶片颗粒、快速运动、极低延迟或硬件编码器质量较差的场景里，优势会变小。
工程用途
- 4K/8K 流媒体、点播视频和高分辨率本地媒体。
- 监控、行车记录仪、采集系统中的长时间录像。
- 移动设备录像和带宽受限上传。
- UVC 摄像头或采集设备在 USB 带宽受限时输出压缩流。
工程上判断是否适合使用 H.265，要同时看：
- 目标设备是否支持对应 profile、level、bit depth 和 chroma format 的硬解。
- 播放器是否真的走了硬件解码路径，而不是静默回退到软解码。
- 分辨率、帧率、码率、GOP 结构和 B 帧数量是否符合实时性要求。
- 是否需要浏览器、老设备或低功耗设备兼容。
边界与常见坑
- H.265 不是容器格式：
.mp4、.mkv、.mov是容器；H.265 是里面视频轨使用的编码格式。 - 编码复杂度和解码复杂度不是一回事：H.265 编码端搜索非常重；解码端不做搜索，但仍比 H.264 通常更复杂。
- 硬解支持要看具体 profile：设备支持 H.265 Main 8-bit，不等于支持 Main 10、HDR 或 4:2:2。
- CPU 低不等于没有成本：硬解会降低 CPU 占用，但可能增加专用解码单元、显存带宽、拷贝和显示管线压力。
- 码率低不等于低延迟：B 帧、长 GOP、播放器缓冲和硬件队列都可能增加端到端延迟。