-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Min/Max QPI/P/B not in documented 1..51 range #297
Comments
@yefeizhou any comment? |
VSMGWL-68223 |
Auto Created VSMGWL-69251 for further analysis. |
Hi @uartie , thanks for your report. For the middlewire, since it's a long-standing change in VPL and various customers have already adapted this who use VPL directly, Hi @wenbinc-Bin @xhaihao could you help adding 10bit and 12bit QP calculation based on this logic in ffmpeg-qsv? |
@wenbinc-Bin @xhaihao comments? |
Repeating additional details discussed elsewhere:
|
We may do that, but I think the first thing is to clarify the range for each codec in the documentation |
Hi @leyu-yao could you please help update the valid QP range for AV1&VP9 in the VPL spec? |
Can we query the implementation for Min/Max QPI/P/B at runtime? |
Hi @uartie |
Use a valid QP range accepted by the iHD driver for HEVC 10bit. Unfortunately, there is still a bug in ffmpeg and vpl that incorrectly forces QP in the wrong range... See intel/vpl-gpu-rt#297 Thus, until the issue is fixed, the ffmpeg-qsv encoder code needs to be modified, manually, to remove the QP range constraints so that the requested values can propogate to vpl and the driver to properly generate a trendline model. Signed-off-by: U. Artie Eoff <[email protected]>
Use a valid QP range accepted by the iHD driver for HEVC 10bit. Unfortunately, there is still a bug in ffmpeg and vpl that incorrectly forces QP in the wrong range... See intel/vpl-gpu-rt#297 Thus, until the issue is fixed, the ffmpeg-qsv encoder code needs to be modified, manually, to remove the QP range constraints so that the requested values can propogate to vpl and the driver to properly generate a trendline model. Signed-off-by: U. Artie Eoff <[email protected]>
Which component impacted?
Encode
Is it regression? Good in old configuration?
No, this issue exist a long time
What happened?
VPL and MSDK documentation states Min/Max QPI/P/B valid range is 1..51 (0 for default).
However, the runtime returns ranges outside of the documented range depending on the codec, bitdepth, and/or VME vs. VDENC mode.
Using ffmpeg-qsv , we can observe the ranges returned by the runtime as:
MinQPI: 1; MaxQPI: 51; MinQPP: 1; MaxQPP: 51; MinQPB: 1; MaxQPB: 51
MinQPI: 10; MaxQPI: 51; MinQPP: 10; MaxQPP: 51; MinQPB: 10; MaxQPB: 51
MinQPI: 12; MaxQPI: 63; MinQPP: 12; MaxQPP: 63; MinQPB: 12; MaxQPB: 63
MinQPI: 22; MaxQPI: 63; MinQPP: 22; MaxQPP: 63; MinQPB: 22; MaxQPB: 63
MinQPI: 24; MaxQPI: 75; MinQPP: 24; MaxQPP: 75; MinQPB: 24; MaxQPB: 75
Unfortunately, VPL/MSDK will clamp any user value outside of these ranges. Additionally, ffmpeg-qsv also clamps any value outside of 1..51 range. So even though user can pass any value to ffmpeg-qsv, the effective honored range will only be [MinQPI/P/B, 51]. Apart from being confusing to the end-user, this means the ffmpeg end-user is unable to take advantage of the full underlying QP range that is achievable by the runtime.
From the middleware (ffmpeg, gstreamer) perspective, the end-user should not have to know about these internal/runtime nuances. Thus, the runtime should map it's documented standard 1..51 range to its underlying actual range.
What's the usage scenario when you are seeing the problem?
Transcode for media delivery
What impacted?
gstreamer, ffmpeg, other user apps/middleware. Compression levels may appear low for default values in apps/middleware.
Debug Information
Verified issue on TGL
Do you want to contribute a patch to fix the issue?
None
The text was updated successfully, but these errors were encountered: