4、计算复杂度与硬件要求：编码器复杂度分析、解码器复杂度分析、硬件加速支持情况
选编码器，说白了就是在算力和画质之间找平衡。H.265 比 H.264 压缩率高 30%-50%，但代价是什么？计算量翻了好几倍。这一章我们就把账算清楚。
4.1 编码器复杂度：H.264 vs H.265
编码器的复杂度，主要卡在几个地方：运动估计、模式决策、变换量化。H.265 在这几个环节都做了「加法」。
核心差异点：
- 运动估计（ME）： H.264 支持 7 种块划分（16x16 到 4x4），H.265 支持 25 种（64x64 到 4x4）。搜索范围更大，候选更多，计算量直接翻 3-5 倍。
- 帧内预测： H.264 有 9 种角度模式，H.265 有 33 种。模式决策的 RD-cost 计算量暴增。
- 变换单元（TU）： H.265 引入了四叉树划分，从 32x32 到 4x4 递归决策。这棵树每多一层，编码时间就多一倍。
我做过一个实测对比：用 x264 和 x265 压同一段 1080p 视频，码率都是 2Mbps。x264 用 medium preset，单帧编码时间约 12ms；x265 用 same preset，单帧时间飙到 80ms。差了将近 7 倍。
我的经验： 如果你用 x265 的 placebo preset，编码速度会慢到让你怀疑人生。我曾在一次离线转码任务中用了 placebo，结果 10 分钟的视频跑了 3 个小时。后来我学乖了，生产环境只用 medium 或 fast，画质损失肉眼几乎看不出来。
4.2 解码器复杂度：没那么夸张
解码器比编码器简单得多。为什么？因为解码器不需要做「决策」，只需要按语法解析、反变换、运动补偿。H.265 解码器的复杂度大约是 H.264 的 1.5-2 倍，远没有编码器那么夸张。
| 环节 | H.264 解码 | H.265 解码 | 复杂度倍数 |
|---|---|---|---|
| 熵解码 | CABAC/CAVLC | CABAC（改进版） | 1.3x |
| 运动补偿 | 1/4 像素插值 | 1/4 像素插值 + DCT 滤波 | 1.5x |
| 帧内预测 | 9 种模式 | 33 种模式 | 2.0x |
| 环路滤波 | Deblocking | Deblocking + SAO | 1.8x |
嗯，这里要注意：SAO（样点自适应补偿）是 H.265 新增的环节，它虽然能提升画质，但解码时多了一道计算。不过好在 SAO 的算法相对简单，对整体解码性能影响不大。
避坑指南： 我曾经在低端 ARM 设备上测试 H.265 解码，发现 4K 60fps 的视频解码帧率只有 15fps。后来查了芯片手册，发现那颗芯片的 H.265 解码器只支持到 4K 30fps。所以选型时一定要看芯片的硬解规格表，别只看「支持 H.265」几个字。
4.3 硬件加速支持情况
现在的主流芯片，基本都集成了 H.264 和 H.265 的硬编解码单元。但支持的细节差异很大。
4.3.1 桌面端（Intel / AMD / NVIDIA）
- Intel Quick Sync Video（QSV）： 从 Skylake 开始支持 H.265 编码，Tiger Lake 开始支持 10-bit。我建议用 QSV 做实时推流，延迟低，画质够用。
- NVIDIA NVENC： Turing 架构之后支持 H.265 B 帧，画质提升明显。我实测过，NVENC 的 H.265 编码质量已经接近 x264 medium 水平。
- AMD VCE / VCN： 支持 H.264 和 H.265，但驱动稳定性不如 Intel 和 NVIDIA。我在项目中遇到过 AMD 硬编解码器在某些 Linux 内核版本下崩溃的问题。
4.3.2 移动端（Apple / Qualcomm / MediaTek）
- Apple A 系列芯片： 从 A8 开始支持 H.265 解码，A9 开始支持编码。Apple 的硬编解码器质量很高，延迟也低。
- Qualcomm Snapdragon： 从骁龙 820 开始支持 H.265 解码，835 开始支持编码。但要注意，不同代际的编码质量差异很大。
- MediaTek： 从 Helio P20 开始支持 H.265 解码，但编码质量一般。我建议只用于解码场景。
硬件加速选型建议：
- 实时通信（WebRTC）： 优先用 H.264 硬编，兼容性好，延迟低。H.265 硬编在部分浏览器上还不支持。
- 点播转码： 用 H.265 软编（x265 medium），配合 GPU 加速解码。硬编在低码率下画质不如软编。
- 直播推流： 用 H.264 硬编（NVENC/QSV），码率控制在 2-4Mbps 即可。H.265 硬编在低延迟场景下优势不明显。
4.4 复杂度与硬件选型决策树
下面这张图是我自己总结的选型逻辑，帮你快速判断该用哪种方案。
4.5 实际项目中的复杂度评估
我习惯用「编码时间比」来评估复杂度。公式很简单：
编码时间比 = 编码总时间 / 视频时长举个例子：一段 10 分钟的视频，用 x264 medium 编码花了 5 分钟，编码时间比就是 0.5。用 x265 medium 编码花了 35 分钟，编码时间比就是 3.5。这个比值能直观反映编码器的计算压力。
我的经验值：
- H.264 软编（x264 medium）：编码时间比 0.3-0.8
- H.265 软编（x265 medium）：编码时间比 2.0-5.0
- H.264 硬编（NVENC）：编码时间比 0.05-0.1
- H.265 硬编（NVENC）：编码时间比 0.1-0.2
如果你看到 H.265 硬编的时间比超过 0.5，说明你的 GPU 可能太老了，或者驱动有问题。
4.6 总结：选型时的复杂度考量
说白了，选 H.264 还是 H.265，取决于你的算力预算和场景需求。
- 算力充足（服务器集群）： 用 H.265 软编，追求最高压缩率。一台 32 核服务器可以同时跑 4-6 路 x265 medium 编码。
- 算力有限（嵌入式设备）： 用 H.264 硬编，或者 H.265 硬编（如果芯片支持）。别想着在树莓派上跑 x265，你会后悔的。
- 解码端： 只要芯片支持 H.265 硬解，就放心用 H.265。解码复杂度不是瓶颈。
最后提醒一句： 别只看编码速度，还要看功耗。我曾在某个项目中用 GPU 做 H.265 硬编，编码速度是快了，但整机功耗从 150W 飙到 350W。后来算了一笔账，电费比服务器租金还贵。所以，选型时把 TCO（总拥有成本）也算进去。