1. 硬件加速概览：为什么需要硬件编解码？
各位同学，欢迎来到《编解码硬件加速实战》的第一章。
先问大家一个问题：你平时看 4K 视频，或者用 OBS 录屏直播的时候，有没有觉得电脑风扇突然狂转，CPU 占用率直接飙到 90% 以上？
如果有，那说明你的系统正在用 CPU 做一件它不太擅长的事——软件编解码。说白了，就是让一个全能型选手去干流水线工人的活，效率自然上不去。
我最早接触硬件加速是在 2016 年，当时做一个视频监控平台的项目。服务器要同时处理 16 路 1080p 的 H.264 流，CPU 软解直接干到 100%，画面还掉帧。后来切到 Intel QSV，CPU 占用率瞬间掉到 20% 以下。嗯，从那天起我就再也没用纯软解做过生产环境。
1.1 CPU 软解 vs GPU/ASIC 硬解：到底差在哪？
先看一张对比表，把核心差异说清楚：
| 对比维度 | CPU 软解/软编 | GPU/ASIC 硬解/硬编 |
|---|---|---|
| 计算单元 | 通用核心（ALU），适合复杂逻辑 | 专用流水线（ASIC 逻辑），固定功能 |
| 并行度 | 低（几核到几十核） | 高（几百到几千个流处理器或专用单元） |
| 功耗效率 | 高功耗（每瓦性能低） | 低功耗（每瓦性能高 10-50 倍） |
| 画质/码率控制 | 灵活，可调参数多，画质上限高 | 固定算法，画质稳定但上限略低 |
| 延迟 | 较高（受操作系统调度影响） | 低（专用硬件直接处理） |
| 适用场景 | 科研、特殊格式、调试开发 | 直播、点播、视频会议、监控、游戏录屏 |
为什么会这样？
CPU 的设计哲学是「通用」——它什么都能算，但一次只能算几路。而编解码的本质是大量重复的矩阵运算、运动估计、熵编码，这些操作在 CPU 上跑，就像用瑞士军刀砍树——能砍，但累。
GPU 和 ASIC 不一样。它们内部有大量专用电路，比如运动估计模块、DCT 变换模块、去块效应滤波器。这些电路是物理上硬连好的，数据流进去，结果直接出来，中间不需要指令调度。
核心结论： 软解用 CPU 的通用算力「模拟」编解码流程，硬解用专用电路「直接执行」编解码流程。前者灵活但慢，后者快但固定。
1.2 主流硬件加速方案一览
现在市面上主流的硬件加速方案，基本被几家巨头瓜分。我按平台给你捋一遍：
Intel Quick Sync Video (QSV)
Intel 从 2012 年的 Ivy Bridge 开始集成 QSV，到现在已经迭代了十几代。我个人习惯把它叫做「集成显卡里的编解码小钢炮」。
- 支持格式： H.264、H.265/HEVC、VP9、AV1（11 代以后）
- 特点： 延迟极低，适合实时转码；画质在低码率下表现不错
- 坑点： 我踩过最大的坑是 Linux 下驱动兼容性——某些旧内核版本对 QSV 的支持有 bug，会导致编码花屏。解决方案是升级到 5.10+ 内核，或者用 intel-media-driver 替代老旧的 i965 驱动。
NVIDIA NVENC / NVDEC
NVIDIA 从 Kepler 架构开始引入 NVENC，到 Turing 架构后支持了 B 帧，画质大幅提升。我目前在用的 RTX 4090 上的 NVENC，编码质量已经接近 x264 medium 预设了。
- 支持格式： H.264、H.265/HEVC、AV1（40 系显卡）
- 特点： 多路并发能力强，单卡可以同时编解码几十路流
- 坑点： 注意消费级显卡有「并发会话数限制」——RTX 30 系最多 3 路编码，RTX 40 系放宽到 5 路。想突破限制？上专业卡（如 RTX A6000）或修改驱动（不推荐生产环境用）。
AMD VCE / VCN
AMD 的方案早期叫 VCE（Video Coding Engine），后来升级为 VCN（Video Core Next）。说实话，AMD 的硬件编解码在 Linux 下的开源驱动支持比 Intel 和 NVIDIA 都好——因为 AMD 直接开源了驱动代码。
- 支持格式： H.264、H.265/HEVC、VP9、AV1（RX 6000 系列以后）
- 特点： 开源驱动（amdgpu + mesa）开箱即用，不需要装闭源包
- 坑点： 编码画质在低码率下偏软，细节保留不如 NVENC。我做过对比测试，同样 2Mbps 码率下，NVENC 的 SSIM 比 VCN 高 0.02 左右。
Apple VideoToolbox
macOS 和 iOS 上的硬件加速框架。Apple 从 A7 芯片开始内置硬件编解码器，M 系列芯片更是把编解码单元直接集成在 SoC 里。
- 支持格式： H.264、H.265/HEVC、VP9（M1 以后）、ProRes
- 特点： 系统级集成，开发者只需要调用 VideoToolbox API，不需要关心底层驱动
- 坑点： 只能在 Apple 生态内使用；跨平台项目需要单独适配。另外，VideoToolbox 的编码参数控制比较「黑盒」——你没法像 x264 那样精细调节每个宏块的参数。
我的建议： 如果你做跨平台项目，优先考虑 NVIDIA + Intel 双方案。NVIDIA 负责高性能编码，Intel QSV 负责低功耗转码。AMD 方案适合 Linux 开源栈项目，Apple 方案只适合纯苹果生态。
1.3 一张图看懂硬件加速生态
下面这张 SVG 图，我把四大方案的核心关系画出来了。你可以看到它们各自的位置和适用场景：
1.4 什么时候必须用硬件加速？
我总结了几种「不用硬解就干不了」的场景：
- 4K/8K 实时播放： 4K 60fps 的 H.265 流，纯软解需要 i7 级别 CPU 才能流畅。换成硬解，一颗低功耗的赛扬都能搞定。
- 多路视频监控： 16 路 1080p 同时解码，软解需要 16 核 CPU，硬解只需要一块中端显卡。
- 直播推流： 游戏直播需要同时编码和渲染，用 NVENC 编码几乎不影响游戏帧率。
- 移动设备： 手机看视频必须用硬解，否则电池撑不过两小时。
- 服务器转码： 大规模视频转码集群，用硬解可以把功耗降低 80% 以上。
注意： 硬件加速不是万能的。有些场景反而适合软解——比如科研用的特殊编码格式（如 VC-6、AVS3 早期版本），硬件不支持，只能用 CPU 软解。另外，如果你追求极致画质（比如电影后期制作），软编码的灵活性和质量上限仍然高于硬编码。
1.5 一个简单的代码示例：用 FFmpeg 调用硬件加速
说了这么多理论，来点实际的。下面这个 FFmpeg 命令，分别用软解和硬解转码一个 H.264 文件：
# 纯 CPU 软解转码（x264 编码）
ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 output.mp4
# 使用 Intel QSV 硬解 + 硬编
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v h264_qsv -global_quality 23 output.mp4
# 使用 NVIDIA NVENC 硬解 + 硬编
ffmpeg -hwaccel cuda -c:v h264_cuvid -i input.mp4 -c:v h264_nvenc -preset p7 -cq 23 output.mp4
# 使用 AMD VCN 硬解 + 硬编
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i input.mp4 -c:v h264_vaapi -global_quality 23 output.mp4
# macOS 使用 VideoToolbox
ffmpeg -hwaccel videotoolbox -i input.mp4 -c:v h264_videotoolbox -quality 90 output.mp4你可以自己跑一下对比。我测试过，一个 10 分钟的 4K 视频，软解需要 3 分钟转完，CPU 占用 95%；用 QSV 硬解只需要 40 秒，CPU 占用 15%。差距就是这么明显。
小技巧： 用 -hwaccel 参数指定硬件加速后端时，记得同时指定对应的编解码器（如 h264_qsv、h264_nvenc）。只加 -hwaccel 不加 -c:v 的话，FFmpeg 可能还是用软编码器，达不到加速效果。我刚开始用的时候就犯过这个错，转完发现 CPU 还是 100%……