fix(vaapi): use VBR rate control mode #3337
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3337 +/- ##
=======================================
Coverage 11.15% 11.15%
=======================================
Files 99 99
Lines 17183 17180 -3
Branches 8009 8008 -1
=======================================
Hits 1916 1916
+ Misses 12580 12577 -3
Partials 2687 2687
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
|
VBR is required because CBR with reasonably relaxed VBV still results in poor quality on Intel? |
|
What I'm finding in my VAAPI testing with several AMD and Intel GPUs with a single frame VBV is that VBR appears to behave like CBR except that it allows bitrate undershoots (which is what we want). The quality issues seen on Intel with CBR and a single frame VBV are similar to what we already saw with QSV and solved by forcing VBR there. In my testing with an RX 7600, I noticed bitrate overshoots happening periodically with both VBR and CBR modes, despite setting a single frame VBV. VBR allowed the bitrate to drop when content was relatively static while CBR was pumping 150 Mbps constantly, so VBR seems like a clear win there. I did verify that this change alone does not fix the poor encoding quality on Polaris cards (though my RDNA3 card was totally fine, regardless of the VBV). So I'm thinking for the full solution:
|
|
Sporadic 2x-3x overshoots for a frame are expected without pre-analysis pass due to the parallel nature of hardware encoding, but not sure this can be controlled in VAAPI. What I meant by "relaxed" VBV is that we don't have to choose between two extremities - single frame or "off", but may settle on something like 4 or 5 frames. Because otherwise it may default to something like 1 second since it performs better in the usual periodic GOP scenarios. The fact that CBR also enables zero padding is certainly a bummer though, again not sure if it can be controlled in VAAPI. |
Yeah, unfortunately even pretty relaxed VBV buffers like 250 ms still cause Polaris's encoder to produce garbage quality. What I ended up doing for #3332 is basically choosing between 2 operating modes:
The former works great for Intel GPUs and AV1 on AMD GPUs (likely any codec for RDNA3 and later, but I wanted to be conservative). It is also what we use for QuickSync (which likely shares RC logic with Intel's VAAPI driver). The latter is what we will default to for H.264 and HEVC on AMD GPUs, but we'll allow users to override if they want. The coupling of RC mode and RC buffer size helps to balance the negative effects of each other. Single frame VBV avoids the VBR pitfall of producing massive frames using RC headroom provided by earlier smaller frames. CBR avoids some of the downsides of a larger VBV by ensuring a near constant frame size. Closing this PR in favor of the full fix in #3332 |
|
The bitrate drop feature looks impressive. I hope this PR will be merged. |
Description
This is a possible alternative fix for #2864 that could be taken instead of #3332.
In the case of single frame VBV size, using CBR with VAAPI seems to have major quality problems with Intel and AMD drivers. VBR behaves much better in my testing (Intel H.264 case) and allows us to still enforce a reasonable frame size limit without causing the video quality to suffer. Interestingly, we also had to do something similar with the QuickSync encoder using the
CBR_WITH_VBRquirk flag to force VBR mode.As a nice side effect, it also allows the video bitrate to drop when content is static, rather than adding useless filler data to the bitstream to preserve the exact specified bitrate. This also fixes the decoder compatibility issue reported in #3331.
Screenshot
Issues Fixed or Closed
Type of Change
.github/...)Checklist