Arc 140T 核显硬编实测：QSV 的 GQ 数值为什么不能当 CRF 用、AV1 甜点位、ICQ 疯给码

同一台没有独显的机器，核显也能硬编视频，而且玩好了体积能比 CPU 软编小四分之一。这一篇把 Arc 140T 的 QSV 编码器从数值哲学到实战参数全测了一遍，重点回答三个问题：QSV 的 global_quality 和 x264 的 CRF 有什么不同、为什么丢帧后 ICQ 会疯给码、AV1 硬编的甜点位在哪。

环境：Core Ultra 5 235H / Arc 140T 核显 / ffmpeg 9.0.1（gyan essentials，含 QSV/AMF/NVENC）/ 1080p 监控素材，SSIM 以无损为基准。2026-09-11 实测。

先记牢：QSV 的 GQ 数值 ≠ x264 的 CRF 数值

这是最容易踩的坑。看着都是 '25'，实际画质天差地别：

设置	码率	SSIM	结论
libx264 crf25	~490kbps	0.990	CPU 软编基准
h264_qsv gq25	~161kbps	0.984	同数值码率只有 1/3！
h264_qsv gq20	~587kbps	0.990	画质才追平 crf25
av1_qsv gq25	13.4MB	0.985	gq 不跨编码器通用

同是 25：h264_qsv 码率只有 crf25 的 1/3，SSIM 也从 0.990 掉到 0.984。要让 QSV 追平 crf25 画质得用 gq20；而 AV1 的 gq25 和 H264 的 gq25 又不是一回事——gq 数值跨编码器完全不通用。

丢帧后的 'ICQ 疯给码' 问题

真正把我逼到墙角的是这个：mpdecimate 丢帧后再用 QSV 的 gq 参数编码，码率会暴涨。丢帧后剩下的全是'活动帧'，ICQ 质量模式看到高动态画面就疯狂堆码率：

丢帧版码控	耗时	成片	压缩率	码率
gq20(原选定)	32s	187.4MB	2.1x	7.7M ❌
gq30	89.3s	29.9MB	13x	1.12M
gq35	31.3s	12.7MB	31x	403K ✅
b:v800k	32.2s	22.1MB	18x	794K ✅
b:v500k	31.1s	15.2MB	26x	505K ✅

定案方向：丢帧版别用 ICQ（gq），改用定码率 -b:v（体积可预期）或 gq35。A 目录 gq20 丢帧后 187MB 比不丢帧还肥，是 ICQ 参数灾难的现场证据。

AV1 硬编：全面超越 H264 基线

最后的大招：av1_qsv preset 7 + global_quality 27 是这代核显的甜点位。五倍速场景下与基线对比：

指标	基线 H264 gq25	新方案 AV1 p7 gq27
SSIM 画质	0.9812	0.9825 ✓
体积（A目录5段）	12.7MB	9.7MB ✓
压缩率	1.6x	2.1x ✓
耗时	4s	3.4s ✓
音画同步	59.99/59.92s	同 ✓
可解码	✓	✓

体积小 24%、画质 SSIM 0.9825 反而略胜、耗时还更短——三个维度全面领先。白天有人目录复验：16.7MB→14.2MB，体积仍小 15%。注意 AV1 的 preset 很敏感，preset3 又慢体积还略大，preset7 + gq27 才是体积/画质/速度的平衡点。

硬解链路为什么不可靠

hwupload=extra_hw_frames=64 报 Could not create the texture (0x80070057)
-hwaccel qsv + mpdecimate 报 -22 Invalid argument——mpdecimate 是纯软件滤镜，不能直接吃 QSV 硬件帧
完整硬链（hwdownload→mpdecimate→hwupload→编码）初始化滤镜失败
d3d11va 能跑但更慢（13.9s vs 纯软解 3.9s）
可行组合：纯软解 + h264_qsv/av1_qsv 硬编（不带 hwaccel 喂硬编），实测最快且零错误

降帧率：画质的天花板

想靠降帧率省钱？实测 fps6~30 画质必降，SSIM 天花板 ~0.974 压不回来。压缩率应该靠编码器和剪静止（mpdecimate/剪静止方案见剪静止指南），而不是牺牲帧率。另外 hqdn3d 降噪虽能提压缩但 CPU 滤镜拖慢到 44s，不可用。

一句话参数卡

场景	编码	体积预期
体积最小 + 画质平衡	av1_qsv p7 gq27	比 H264 基线小 24%
全兼容	h264_qsv -b:v 700k	≈ 源码率不损质
丢帧版	h264_qsv -b:v 800k	体积可预期

重要：以上是 Arc 140T 特定的实测，核显驱动/ffmpeg 版本不同数值会漂移，但'GQ≠CRF、ICQ 在丢帧高动态下暴涨、AV1 preset 对甜点位敏感'这三条规律是跨设备普适的。数据来自本机实测，仅供参考。

On a no-dGPU box, the iGPU can hardware-encode video too — and get files a quarter smaller than CPU soft-encode when handled right. This piece measures the Arc 140T's QSV encoder from number-philosophy to production flags, answering three things: how QSV global_quality differs from x264 CRF, why ICQ explodes after frame-dropping, and where AV1 hardware encode's sweet spot sits.

Env: Core Ultra 5 235H / Arc 140T iGPU / ffmpeg 9.0.1 (gyan essentials, QSV/AMF/NVENC) / 1080p surveillance, SSIM vs lossless. Tested 2026-09-11.

First, the mantra: QSV GQ ≠ x264 CRF

The easiest trap. They look identical at '25', but real quality differs wildly:

Setting	Bitrate	SSIM	Verdict
libx264 crf25	~490kbps	0.990	CPU soft baseline
h264_qsv gq25	~161kbps	0.984	1/3 the bitrate at same number!
h264_qsv gq20	~587kbps	0.990	only now matches crf25
av1_qsv gq25	13.4MB	0.985	GQ not portable across encoders

At the same '25', h264_qsv is ~1/3 the bitrate of crf25, SSIM dropping 0.990→0.984. Matching crf25 quality needs gq20; and AV1's gq25 is not H264's gq25 — GQ values simply don't port across encoders.

The 'ICQ goes wild' problem after frame dropping

This cornered me: after mpdecimate drops frames, encoding with QSV's gq blows up the bitrate. What survives is all 'motion frames', and ICQ quality mode sees high-motion content and throws bits at it:

dropped-frame codec ctrl	time	output	ratio	bitrate
gq20 (original)	32s	187.4MB	2.1x	7.7M ❌
gq30	89.3s	29.9MB	13x	1.12M
gq35	31.3s	12.7MB	31x	403K ✅
b:v800k	32.2s	22.1MB	18x	794K ✅
b:v500k	31.1s	15.2MB	26x	505K ✅

For dropped-frame encodes don't use ICQ (gq) — use constant -b:v (predictable size) or gq35. The 187MB gq20 result, fatter than no-drop, is the smoking gun for the ICQ disaster.

AV1 hardware encode: beating the H264 baseline

The big one: av1_qsv preset 7 + global_quality 27 is this iGPU's sweet spot. At 5× speed vs the baseline:

Metric	Baseline H264 gq25	New AV1 p7 gq27
SSIM	0.9812	0.9825 ✓
Size (A dir, 5 segs)	12.7MB	9.7MB ✓
Ratio	1.6x	2.1x ✓
Time	4s	3.4s ✓
AV sync	59.99/59.92s	同 ✓
Playable	✓	✓

24% smaller, SSIM 0.9825 marginally better, and faster — ahead on all three axes. Re-verified on the busy daytime dir: 16.7MB→14.2MB, still −15%. AV1's preset is sensitive — preset3 is slower with little gain; preset7 + gq27 is the balance point.

Why the hardware-decode chain is unreliable

hwupload=extra_hw_frames=64 → Could not create the texture (0x80070057)
-hwaccel qsv + mpdecimate → -22 Invalid argument — mpdecimate is a software-only filter that can't eat QSV hardware frames
full chain (hwdownload→mpdecimate→hwupload→encode) fails at filter init
d3d11va runs but slower (13.9s vs 3.9s soft decode)
the workable combo: soft decode + qsv hardware encode (no hwaccel feeding the encoder), fastest and error-free

Lowering FPS: the quality ceiling

Want to save by dropping FPS? Measured: fps6–30 always hurts quality — SSIM ceiling ~0.974, can't be bought back. Compression should come from the encoder and static-cutting (mpdecimate/cut-still: see the cutting guide), not frame-rate sacrifice. hqdn3d denoise boosts compression but the CPU filter drags to 44s — unusable.

Parameter cheat-sheet

Use case	Encode	Typical size
smallest + balanced	av1_qsv p7 gq27	−24% vs H264
max compat	h264_qsv -b:v 700k	≈ source bitrate
dropped-frame	h264_qsv -b:v 800k	predictable

Heads-up:These are Arc 140T-specific numbers; different iGPU driver/ffmpeg builds drift, but 'GQ≠CRF, ICQ explodes on dropped high-motion frames, and AV1 preset hits a sharp optimum' hold universally. Local measurements for reference.

返回文章列表