Repository navigation
vaapi: in-process RC max_qp 44→51，有上限档位能到 QP 51 硬件下限 (#33) - #102
Merged
Merged
Conversation
…he hardware floor (VallierDev#33) max_qp is the worst-quality guardrail, not an operating point: the VCN VBR loop picks QP per frame inside [min_qp, max_qp]. Capping it at 44 stopped the encoder from degrading far enough to approach the bitrate target when the content needs more than the QP-44 floor; 51 is the codec maximum and matches what the FFmpeg process pipeline already runs at (max_qp unset). Measured (Cezanne, in-process VAAPI, tier 1 / 1M target, 600 frames): - 1920x1200 fullscreen testsrc2: 1.77 -> 1.36 Mbps - 2560x1600 fullscreen testsrc2: 4.16 -> 2.60 Mbps - regression: normal dynamic scene tier 1 ~0.9-1.0 Mbps, tier 3 unchanged
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Contributor
Author
|
勘误一处：初版正文把 tier 1 的 1.03 → 0.88 归为 live 场景时序噪声，这是错的。同场景 tier 2/3 与改前字节级一致（0.01% 内），证明场景可复现；改动后 tier 1 同一二进制复跑三次为 0.88 / 0.88 / 0.85 Mbps，稳定低于改前的 1.03。结论：该场景内容偶尔需要 QP > 44 才能压进 1M 上限，旧护栏下 VBR 停在 1.03 略超上限，放宽后真正落进上限——低档在正常内容上也会更贴目标。正文已更新。 |
Owner
|
谢谢！改动小，前后对照也完整：2560x1600 tier 1 从 4.16 降到 2.60 Mbps，正常场景 tier 1 从 1.03 降到 0.88，进一步贴近目标，tier 2/3 字节级一致。CI 全部通过，已 squash 合并，会随下一版发布。 🤖 Generated with Claude Code |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
改动
c_engine/vaapi_engine.c一行：RCmax_qp44 → 51（#80 引入的硬编码）。min_qp、initial_qp保持不变。max_qp是最差画质的护栏而非工作点：驱动的 VBR 逐帧在 [min_qp, max_qp] 内选 QP。44 会挡在 QP 51 硬件下限之前，让有码率上限的档位到不了它能到的最低码率（#33 勘误后的结论）；51 是编码器最大值，与进程管线的实际行为一致（FFmpeg 不传 max_qp 时驱动默认放行到 51）。实测（Cezanne / radeonsi renoir，Mesa 26.2.5，in-process VAAPI，XShm 上传，live 抓屏，desktop-video-probe）
live 2560x1600 满屏 testsrc2，tier 1（目标 1M），600 帧：4.16 → 2.60 Mbps（旧 44 护栏挡在硬件下限之前）。
live 1920x1200 满屏 testsrc2，tier 1，600 帧：1.77 → 1.36 Mbps。
正常动态场景（1920x1200 桌面 + 1280x720 60fps 测试图窗口，每档 1200 帧 = 20 s）改动前后对照：
高档不受影响（tier 2/3 与改前几乎逐字节相同，同场景可复现到 0.01%——这也排除了「场景不同时段」的干扰）。tier 1 的 1.03 → 0.88 是改动本身的效果，不是噪声：这个场景的内容偶尔需要 QP > 44 才能压进 1M 上限，44 护栏下 VBR 只能停在 1.03（略超上限），放宽到 51 后真正落进上限内。即低档在正常内容上也会更贴目标，与改动目的一致。
测试
cargo test全绿（208 passed）；--features inproc-avrelease 构建通过，探针复测如上。