oneapi-src
[Bug]: Min/Max QPI/P/B not in documented 1..51 range
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.
- https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxextcodingoption2
- https://spec.oneapi.io/onevpl/2.5.0/API_ref/VPL_structs_encode.html#mfxextcodingoption2
Using ffmpeg-qsv , we can observe the ranges returned by the runtime as:
- encode 8bit hevc VME returns
MinQPI: 1; MaxQPI: 51; MinQPP: 1; MaxQPP: 51; MinQPB: 1; MaxQPB: 51 - encode 8bit hevc VDENC returns
MinQPI: 10; MaxQPI: 51; MinQPP: 10; MaxQPP: 51; MinQPB: 10; MaxQPB: 51 - encode 10bit hevc VME returns
MinQPI: 12; MaxQPI: 63; MinQPP: 12; MaxQPP: 63; MinQPB: 12; MaxQPB: 63 - encode 10bit hevc VDENC returns
MinQPI: 22; MaxQPI: 63; MinQPP: 22; MaxQPP: 63; MinQPB: 22; MaxQPB: 63 - encode 12bit hevc VME return
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
Hi @uartie , thanks for your report.
We'll update the description of the Min/Max QPI/P/B valid range in the oneVPL spec.
And before that, you can refer to the first note in oneVPL QPI.
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?
Repeating additional details discussed elsewhere:
Seems we have similar problem with VP9 encoder... the actual effective QP range for it is 1..255 but is being clamped by ffmpeg to 1..51. Also, it does not appear the runtime reports the min/max QP for VP9 like it does for avc/hevc.
Hi @uartie , thanks for your report. We'll update the description of the Min/Max QPI/P/B valid range in the oneVPL spec. And before that, you can refer to the first note in oneVPL QPI.
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?
We may do that, but I think the first thing is to clarify the range for each codec in the documentation
Repeating additional details discussed elsewhere:
Seems we have similar problem with VP9 encoder... the actual effective QP range for it is 1..255 but is being clamped by ffmpeg to 1..51. Also, it does not appear the runtime reports the min/max QP for VP9 like it does for avc/hevc.
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
Sorry for my previous misunderstanding, the Query function is used to check if a field is supported or its value is valid, and does not return the actual range of minimum or maximum values.