八类故障的根因、一处跨构建差异，以及 VMAF 测量方法本身的偏差。 本页是全站调试成本最高的部分，每条都对应一次真实排查。
均出自"自动回退 / 自动探测"逻辑的边界情况，而非硬件能力不足。
| 症状 | 根因 | 处理 |
|---|---|---|
hevc / av1 均报 Invalid FrameType:0. |
启用 QSV 的 look-ahead（-look_ahead_depth 与 -extbrc 组合），本驱动在"硬件解码 + look-ahead"下崩溃 |
不再使用 look-ahead（ICQ 下本身无效） |
| 无报错但极慢，CPU 解码仅 0.x 倍速 | 崩溃后回退 CPU 解码重试，形成约 0 帧的挂起状态，表面仍在"编码"但无进度 | 增加 out_time 看门狗；区分编码器错误与解码器错误，前者不触发解码回退 |
音频报 Quality-based encoding not supported（exit −22） |
-global_quality 未限定作用域，参数落到音频编码器 |
改为 -global_quality:v |
视频 TargetUsage 变为 7，报 Invalid compression level |
-compression_level 10 属音频参数，被下发给视频编码器 |
改为 -compression_level:a |
偶发 Error creating a MFX session: -9 |
进程被强杀后 QSV 会话未释放 | 先 terminate 再 kill |
| 编码完成但进程不退出 | stdout EOF 哨兵只消费一次 | EOF 后显式调用 wait() |
| 误报"超上限" | 比较时一侧为 bit/s、一侧为 kbps | 统一单位 |
| 存在硬解却报"无硬件解码" | 能力探测取 videos[0]，可能命中音频轨或损坏文件 |
先分类候选文件，用第一个真实视频探测 |
ICQ（Intel 官方推荐的质量模式）能否启用取决于 ffmpeg 构建，与显卡驱动无关。
| ffmpeg 构建 | -global_quality:v 30 的结果 |
|---|---|
| 9.0.2 发布版 / 9.0 分支 | 正常 RateControlMethod: ICQ / ICQQuality=30 |
| 8.0 发布版、2025 年各 git 构建 | 正常 ICQ |
| 2026-10 的 master 构建 | 失效 参数未送达编码器，退回出厂默认 CQP（QP 20/26/33） |
-preset、-g、-bf、-b:v、-q:v 均正常送达，仅 -global_quality 失效处置：PATH 切换至 9.0 分支构建；脚本增加"自动定位支持 ICQ 的 ffmpeg"兜底。 AV1 的 ICQ 同样只在 9.0 分支可用，且其 CQP 标尺失真（q40 仍需 7 Mbps 以上）。
| 偏差来源 | 实测影响 |
|---|---|
| 单段抽帧与全片多窗口 | 同一文件同一 preset 可差 4~6 分（1080p Q32 批次：85.9 对 79.6） |
| NEG 模型与默认模型 | NEG 低约 2.1 分。跨编码器比较应使用 vmaf_v0.6.1neg（去除"增强增益"项） |
| 两端同时 seek | 帧对齐失败，分数可降至 30 余分 |
| 绝对值跨方法比较 | 不可比。绝对值仅在自身方法内有效 |
日常用法：VMAF NEG 与 XPSNR 交叉验证。XPSNR 采用感知加权，速度约为 VMAF 的 3 倍， 结论与 VMAF 一致。SSIM 偏旧，仅作旁证；SSIMULACRA2 为当前较优指标，但 ffmpeg 未内置。
指标最优不等于观感最优：低码率下 AV1 噪点更少、涂抹更强，观感更"干净"， 而 VMAF 更偏向 HEVC。实际观感与指标结论可能不一致，最终选择仍应以人眼判断。
benchmark_concurrency() 内的同名调用，
真正运行的 main() 分支未改，连续三版均未生效。
根因是启动阶段需启动 3 次 ffmpeg（-version 两次、-encoders 一次），
而 ffmpeg.exe 体积 165 MB，Windows 每次都要经过安全扫描。
解法：合并为单次调用、缓存结果、用编码器列表判定平台。