FFmpeg QSV硬编解码实战：从环境验证到多路并发调优

手上那台老 i5 台式机一跑 ffmpeg 转码，风扇就跟要起飞似的，CPU 直接顶到 100% 然后掉帧，这大概是我第一次严肃研究 QSV 硬编解码的契机。QSV 就是 Intel Quick Sync Video 的缩写，是集成在 Intel 核显里的一套固定功能硬件单元，专门干视频解码、编码和图像处理这三件事。它跟 CPU 软编最大的区别在于：活是交给显卡里的专用电路干的，CPU 只管搬数据、写文件，理论上能把整机功耗和耗时压掉一个数量级。如果你手里有一台带 Intel 核显的机器，不管是家用迷你主机、办公笔记本，还是一台塞在机柜里做转码的服务器，只要那台机器上跑着 ffmpeg，这套东西就大概率是能榨出来的免费算力。我接下来要讲的东西，面向的是那些已经会用 ffmpeg 敲几条基础命令、但被 QSV 各种参数和诡异报错折腾过的同学，也面向完全没碰过硬编、想一步到位上手的初学者。整篇按我自己的踩坑顺序来写：先讲清楚为什么选它，再讲环境怎么验，然后是命令怎么迁移、画质怎么调、多路怎么并发，最后是我攒下来的一份报错速查表。

1. 为什么我最后把 ffmpeg 编码链路切到了 QSV

1.1 先算一笔账：软编到底慢在哪

很多人对软编慢这件事只有个模糊感受，其实账很好算。以 x264 的 medium preset 编 1080p30 为例，一颗四核八线程的老 CPU 大概能跑到 1.2x 到 1.8x 的实时速度，也就是说一个 10 分钟的片子要编 6 到 8 分钟；换成 veryslow，实时速度掉到 0.4x，一部两小时的电影要编五个小时。更难受的是功耗和散热，整机 CPU 满载的时候，功耗墙一到就降频，速度还会进一步下滑，笔记本上更是直接风扇噪音拉满。

软编的本质是拿通用计算单元去做大量重复的、模式高度固定的数学运算。DCT 变换、运动估计、熵编码这些东西，算法结构稳定，非常适合做成专用电路。QSV 的思路就是把这一整条流水线做成硬件模块，你只要把帧喂进去、把参数配好，它自己就把码流吐出来。CPU 在这套流程里的角色从“干活的”变成了“调度员”，占用率通常能压到单核的 30% 以内，多路并发的时候你才会看到它慢慢涨上去。

我实际测过一个很典型的场景：同一台带 UHD 630 核显的机器，同一段 1080p H.264 素材转成 HEVC。纯软编用 libx265 medium，速度是 0.6x，CPU 全核满载；切到 hevc_qsv medium，速度是 4.2x 左右，CPU 占用不到 20%。差了七倍。这个差距不是优化能追回来的，是架构决定的。

1.2 QSV、NVENC、VAAPI、AMF 四种硬编我各踩过什么坑

市面上主流的硬件编码方案就那么几个，我在不同机器上全都折腾过一遍，说说各自的脾气，方便你判断自己该往哪条路上走。

QSV 让我最终留下来的核心原因是参数控制粒度。它把码率控制模式细分成 ICQ、CQP、VBR、CBR、AVBR、LA_ICQ 这好几种，每一种都能对应到具体的业务场景；而 VAAPI 在很长一段时间里连一个像样的恒定质量模式都给不出来，只能靠固定 QP 硬撑，遇到运动剧烈的镜头就糊成一片。

另一个现实因素是解码。QSV 的解码能力比编码能力更值得用，尤其是你要做多路转码的时候，八路 1080p 的 H.264 硬解几乎不占 CPU，光这一条就能把整机的并发能力翻好几倍。NVENC 解码同样强，但普通消费级 N 卡在并发编码会话上有硬性限制，做批量转码会很难受。

1.3 不是所有 Intel 核显都能吃到 QSV：按代际筛选硬件

这是最容易踩的第一个坑：QSV 不是有核显就有的，代际差别很大。Sandy Bridge 是 QSV 的第一代，但那会儿只能编码 H.264，画质和速度都只是“能用”的水平；Haswell 之后开始支持 HEVC 的解码辅助；Skylake 之后 H.264 编码质量才算成熟；Kaby Lake 是第一个完整支持 HEVC 8bit/10bit 编解码的消费级平台；Ice Lake 之后加了 HEVC 的屏幕内容编码和 VP9 编码；Tiger Lake 到 Alder Lake 这一段，H.264 和 HEVC 的编码质量已经能做到和 x264 medium 肉眼难区分了。

所以判断标准很简单：如果你只是想转 H.264，Haswell 之后的机器都能上；如果你要转 HEVC，最好确保是 Kaby Lake 或更新的平台；如果你还想玩 AV1 编码，那得是 Arc 独显或者 Meteor Lake 之后的核显。我见过有人在 Skylake 上折腾 hevc_qsv，命令跑得通但输出画质惨不忍睹，最后发现是那代硬件根本就没给 HEVC 编码单元。

还有一个容易被忽略的点：同一代里也分档。U 系列低压版的核显在执行单元数量上比 H 系列少不少，编码速度会差一截，但支持的编码格式是一样的。所以如果只是做 1080p 的轻量转码，一台低压笔记本也够用；要跑 4K，就得看执行单元和显存带宽了。

提示：查自己机器核显型号最快的办法，Linux 上用lspci -nn | grep -i vga，Windows 上直接看设备管理器里的显示适配器。拿到型号再去查 Intel 官方文档里对应的编解码能力表，比瞎试命令靠谱得多。

2. 环境准备：驱动、设备节点与 ffmpeg 编译选项

2.1 Linux 下先把 /dev/dri 和 vainfo 跑通

QSV 在 Linux 上跑不起来，九成的原因是驱动或设备节点的问题，跟 ffmpeg 本身没关系。所以第一步永远不是敲转码命令，而是确认硬件层通没通。

先看设备节点。现代内核会把 Intel 显卡暴露成两种节点：card0 是显示输出节点，renderD128 是渲染节点。硬件编解码走的是渲染节点，所以你要确认 /dev/dri/renderD128 存在：

ls -l /dev/dri/ # 典型输出 # crw-rw---- 1 root video 226, 0 Jan 1 00:00 card0 # crw-rw---- 1 root render 226, 128 Jan 1 00:00 renderD128

如果这个目录压根不存在，说明内核里没加载 i915 驱动，或者你是在容器/子系统里跑，那 QSV 基本可以放弃了。如果节点存在但普通用户没权限，把用户加进 render 组再重新登录：

sudo usermod -aG render $USER # 重新登录后确认 id | grep render

权限这关过了之后装驱动。现在主流的做法是装intel-media-driver（也就是俗称的 iHD 驱动），它对应 Broadwell 及更新的平台。如果是特别老的机器，才需要intel-vaapi-driver（i965）。装完之后用 vainfo 验证：

sudo apt install intel-media-va-driver-non-free vainfo vainfo --display drm --device /dev/dri/renderD128

输出的关键在 Entrypoint 那一栏。你要能看到VAEntrypointEncSlice（这是编码能力）和VAEntrypointVLD（这是解码能力）。如果只看到 VLD 没有 EncSlice，说明驱动加载了但编码能力没起来，多半是驱动版本太老，或者你的平台本身不支持该格式的编码。这时候别急着调 ffmpeg 参数，先去升级驱动。

2.2 确认手里的 ffmpeg 到底带不带 qsv

第二类高频问题是：系统里的 ffmpeg 是发行版仓库装的老版本，编译时压根没开 QSV 支持。验证方法很简单：

ffmpeg -hide_banner -hwaccels # 如果支持，输出的列表里会有 qsv 这一项 ffmpeg -hide_banner -encoders | grep qsv # 正常应该能看到 h264_qsv、hevc_qsv、mpeg2_qsv、vp9_qsv 等

如果-hwaccels里没有 qsv，别折腾了，换一个带支持的构建版本。要注意 ffmpeg 4.x 时代用的是libmfx这个库，从 ffmpeg 6.0 开始逐步切换到libvpl（也就是 oneVPL）。这两个东西不通用，编译选项分别是--enable-libmfx和--enable-libvpl。你如果从源码自己编，得先确认系统里装的是哪一个：

# 检查 oneVPL pkg-config --modversion vpl # 检查旧版 Media SDK pkg-config --modversion libmfx

自己编译的话，一个我常用的最小配置是这样：

./configure \ --prefix=/usr/local \ --enable-libvpl \ --enable-gpl \ --enable-libx264 \ --enable-libx265 \ --enable-nonfree

这里保留 libx264 和 libx265 是为了留一条退路，万一某段素材在硬编下画质不达标，还能切回软编做对照测试。这个习惯我强烈建议你养成，做画质调优的时候没有软编做基准，你根本判断不了硬编到底损失了多少。

2.3 Windows 与国产系统上的差异处理

Windows 上省事很多，装完 Intel 官方显卡驱动，再从可信渠道拿一个 essentials 或 full 构建的 ffmpeg 压缩包，解压后把 bin 目录加进 PATH 就能用。Windows 上的 QSV 走的是 D3D11 后端，所以你不需要关心 /dev/dri 这些东西，直接ffmpeg -hwaccels看有没有 qsv 就行。唯一的坑是驱动版本：某些 OEM 厂商会锁驱动版本，导致新平台的编码能力被封印，遇到这种情况去 Intel 官网下通用驱动覆盖安装。

国产化平台上的情况稍微绕一点。这类系统一般基于较新的内核，i915 驱动是有的，问题主要出在用户态的驱动包和 ffmpeg 构建版本上。我的处理顺序是：先用 vainfo 确认硬件能力，再确认系统的 ffmpeg 是不是带 libvpl 的构建，如果不是，自己编一个静态版本丢到 /opt 下面，通过环境变量指定 PATH，不要动系统的包管理器，避免破坏依赖。

另外要提醒一句，WSL2 或者任何虚拟化环境里是没有 /dev/dri 的，这条路走不通，别在这上面耗时间。要在虚拟化里用 QSV，得做显卡直通，那是另一个话题了。

3. 命令拆解：从软编命令迁到 QSV 硬编

3.1 解码端：全 GPU 零拷贝管线怎么搭

迁移的第一步是解码。很多人第一次用 QSV，只把编码器换成了 h264_qsv，解码还是软解，结果发现速度只提升了 30%，然后就得出“QSV 也就那样”的结论。这是典型的没用对。

默认情况下，ffmpeg 解码出来的帧在系统内存里，交给编码器之前要先做一次格式转换（比如 yuv420p 转 nv12），再上传到显卡。这一步在数据量大的时候开销非常可观。正确姿势是让解码出来的帧直接留在显存里：

ffmpeg -hwaccel qsv -hwaccel_output_format qsv \ -c:v h264_qsv -i input.mp4 ...

这两行参数的含义要拆开看。-hwaccel qsv是告诉 ffmpeg 用 QSV 做硬件解码；-hwaccel_output_format qsv是关键，它让解码后的帧保持 QSV 的硬件帧格式，不做下载回内存的操作。只有加上后面这一条，滤镜链里的 scale_qsv、vpp_qsv 这些硬件滤镜才能直接吃这些帧，整条管线才是真正的零拷贝。

如果你省略了-hwaccel_output_format qsv，ffmpeg 会在硬件解码后把帧下载到系统内存，转成普通的 nv12，然后再交给硬件编码器上传回去。这一下一上，显存和内存之间来回搬几十 GB 的数据，性能优势直接砍半。我最早就是这么写的，测出来的数据一直不理想，后来才发现问题出在这儿。

还有一个参数值得单独说：-async_depth。这是解码的并行深度，默认值是 4。它的作用是让解码器一次提交多帧，充分利用硬件的流水线。如果你做的是单路低延迟直播，这个值要调小甚至设成 1，否则会引入额外的缓冲延迟；如果是离线批量转码，可以调到 8 甚至更高，吞吐会明显提升。

3.2 编码端：h264_qsv / hevc_qsv 参数逐条讲

编码端的参数是整套流程里最容易配错的部分，因为 QSV 的参数命名和 libx264 完全是两套体系。我把最常调的几条列出来，逐条解释。

preset：ffmpeg 的 QSV 编码器把 preset 映射成了硬件里的 Target Usage，一共七档。映射关系大致是 veryfast 和 faster、fast 都对应 TU7（最快），medium 对应 TU4（默认），slow 和 slower 对应 TU2，veryslow 对应 TU1（最慢最好）。注意这里有个反直觉的点：TU7 和 TU1 之间的画质差距，在同等码率下其实比 x264 的 veryfast 到 veryslow 要小，因为硬件编码器本身的搜索算法就那几种，preset 主要影响的是运动估计的精细度。我大多数时候用 medium，需要压速度的时候用 fast，画质优先用 slow。

global_quality：这是恒定质量模式的入口，取值范围 1 到 51，数值越小画质越好、码率越高。它大致对标 x264 的 CRF，但两者的刻度不一样，不能直接套用。这个参数后面会单独用一节讲对照实验。

look_ahead 和 look_ahead_depth：开启前向预测，编码器会先“看”若干帧再决定当前帧怎么分码率，对运动场景和场景切换的码率分配帮助很大。-look_ahead 1打开开关，-look_ahead_depth 40控制往前看多少帧。代价是延迟和显存占用上去了，所以直播别开，离线转码建议开。

bf（B 帧数量）：QSV 支持 B 帧，设成 3 到 4 通常能在同等画质下再省 5% 到 10% 的码率。注意有些老平台在特定编码格式下 B 帧支持不完整，如果开了之后报错，直接设成 0。

low_power：这条是 QSV 里最需要小心对待的参数。-low_power 1会走低功耗编码路径（VDENC），功耗和资源占用更低，但代价是它和 look_ahead、extbrc 这些高级码率控制不兼容，某些平台上支持的编码格式也有限。我在做多路并发、每路画质要求不高的时候会开它，做单路高质量转码的时候一定关掉。

g 和 idr_interval：-g控制 GOP 长度，-idr_interval控制 IDR 帧间隔。做流媒体切片的时候这两个值要和切片长度对齐，比如做 4 秒切片，30fps 下-g 120。

profile：转 HEVC 10bit 素材的时候必须显式写-profile:v main10，否则编码器会默认按 8bit 处理，颜色会出现带状断层。这时候像素格式也要对应改成 p010。

3.3 三条可直接抄的完整命令

讲完参数，给你三条我实际在用的命令，按场景分。

第一条，离线批量转码，追求画质，H.264 转 HEVC：

ffmpeg -hide_banner -y \ -hwaccel qsv -hwaccel_output_format qsv -async_depth 8 \ -c:v h264_qsv -i input.mp4 \ -vf "vpp_qsv=format=nv12" \ -c:v hevc_qsv -preset slow -global_quality 26 \ -look_ahead 1 -look_ahead_depth 40 -bf 4 \ -c:a copy -movflags +faststart \ output.mp4

这条命令里的vpp_qsv=format=nv12是显式把硬件帧统一成 nv12 格式，防止源文件是别的像素格式时编码器报错。音频直接 copy 不重编，这是我个人强烈推荐的做法——音频重编几乎不省空间，但会引入质量损失和处理时间。

第二条，多路并发直播转码，追求低延迟和资源占用：

ffmpeg -hide_banner -y \ -hwaccel qsv -hwaccel_output_format qsv -async_depth 2 \ -c:v h264_qsv -i input.mp4 \ -vf "scale_qsv=1280:720" \ -c:v h264_qsv -preset fast -low_power 1 \ -b:v 2500k -maxrate 3000k -bufsize 5000k \ -g 60 -bf 0 \ -c:a aac -b:a 128k \ -f flv rtmp://your-endpoint/stream

注意这里用了 low_power，所以没开 look_ahead，码率控制换成了标准 VBR。缓冲区的设置遵循一个经验公式：bufsize 取 maxrate 的 1.5 到 2 倍，这样码率波动不会太剧烈，又能保证画面质量。

第三条，批量缩放+去隔行，纯 GPU 管线：

ffmpeg -hide_banner -y \ -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw \ -hwaccel qsv -hwaccel_output_format qsv \ -c:v mpeg2_qsv -i interlaced_input.ts \ -vf "vpp_qsv=deinterlace=advanced,scale_qsv=1920:1080:mode=hq" \ -c:v h264_qsv -preset medium -global_quality 24 \ -c:a copy output.mp4

第三条第 2 行是我特意加的：-init_hw_device显式指定设备节点，-filter_hw_device告诉滤镜链用哪个设备。单卡机器上不写也行，但只要你机器上插了两块卡，或者有核显加独显的组合，不显式指定的话 ffmpeg 可能会挑错设备，报一个莫名其妙的初始化失败。

4. 码率控制与画质调优的实测过程

4.1 ICQ、CQP、VBR、CBR 四种模式该怎么选

QSV 提供了好几套码率控制逻辑，用错了模式，后面怎么调参数都是白费劲。把这四种搞清楚，你就掌握了 QSV 调优的一半。

CQP是固定 QP 模式，通过-qscale指定一个固定值，每一帧都用同样的量化参数。它的优点是行为可预测，缺点是遇到复杂画面码率会飙，遇到简单画面码率又浪费。除了做对照实验，我基本不用它。

ICQ是智能恒定质量模式，通过-global_quality指定目标质量，编码器根据画面复杂度自动分配码率。这是我最常用的模式，对标 x264 的 CRF，适合绝大多数离线转码场景。

VBR是可变码率，通过-b:v指定平均码率，配合-maxrate和-bufsize限制波动范围。适合有码率上限要求的场景，比如平台规定视频不能超过某个码率。开-look_ahead 1之后它会变成 LA_VBR，码率分配更合理。

CBR是恒定码率，-b:v、-maxrate、-minrate设成同一个值。这是给传输链路用的，比如某些硬件推流设备对码率稳定性有硬要求。除了这种情况，别用 CBR，同样的体积它画质最差。

选择逻辑其实很简单：离线转码优先 ICQ，有码率约束的用 VBR，推流用 CBR 或者低延迟 VBR，做实验用 CQP。

4.2 global_quality 与 x264 CRF 的对照实验

这是我自己做过最多次的一组实验，因为你从软编迁过来的时候，心里总得有个换算表。我用同一段包含快速运动和暗场细节的 1080p 素材，用 hevc_qsv 和 libx265 分别跑了一轮，控制变量，只改质量参数，然后用 VMAF 打分。

结论有这么几条。第一，QSV 想达到 x265 同等画质，global_quality 大概要比 CRF 低 2 到 3 档，同时文件会大 10% 上下。第二，这个差距在低质量区间会拉大，高质量区间反而缩小。第三，也是最关键的：在 global_quality 22 到 26 这个区间，1080p 素材在正常观看距离下，我基本分不出来。只有在逐帧对比、放大到 200% 看暗部噪点的时候才能看出差别。

所以我的做法是：绝大多数内容用 global_quality 26，重要的、需要长期保存的素材用 22，对体积敏感的批量内容用 28 到 30。这个取值不是拍脑袋来的，是我反复对比之后形成的习惯值，你的素材类型可能不同，建议自己也跑一轮对照，成本很低，收益很大。

4.3 滤镜也要留在 GPU 上：vpp_qsv 与 scale_qsv

这一节是很多人的盲区。你前面把解码和编码都放到 GPU 上了，结果滤镜链里写了一个-vf scale=1280:720，ffmpeg 就会老老实实把帧从显存下载到内存，做完缩放再上传回去。这一下一上，前面的优化全部作废。

正确的写法是用硬件滤镜。QSV 提供了scale_qsv和vpp_qsv两个，后者是前者的超集，支持缩放、去隔行、降噪、裁剪、色调映射等一堆操作。

# 纯硬件缩放 -vf "scale_qsv=1280:720:mode=hq" # 去隔行 + 缩放 + 格式转换，一条链走完 -vf "vpp_qsv=deinterlace=advanced:denoise=10,scale_qsv=1920:1080" # HDR 转 SDR 的色调映射 -vf "vpp_qsv=tonemap=1:format=nv12"

scale_qsv的 mode 参数有 low_power、hq 和 auto 三档。low_power 用的是固定功能单元，速度最快但画质一般；hq 走的是更精细的算法，速度慢一些但边缘处理明显更好。我一般缩放比例超过 2 倍的时候用 hq，其他情况用 auto 让它自己判断。

这里有个细节要注意：硬件滤镜对像素格式有要求，输入必须是 nv12 或者 p010。如果你的源是 yuv420p 这种软格式，前面得先hwupload上传，或者干脆让解码器输出硬件帧。这也是为什么我在前面的命令里一直强调-hwaccel_output_format qsv。

5. 多路并发与生产化落地

5.1 并发会话上限与多设备调度

单路跑通了，接下来一定是多路。QSV 的并发能力受两个因素限制：硬件编码单元的数量和显存带宽。经验值是，消费级核显上同时跑 3 到 4 路 1080p 的 H.264 编码基本到顶了，再往上会出现单路速度急剧下降，甚至初始化失败。HEVC 因为计算量大，能跑的路数还要再少一些。

这里有个坑要提前说：QSV 报错的时候不一定给你明确的“资源不足”提示，有时候直接是Error initializing an internal MFX session或者device failed (-17)。遇到这种，先怀疑是不是并发数超了，用intel_gpu_top看一下显卡的 Video 引擎占用率，如果一直贴着 100%，那就是饱和了。

如果一定要提高并发，有这么几条路。一是把 low_power 打开，它走的低功耗路径对硬件资源的占用明显更低，代价是画质略有下降。二是降低分辨率和帧率，720p 的比例差不多是 1080p 的一半开销。三是如果你的机器上有多个 Intel 显卡设备（比如核显加一块 Arc 独显），可以用-init_hw_device分别初始化，然后在每个 ffmpeg 进程里指定不同的设备：

# 进程 A 用核显 ffmpeg -init_hw_device qsv=hw0:/dev/dri/renderD128 -filter_hw_device hw0 ... # 进程 B 用独显 ffmpeg -init_hw_device qsv=hw1:/dev/dri/renderD129 -filter_hw_device hw1 ...

这种做法在服务器上很实用，尤其是有多块 Arc 显卡的转码机。要注意的是不同设备之间的负载需要你自己在外层调度，ffmpeg 不会帮你做。

5.2 Python 调用 ffmpeg 的工程化写法

做批量任务的时候，用 shell 脚本拼命令是能跑，但错误处理和进度采集会很痛苦。我现在的做法是用 Python 的 subprocess 直接传参数列表，绝对不用shell=True，因为拼字符串处理文件路径里的空格和特殊字符太容易出问题了。

import subprocess import json def transcode(src, dst, quality=26, device="/dev/dri/renderD128"): cmd = [ "ffmpeg", "-hide_banner", "-y", "-init_hw_device", f"qsv=hw:{device}", "-filter_hw_device", "hw", "-hwaccel", "qsv", "-hwaccel_output_format", "qsv", "-async_depth", "8", "-c:v", "h264_qsv", "-i", src, "-c:v", "hevc_qsv", "-preset", "medium", "-global_quality", str(quality), "-look_ahead", "1", "-look_ahead_depth", "40", "-c:a", "copy", "-movflags", "+faststart", "-progress", "pipe:1", "-nostats", dst, ] proc = subprocess.Popen( cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, ) for line in proc.stdout: line = line.strip() if line.startswith("out_time_ms="): ms = int(line.split("=")[1]) # 这里可以写自己的进度上报逻辑 proc.wait() if proc.returncode != 0: err = proc.stderr.read() raise RuntimeError(f"转码失败，返回码 {proc.returncode}: {err[-800:]}")

关键点有三个。第一，-progress pipe:1加上-nostats，让 ffmpeg 把结构化的进度信息输出到标准输出，你直接按行解析就行，不用去正则匹配那个人类可读的进度条。第二，错误信息在 stderr 里，失败时截取最后一段打印出来，太长的日志反而看不出问题。第三，-y放在前面，避免交互式确认卡住进程。

5.3 任务队列、崩溃恢复与监控指标

跑批的时候最怕的是任务跑一半挂了，或者跑完了你才发现有一半文件是损坏的。我现在的流程里有三道保险。

第一道是任务恢复。不要把待处理文件列表存在内存里，写到磁盘上的一个 sqlite 或者简单的状态文件里，每个文件处理完就更新状态。程序被 kill 或者机器重启之后，从头扫一遍状态，跳过已完成的。这个做起来很土但极其有效，我在一次跑了八小时的任务中途断电之后，靠这个机制省了三分之二的时间。

第二道是输出校验。转码完成后不要只看返回码，用 ffprobe 检查输出文件的时长、码流数量和最后一帧是否可解码。QSV 在显存不足的时候有时候会生成一个时长不对的残废文件，返回码却是 0。

ffprobe -v error -show_entries format=duration \ -of json output.mp4

第三道是资源监控。转码过程中定期采一下/sys/class/drm/renderD128/下面的频率和占用信息，或者直接跑intel_gpu_top -J拿 JSON 输出。我的经验是，当 Video 引擎占用持续高于 95% 的时候，单路转码速度会掉 20% 以上，这时候要么降并发，要么降质量参数，硬撑着只会让整体效率更低。

6. 常见问题排查实录

6.1 报错码速查表

我把这几年见过的报错整理成一张表，按出现频率排序。这些报错信息很多都很含糊，但结合上下文基本能定位。

特别说两条。一是Device failed (-17)，这个错误我遇到过好几次，最后发现是上一次的 ffmpeg 进程崩溃后没释放 QSV 会话，导致新进程申请不到资源。解决办法是用ps aux | grep ffmpeg看看有没有残留进程，杀掉再重试。二是Invalid input parameters，这个八成是像素格式的问题，尤其是处理手机拍的视频时，源文件可能是 yuvj420p（全范围）而不是标准的 yuv420p，加一个显式的格式转换就能解决。

6.2 画质发糊、色彩偏移、帧率不对这三类怪病

报错好解决，难解决的是那些不报错但结果不对的情况。我自己遇到过三类。

第一类是画质发糊。现象是码率上去了，但画面边缘发虚，快速运动的物体周围有明显拖影。查了一圈发现是 low_power 开着的同时又设了 global_quality，结果编码器走进了不受支持的参数组合，静默降级成了固定 QP。这类问题的排查方法是逐条注释参数做二分，先用最小参数集跑一条，确认正常之后一条条加回去。听起来笨，但比在网上搜快得多。

第二类是色彩偏移。输出比原片偏灰或者偏饱和，黑色不够黑。这通常是色彩空间标记丢失导致的。转码的时候加上-colorspace bt709 -color_primaries bt709 -color_trc bt709，把标准的 BT.709 标记显式写进去。如果源是 HDR，还得先做好色调映射再转，不然出来的画面会一片灰。

第三类是帧率不对。源是可变帧率（VFR）的时候，硬编出来的文件音画不同步，或者时长对不上。解决办法是转码时强制恒定帧率：-fps_mode cfr -r 30。这一条在处理手机录屏和直播录制的素材时特别有用。

6.3 长时间跑批才出现的隐性故障

跑几百个文件的任务时，最容易出现的是那种短任务测不出来、长任务一定撞上的问题。我印象最深的一次是跑了六个小时之后开始出现编码速度断崖式下跌，从 4x 掉到 0.8x，但没有任何报错。

后来定位到是显存泄漏。ffmpeg 在处理某些特定编码的源文件时，硬解出来的帧没有及时释放，累积几个小时之后显存压力变大，驱动开始频繁做内存的搬移，速度就崩了。处理办法有两个：一是控制单个进程处理的文件数量，比如每处理 50 个文件重启一次进程，用外层脚本管理；二是升级到较新的 ffmpeg 版本，我印象里 6.0 之后这类问题少了很多。

另一个隐性问题是温度。核显和 CPU 共享同一个散热模块，长时间满载之后 CPU 会先降频，进而拖慢整个流水线。这个只能从物理层面解决，改善机箱风道或者限制一下并发数。我的做法是在任务队列里加一个简单的温度检测，超过阈值就暂停几分钟，虽然总时长变长了，但整体稳定性好很多。

注意：跑批任务的时候千万别只看单文件的转码速度，那只能反映初始状态。真正的指标是持续跑两小时之后的平均速度，这个数字才是你评估机器能力时该用的。

还有一个小技巧值得分享：我习惯在批量任务的第一个文件上开详细的日志输出（-loglevel verbose），后面所有文件都只记警告。这样既能看到完整的初始化过程，又不会让日志文件涨到几 GB。出问题的时候，把第一个文件的日志拉出来看，八成能定位到是驱动、设备还是参数的问题。

最后分享一个我最近才发现的小用处。这套 QSV 管线搭好之后，其实不只是转码能用，做批量截图、生成缩略图、甚至给视频加水印，都可以套用同样的硬件加速思路——解码走 qsv，滤镜走 vpp_qsv，输出前的缩放走 scale_qsv，整条链路都在显卡上完成。我给一个素材库做封面缩略图的时候，用这套方法把处理时间从四十多分钟压到了三分钟。这个方向后续还可以继续挖，比如把 vpp_qsv 的降噪和锐化参数调细，做成一个视频预处理的通用模块，那样很多画质增强的需求就不用再单独交给软滤镜了。