本文记录一套可复现的压缩方案：在肉眼不可辨的前提下，把常见来源的视频压到原体积的约 1/7。 实测覆盖六类素材——录屏、相机 4K60 10bit HLG、电影 4K30、三档直播流，以及已被压缩过一次的成品。 结论按每像素比特（bpp）分组，便于对应到其他素材。
口径说明：以上四项来自 2026 年的一次真实批量任务（16 个 1080p 录屏，Q32、2.5 Mbps 上限、Opus 64k）。 工具当前默认质量已调为 Q30，同素材下体积略增、画质略升（1080p 实测 VMAF 88.6 / 856 kbps）。 本站数据表保留 Q32 批次原值并标注版本，不做换算或改写。
压缩参数与素材类型强相关，因此先把样本摊开。前六行用于参数实验， 后两行是"已被压缩过一次"的产物，用于确认参数边界。
| 素材 | 分辨率 / 帧率 | 色彩 | 源码率 | bpp | 源自带 GOP | B 帧 |
|---|---|---|---|---|---|---|
| iPhone 录屏格式 15 Mbps 高码率档的一员 |
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 |
| 已压缩旧文件 2022.07 的产物 |
1290×592@22 等 | — | ~1 Mbps | — | 11.27 s | 0 |
| 弹幕渲染产物 | 1440×1088@20 HEVC | — | 597 kbps | — | 12.4 s | 3 |
为什么按 bpp 分组而非码率。 同样写作"15 Mbps"，在 1290×2796@60 上是 0.069 bpp（每像素比特偏低）； 而 4K60 的 81.6 Mbps 是 0.164 bpp。码率数字跨分辨率不可比， 因此下文每条结论均标注适用素材，而非笼统地写作"视频"。
后两行的意义：其源自带 GOP 为 11.27 s / 12.4 s（248 帧），
即 ffmpeg 未显式设置 -g 时的默认值（250 帧）。两次实测均证实：
未设 GOP 的产物在硬件播放器上拖动明显卡顿。这是本档案中最易被忽略的一处。
恒定质量模式（ICQ）相比固定量化（CQP）在同画质下节省 5~7% 码率，六类素材均成立。
两个前提：-global_quality 必须限定视频流作用域（:v），
否则参数会落到音频编码器上导致编码失败；ICQ 能否启用取决于 ffmpeg 构建，
2026-10 的 master 构建无法送达该参数，9.0 分支正常。
仅看体积，关键帧间隔越长越省：整片实测的拐点在 30 秒左右，gop1 → gop8 在录屏上省 25%。 但手机端拖动定位的手感要求更短的关键帧间隔——相机 / 录屏 / 电影素材在 GOP 2 秒即出现不流畅， 4 秒已不可用。最终取值：自适应，相机 / 10bit / 4K 取 1 秒，其余取 2 秒， 以约 6~9% 的体积代价换取可用性。若只做冷归档、不需拖动，可手动放宽至 8~30 秒。
| 素材（ICQ Q32 / medium / 不限码率） | gop 1 s | gop 8 s | 降幅 |
|---|---|---|---|
| iPhone 录屏 | 2627 kbps | 1970 kbps | −25.0% |
| 相机 4K60 | 4805 kbps | 4455 kbps | −7.3% |
| 电影 4K30 | 1973 kbps | 1465 kbps | −25.7% |
| 直播 720p | 542 kbps | 457 kbps | −15.7% |
| 直播 1088p22 | 936 kbps | 720 kbps | −23.1% |
| 直播 1088p20 | 995 kbps | 724 kbps | −27.2% |
显式写 -bf 0/1/2/3 在五个测试源上全部更费码率（最多 +41%），
而各档 VMAF 极差仅 0.94——远小于人眼可觉差（约 6 分）。
结论：B 帧是码率旋钮，不是画质旋钮。默认值（QSV 为 3）已是五个源中四个的最优解。
extbrc、look-ahead、mbbrc、adaptive_i/b、scenario、rdo 等 19 个开关， 在 ICQ 模式下输出逐字节相同，无一能提升同码率画质。 ICQ 下真正有效的参数只有三个：质量值、TargetUsage（preset）、GOP 长度。
同画质下 SVT-AV1（preset 6）比两种硬件编码器省 40~48% 体积， 代价是 0.5~0.65 倍实时速度。对归档场景（不在意编码时长）这是明确选择； 对需要当天出片的场景则不适用。
在相同 GOP、相同质量值、相同 faststart 条件下，hevc_qsv 的产物在真机上拖动卡顿，
换 x265 即恢复正常（ctu32 与 ctu64 表现一致）。GOP、B 帧、CTU、容器参数均尝试过，
无一能改变该结果。代价是软件编码慢 4~15 倍，因此默认不提供软编档。
上述数据的生成工具均开源，默认参数与提交历史可逐项复核。
两个栏目并非拼凑。弹幕渲染项目的第 1 项改造，
与本站编码栏目的第 1 条前提是同一个问题——-global_quality 缺少 :v 流说明符，
参数落到音频编码器，导致 0 字节产物。同一处缺陷、两条独立工序先后撞上，
这也是把两者放在同一站点的原因。
起点很具体：iPhone 录屏（1290×2796@60，约 15 Mbps）体积过大，归档没有必要保留原始码率。 实测展开后，问题很快超出单一素材——相机 4K60 10bit HLG 为 81.6 Mbps、电影素材 44.95 Mbps、 直播录制仅 1~3 Mbps。同一组参数在这四类素材上表现差异显著： 高码率实拍对 GOP 敏感，低码率直播流则相对钝感。
因此本文档按"素材类型 → 参数行为"组织，而非按软件用法组织。 硬件为 i3-12100F + Arc A380，走 Intel QSV 硬件编码（含零拷贝解码）， NVIDIA NVENC 作为对照线路。全部结论基于 ffmpeg 9.0 分支，VMAF / NEG / XPSNR 交叉验证， 测量方法本身的偏差亦记录在案——部分"优化"实际是测量误差，这部分同样保留。
外部资料仅作参考并标注出处（见外部参考）： 本站结论以本机实测为准，与外部资料不一致处会明确说明条件差异。