实测数据

所有数据均为本机实测。测量方法：ffmpeg 内置 libvmaf（默认模型与 NEG 交叉验证）， XPSNR 旁证。四种指标（VMAF / NEG / XPSNR / SSIM）在每个码率点给出完全一致的排序，结论不是某个指标的偏差造成的。

本页导航： GOP · ICQ 扫描 · AV1 对比 · 降分辨率 · Q 缓存 · 音频 · 全量数据总表（含 B 帧 / 编码器 / NVIDIA / 音频）

GOP 长度：整片实测

55.8 秒录屏，ICQ Q30，全片平均码率。体积拐点约 30 秒；但关键帧间隔同时决定拖动定位精度，实际取值由手感约束决定（见本节末）。

测量陷阱：20 秒的短片段无法体现 GOP 差异（一段内最多 1~2 个 I 帧）。曾据此得出"不同构建差 27%"，实为片段过短造成的错觉。

GOP 长度 vs 全片平均码率（越小越省）

先建立标尺：VMAF 分数意味着什么

VMAF	实际观感
≥ 93~95	视觉无损（和源看不出差别）
85~93	优秀（仔细看才见差别）
80~85	很好（偶有轻微痕迹）
70~80	好（能看出压缩痕迹，但不糊）
60~70	一般
< 60	差

人眼 JND（最小可觉差）约 6 分——所以下面表里差 1~2 分基本不用纠结。

ICQ 质量扫描：Q 值换来了什么

这是整套参数里最核心的一张表：三档素材（1080p22 / 720p22 / 1290p60）， ICQ 恒定质量模式，扫遍 Q30~Q40。每格是「码率 / VMAF」。

Q	1080p22	720p22	1290p60
Q30（当前默认）	856 k / 88.6	592 k / 85.0	5471 k / 75.4
Q32（v37–v65 基线）	621 k / 83.8	428 k / 80.1	4180 k / (NEG 71.4)
Q34	485 k / 83.1	330 k / 79.2	3457 k / 71.7
Q37	307 k / 76.3	202 k / 72.2	2378 k / (NEG 65.0)
Q40	225 k / 68.9	144 k / 64.5	—

Q 值 → VMAF（三条曲线各自的边际收益）

1080p22 720p22 1290p60

边际效率递减得非常明显：Q40→Q37 每 +1% 体积能换 0.18~0.20 分（高效区）； Q37→Q34 掉到 0.10~0.12；Q34→Q30 只剩 0.06~0.07，已经进入低效区。按人眼 JND（最小可觉差）约 6 分计，Q30→Q34 是边际收益最高的一段；当前默认取 Q30，若需进一步压缩体积可退到 Q32。

同一个 Q 数字在不同模式含义不同：CQP(-q:v) 与 ICQ(-global_quality:v) 差别巨大—— 1080p Q32 下分别是 352 kbps / 78.3 与 621 kbps / 85.9。别把两种模式的 Q 值混着比。

HEVC vs AV1 vs SVT-AV1

同实际码率下比较（capped VBR，统一换算到同一实际码率）。素材：iPhone 录屏 1290×2796@60，源 15 Mbps。

同码率下的 VMAF（越高画质越好）

HEVC（QSV 硬件） AV1（QSV 硬件） SVT-AV1（软件 p6）

三个读法

硬件 AV1 只在 <1 Mbps 有优势：400k 时领先 HEVC 6.8 分；1 Mbps 以上被反超（交叉点 ≈1 Mbps）。
已经压过的 720p 素材上 HEVC 全程略胜——AV1 的优势区间更窄。
软件 SVT-AV1 才是真赢家：同画质省 40~48% 体积，代价是 0.5~0.65× 实时的速度。

同画质所需码率（目标 VMAF）

目标 VMAF	HEVC (QSV)	AV1 (QSV)	SVT-AV1	SVT 相对最省
70	590 kbps	550 kbps	410 kbps	省 25~31%
75	780 kbps	750 kbps	410 kbps	省 45~47%
80	1100 kbps	1170 kbps	610 kbps	省 45~48%
82	1360 kbps	1440 kbps	810 kbps	省 40~44%

降分辨率 / 降帧率：净损失

方法：成品先 scale 回源规格 + fps 对齐，再与源比 NEG（把分辨率损失算进去）。源是 VFR 录屏，主体 22fps，但 UI / 弹幕 / 原生界面平均 40+ fps。

变体	码率	NEG
A 原生 1290p60 Q37	2378	64.95
B 1080p30 Q32	2301	60.11
C 1080p20 Q32	1926	57.61
D 720p30 Q32	1387	47.48
E 1080p30 Q37	1334	53.02

同码率下为净损失：B 对比 A 低 4.8 分
省 44% 体积的 E，要付 12 分的代价
C vs B 那 2.5 分就是降帧率的真实代价——UI 和弹幕会变卡

结论：不降分辨率、不降帧率。录屏里的 UI 文字、弹幕是原生分辨率细节，一降就糊字。体积只靠 Q 值和上限两把旋钮来控。

Q 缓存：开启后最多损失 3~8 档画质

Q 缓存 = 同规格文件共用实测出来的 Q。听起来省事，实测是把「简单文件」按「同规格最难文件」的 Q 压缩。同 16 个真实文件各跑一批对照：

文件	缓存开	缓存关（定稿）	变化
2026-08-05_01-31	0.56M / Q40	1.46M / Q32	码率 +161%，Q 降 8 档
2026-07-27_15-18	1.15M / Q40	2.50M / Q33	+117%，降 7 档
2026-07-24_13-10	0.99M / Q38	1.75M / Q32	+77%，降 6 档
2026-07-24_13-31	1.00M / Q38	1.72M / Q32	+72%，降 6 档
2026-07-28_18-27	1.71M / Q38	2.33M / Q35	+36%，降 3 档
其余 11 个	完全相同（含 2 个真超标文件）		—

批次指标	缓存开	缓存关（定稿）
Q32 文件数	9 / 16	12 / 16
Q38 / Q40 文件数	7 / 16	2 / 16
平均体积节省	−88.6%	−86.8%
用时	5:13	5:46

按"同体积下画质最优"取向 → 关闭 Q 缓存。代价为：总体积增加 1.8 个百分点、多两次重压（+33 秒）。该取舍可接受。

音频：Opus 的三个拐点

指标用 SI-SDR（尺度不变信噪比，越高越好）。同一实际码率下比较帧长：

frame_duration	实际码率	SI-SDR
60 ms（采用）	65.3 kbps	19.61 dB
40 ms	65.7 kbps	19.61 dB
20 ms（libopus 默认）	67.1 kbps	19.62 dB
10 ms	69.1 kbps	17.83 dB
5 ms	73.9 kbps	16.79 dB

帧长 60 ms 最省：与 20ms 画质相同但码率最低；10ms 以下明显变差。
complexity 10 有收益：同码率 +0.3 dB，保持。
VBR 比 CBR 省 8%：同画质 VBR 56.1k ≈ constrained 65.2k，保持 -vbr:a on。

96k 是性价比点，不是透明点。按外部实测（外部参考第二节）， Opus 在扬声器下的听感透明阈值约为 128 kbps，AAC 约 160k、MP3 需 192k 以上。所以本站默认 96k 的定位要写清楚：归档直播人声（对白为主、动态小）足够；音乐素材或高动态内容建议提到 128k。

效率优先级一览

同画质下比较码率，各项单独实测的节省幅度。表中 GOP 取值为"纯体积最优"，与默认取值不同，原因见下一节。

优化项	省多少	生效条件
ICQ 取代 CQP (`-q:v`)	5~7%	质量模式（默认路径），单项收益最大
GOP 拉长到 8 / 33 秒	4.1% / 7.5%	两种模式均有效；与手感约束冲突，默认不采用
`-extbrc 1`	3.7%	仅上限（VBR）模式有效；ICQ 下为 0%
preset veryslow（相对 medium）	2.6%	均有效，但耗时 ×1.44，不采用
GOP 20 秒相对 10 秒	1.8%	两种模式

上限模式的代价：同码率下 ICQ 比 capped VBR 高约 0.4 VMAF，且最差帧差距巨大（min VMAF ≈75 vs ≈54）。上限模式是"体积可控"的保险，不是画质的选择——所以它只用来兜底超标文件。

不显式设置时，编码器在干什么

这一节记录 ffmpeg / QSV 没有显式下发参数时的默认行为—— 很多"莫名其妙的卡顿"根子都在这。

隐式默认	实测值	后果
`-bf`（B 帧）	3（QSV 默认，从未显式设置过）	—
不下发 `-g`	QSV 默认 GOP ≈ 4 秒	灾难所有产物拖动明显卡顿
最小关键帧间隔	≈ 48 帧	低帧率素材设「1 秒」会被夹到约 1.6 秒
日志可见的默认	`GopRefDist=8`、`NumRefFrame=4`、`Idr=1`	—

关键教训：关键帧间隔必须由我们显式给出，不能依赖编码器默认值。 曾有一版把「自适应」实现成不下发 -g（交给编码器决定），结果 QSV 默认 4 秒 GOP，所有产物拖动明显卡顿。已改回显式设置。

六种素材：源自己的 GOP 是多少

先测源自身的关键帧间隔，再决定取值取向：以源为基准，避免与源差距过大影响拖动定位。

素材	规格	源自己的 GOP
iPhone 录屏	1290p60	1.00 s
相机 DV	4K60 10bit	0.93 s
电影	4K30 / 45 Mbps	1.00 s
直播流 ×3	720p38 / 1088p22 / 1088p20	1.85~2.15 s

GOP 对码率的实测（60 秒片段，Q32 / medium / 不限制）

素材	gop1	gop2	gop3	gop4	gop8	1→2	2→4
iPhone 录屏	2627	2239	2126	2057	1970	−15%	−8%
相机 4K60	4805	4598	4513	4525	4455	−4%	−2%
电影 4K30	1973	1690	1579	1544	1465	−14%	−9%
直播 720p38	542	492	472	469	457	−9%	−5%
直播 1088p22	936	818	772	749	720	−13%	−8%
直播 1088p20	995	837	800	781	724	−16%	−7%

码率收益集中在 1→4 秒，4 秒后基本到顶。 但手机上实测手感是另一回事：相机 / 录屏 / 电影只有 GOP 1 秒才跟手， 2 秒就不流畅，4 秒卡成 PPT；直播流 1~4 秒都流畅，6 秒起不流畅。

所以最终改成自适应：相机 / 10bit / 4K 及以上 → 1 秒；其余 → 2 秒。菜单里 1/2/4/自定义都可选。
另加 -forced_idr 1（QSV）/ -forced-idr 1（NVENC）：保证每个关键帧都是 IDR（闭合 GOP）。

全量数据总表（原始记录）

上面各节讲的是"结论怎么来的"，这一节把原始表格全部摊开——包含分散在「硬件与并发」页的 Intel / NVIDIA 对照数据。这一节的目的很简单：不用翻第二个网站。

1. 源素材规格（八种，含 bpp）

素材	分辨率 / 帧率	色彩	源码率	bpp	源 GOP	B 帧
iPhone 录屏格式	1290×2796@60	8bit bt709	14.9 Mbps	0.069	1.00 s	2
相机 DV	3840×2160@59.94	10bit HLG（DV 8.4）	81.6 Mbps	0.164	0.93 s	2
电影	3840×2160@29.97	8bit	44.95 Mbps	0.181	1.00 s	1
直播流 720p	720×1280@38	H.264	1.07 Mbps	0.031	2.15 s	2
直播流 1088p	1088×1920@22	H.264	1.91 Mbps	0.042	1.85 s	2
直播流 1088p	1088×1920@20	H.264	2.97 Mbps	0.071	2.05 s	2
已压缩旧文件	1290×592@22 等	—	~1 Mbps	—	11.27 s	0
弹幕渲染产物	1440×1088@20 HEVC	—	597 kbps	—	12.4 s	3

2. B 帧对照（最严谨的一组实验）

无损参照（ffv1 / x265 lossless）+ 输出侧 seek，VMAF 以原片为参照。每格是「码率 kbps / VMAF」，加粗为该源的最优体积。

素材	默认（不写）	-bf 0	-bf 1	-bf 2	-bf 3	VMAF 极差
iPhone 录屏	2906 / 93.09	2765 / 92.60	4100 / 93.54	3991 / 93.52	3563 / 93.44	0.94
相机 4K60	6094 / 70.39	9222 / 70.38	12495 / 70.73	11482 / 70.66	8448 / 70.58	0.35
电影 4K30	3247 / 33.51	3812 / 33.25	4738 / 33.39	4575 / 33.37	3864 / 33.47	0.26

控制项：各档实际关键帧间隔 2.00~2.05 秒完全一致（只改了 B 帧）；实际 B 帧数 default→3、bf0→0、bf1→1、bf2→1、bf3→2（-bf 是上限）。
默认（不写）在 5 个源里 4 个体积最小；显式设置一律更费码率，最多 +41%。
VMAF 极差最大 0.94，远小于人眼 JND（约 6 分）→ B 帧是码率旋钮，不是画质旋钮。

3. 编码器对比：QSV vs x265（含手机手感）

同 GOP 2 秒 / 同 Q·CRF 30 / 同 faststart，用同一段素材，真机上手拖。

编码器	体积	VMAF	手机拖动手感
`hevc_qsv`（CTU 64）	7.23 MB	98.84	卡
`x265` ctu32	4.14 MB	97.54	跟手
`x265` ctu64	3.46 MB	97.66	跟手

ctu32 与 ctu64 手感无差别，画质几乎相同（差 0.01~0.12），但 ctu64 小 10~20%。而 x265 表面"省 43%"其实是 CRF30 画质更低所致——x265 与 QSV 的率失真效率相当。
结论：手感取决于编码器（硬编 QSV vs 软编 x265），与 GOP / B 帧 / CTU / 容器参数全无关。 代价是软编慢 4~15 倍（4K60 10 秒：14 s → 66~75 s），所以默认不做软编档。

4. 手机跟手矩阵（GOP × 素材）

GOP	直播流（720p / 1088p）	相机 / 录屏 / 电影
1 秒	极流畅 ✓	还算顺畅 ✓
2 秒	极流畅 ✓	不流畅 ✗
3 秒	与 4 秒接近	卡成 PPT ✗
4 秒	流畅 ✓	卡成 PPT ✗
6 秒	不流畅 ✗	—

5. QSV preset 的真相：7 个名字只对应 3 档

preset 名	实际 TargetUsage	capped 速度	capped VMAF	ICQ Q30 速度	ICQ VMAF
veryfast / faster	TU=7	3.28~3.37×	81.83	3.41~3.42×	86.53
fast / medium / slow	TU=4	3.15~3.18×	82.55	3.27~3.29×	86.73
slower / veryslow	TU=1	2.20×	82.76	2.38×	86.79

TU4 相对 TU1 快 1.44 倍、画质只低 0.21（ICQ 下 0.06）→ 默认 medium；TU7 快 1.5 倍但掉 0.93。

6. NVIDIA NVENC 实测

并发（同片段 1/2/3/4 路，量合计吞吐与单文件速度）：

路数	arc 合计吞吐	arc 单文件	RTX 2060 合计吞吐	RTX 2060 单文件
1	2.18×	2.18×	2.18×	2.18×
2	3.82×（+75%）	1.92×	2.58×（+18%）	1.30×
3	3.96×（+81%）	1.48×	2.60×（+19%）	0.87×
4	3.99×（+83%）	1.01×	2.68×（+23%）	0.68×

Intel 2 路拿走 75% 收益、单文件只掉 12%；N 卡 2 路只 +18%，单引擎建议 1 路。

NVENC 的 Q 标尺与 QSV 完全不同（CQ 扫描，单位 MB，目标是对齐 QSV Q30 的体积）：

素材	cq30	cq32	cq34	cq36	cq38	QSV(Q30)	匹配点
直播 720p38	6.76	5.36	4.31	3.51	2.91	3.5	cq36 = 1.00×
直播 1088p22	15.11	11.87	9.29	7.36	5.90	5.9	cq38 = 1.01×
直播 1088p20	1.25	0.96	0.75	0.59	0.47	0.5	cq38 = 0.89×
iPhone 录屏	18.61	14.93	11.85	9.56	7.73	6.9	cq38 = 1.12×
电影 4K30	56.29	42.60	32.93	25.93	20.80	12.1	cq38 仍 1.72×

直播流 / 录屏：NVENC cq36~38 ≈ QSV Q30（与 rigaya 基准里"实拍类 NVENC ≈ QSV + 6"的口径一致）。但电影级素材 NVENC 明显更差——cq38 仍比 QSV 大 72%。 结论：归档优先 QSV，NVENC 用于赶时间。
⚠️ NVENC 的 QVBR 上限模式（-b:v + -maxrate）尚未在真实 N 卡上验证——本机无卡，只验证了 CQ 标尺与并发。

7. 音频：本站实测 + 外部透明阈值

本站实测（SI-SDR，越高越好，同一实际码率下比帧长）：

frame_duration	实际码率	SI-SDR
60 ms（采用）	65.3 kbps	19.61 dB
40 ms	65.7 kbps	19.61 dB
20 ms（libopus 默认）	67.1 kbps	19.62 dB
10 ms	69.1 kbps	17.83 dB
5 ms	73.9 kbps	16.79 dB

外部实测的听感透明阈值（出处，纯音乐 + 消费级音箱，比视频对白更吃码率）：

格式	透明阈值	低码率表现
MP3	≥ 192 kbps	64k 砍 11~12 kHz 以上；192k 仍砍 18 kHz
LC-AAC	约 160 kbps	从 13 kHz 起渐进衰减，人声好、伴奏易糊
Opus	约 128 kbps	64k 就无条件保留全频谱

本站默认 96k 的定位：性价比点，不是透明点。归档直播人声（对白为主、动态小）96k 足够；音乐素材或高动态内容建议提到 128k。