4、硬件加速转码：NVIDIA NVENC、Intel QSV、AMD AMF的配置与对比
说到硬件加速转码，我得先坦白一件事。早些年我总觉得这是「歪门邪道」，觉得软编码才是王道。直到有一次，客户要求一天内转完200小时的监控录像，我那台满配的服务器跑x264慢得像蜗牛。从那以后，我再也不敢小看硬件加速了。
说白了，硬件加速就是把编码解码的活儿，从CPU扔给GPU或专用媒体芯片去干。效果立竿见影——速度能快5到10倍，功耗还低一大截。当然，代价就是画质和码率控制上会有些妥协。但很多场景下，这点妥协完全值得。
4.1 三大主流方案概览
目前市面上主流的硬件加速方案就三家：NVIDIA的NVENC、Intel的QSV、AMD的AMF。我这些年都摸过一遍，各有各的脾气。
| 方案 | 厂商 | 硬件载体 | FFmpeg编码器名称 | 核心优势 |
|---|---|---|---|---|
| NVENC | NVIDIA | 独立显卡（GTX/RTX系列） | h264_nvenc / hevc_nvenc |
生态成熟，画质相对最好 |
| QSV | Intel | CPU集成显卡（核显） | h264_qsv / hevc_qsv |
延迟极低，无需额外购卡 |
| AMF | AMD | 独立显卡 / APU | h264_amf / hevc_amf |
开源驱动支持好，性价比高 |
ffmpeg -encoders | grep nvenc 或 ffmpeg -encoders | grep qsv。看一眼输出，心里就有底了。
4.2 NVIDIA NVENC：最成熟的方案
NVENC是我用得最多的方案。NVIDIA从Kepler架构就开始做这事，到现在已经非常成熟了。你想想看，连直播平台都在用NVENC推流，说明它的实时性和画质已经得到了市场验证。
基本用法很简单：
ffmpeg -i input.mp4 -c:v h264_nvenc -preset p4 -b:v 5M output.mp4这里有几个关键参数我得提一下：
- -preset：从p1到p7，p1最快但画质最差，p7最慢但画质最好。我个人习惯用p4或p5，平衡性最好。
- -b:v：目标码率。硬件编码对码率控制比较粗，建议给足带宽。
- -rc：码率控制模式。vbr（可变码率）画质更好，cbr（恒定码率）适合直播。
避坑指南： 我曾经在RTX 3060上跑4K HDR转码，结果画面颜色完全不对。后来发现NVENC默认不支持10bit色深，得手动加 -pix_fmt p010le 才行。嗯，这个坑我替你们踩过了。
如果你需要同时处理多路流，NVENC的优势就出来了。一张RTX 4090可以同时跑8路1080p实时转码，CPU几乎不占什么负载。
4.3 Intel QSV：低延迟之王
QSV是Intel的看家本领。它集成在CPU的核显里，所以不需要额外买显卡。对于服务器场景，这其实是个巨大优势——省电、省空间、省成本。
QSV的延迟能做到非常低，我实测过，从输入到输出延迟不到10毫秒。这在视频会议、远程桌面这类场景里简直是神器。
ffmpeg -i input.mp4 -c:v h264_qsv -preset veryfast -b:v 5M output.mp4QSV的参数体系跟NVENC不太一样：
- -preset：有veryfast、faster、fast、medium、slow、slower、veryslow。越慢画质越好。
- -global_quality：相当于CRF值，范围1到51，数值越小画质越好。我一般设18到23之间。
- -look_ahead：开启后能提升画质，但会增加延迟。
vainfo 确认驱动是否正常加载。
4.4 AMD AMF：开源生态的惊喜
AMF是AMD的硬件加速方案。说实话，前几年AMF的表现确实不如NVENC，但最近两代RDNA架构的显卡进步很大。尤其是Linux上的开源驱动（amdgpu + rocmsdk），让AMF在服务器场景里有了用武之地。
ffmpeg -i input.mp4 -c:v h264_amf -usage transcoding -quality quality -b:v 5M output.mp4AMF的参数有点特别：
- -usage：指定使用场景。transcoding（转码）、ultralowlatency（超低延迟）、webcam（摄像头）等。
- -quality：画质预设。有speed、balanced、quality三档。
- -rc：码率控制。CBR、VBR、CVBR（受约束的可变码率）都支持。
4.5 三大方案横向对比
光说参数没意思，我直接给你们一张对比表，一目了然：
| 对比维度 | NVENC | QSV | AMF |
|---|---|---|---|
| 编码速度（1080p） | ★★★★☆ | ★★★★★ | ★★★★☆ |
| 编码画质（同等码率） | ★★★★★ | ★★★★☆ | ★★★★☆ |
| 延迟 | ★★★☆☆ | ★★★★★ | ★★★★☆ |
| 多路并发能力 | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 驱动/生态成熟度 | ★★★★★ | ★★★★☆ | ★★★☆☆ |
| 功耗 | ★★★☆☆ | ★★★★★ | ★★★★☆ |
| 硬件成本 | 高（需独显） | 低（集成在CPU） | 中（需独显/APU） |
看到这个表，你可能会问：「那我到底该选哪个？」我的建议很简单：
- 如果你已经有NVIDIA显卡，直接用NVENC，省心省力。
- 如果你在搭建低成本服务器，或者做低延迟应用，QSV是首选。
- 如果你用AMD平台，或者需要开源驱动支持，AMF值得一试。
4.6 实战：多路并发转码脚本
最后，我分享一个我实际项目中用过的脚本。当时需要把一批4K素材转成1080p，同时输出H.264和H.265两个版本。用硬件加速，一台机器就搞定了。
#!/bin/bash
INPUT_DIR="./input"
OUTPUT_DIR="./output"
mkdir -p "$OUTPUT_DIR"
for file in "$INPUT_DIR"/*.mp4; do
filename=$(basename "$file" .mp4)
# H.264版本（NVENC）
ffmpeg -i "$file" \
-c:v h264_nvenc -preset p4 -b:v 8M \
-c:a aac -b:a 128k \
"$OUTPUT_DIR/${filename}_h264.mp4" &
# H.265版本（NVENC）
ffmpeg -i "$file" \
-c:v hevc_nvenc -preset p5 -b:v 6M \
-c:a aac -b:a 128k \
"$OUTPUT_DIR/${filename}_hevc.mp4" &
# 控制并发数，避免显存溢出
if [[ $(jobs -r | wc -l) -ge 4 ]]; then
wait -n
fi
done
wait
echo "全部转码完成"好了，硬件加速这块儿基本就这些。说白了，选哪个方案取决于你的硬件和场景。没有绝对的「最好」，只有「最合适」。你动手试试，很快就能找到感觉。