HLG input disables hardware decoding
bavdevc opened this issue · 9 comments
Hello @rigaya
I'm testing the Meteor Lake iGPU atm and I see an error with hardware decoding for HEVC/HLG input files. The software decoder is used although the hardware decoder works nowadays in ffmpeg.
current QSVEnc:
avqsv: Failed to get header for hardware decoder, switching to software decoder...
current ffmpeg with qsv hw decoder:
[hevc_mp4toannexb @ 0x56957ad4a940] No parameter sets in the extradata
but it works perfectly fine in ffmpeg with hw decoder, it's just a warning and the default transfer is arib-std-b67->bt2020-10
The major problem here is that the header is not parsed by libavformat demuxer. QSVEncC will not support hw deocding when header is not parsed correctly, due to implementation reason.
QSVEncC fills decoder initialization parameter by MFXVideoDECODE_DecodeHeader, and then initialize decoder by MFXVideoDECODE_Init, so header is required for decoder initialization.
I don't know about ffmpeg, but they might be setting the decoder initialization parameter in different way, but I don't want to go into it further because there are many fields to be filled, and using MFXVideoDECODE_DecodeHeader is the most simple way.
ok, I understand your implicit assumption now - just checked QSVPipeline/rgy_input_avcodec.cpp and QSVPipeline/qsv_mfx_dec.cpp and the corresponding issues - also in nvenc project.
It's better to use avsw in those edge cases when hevc_mp4toannexb doesn't give a valid return value.
btw. HLG doesn't use metadata - so "No parameter sets in the extradata" is fine in that case
Thank you for your description
QSVEnc 7.69 improves furthermore, and enables hardware encoding in this case. It will now extract the headers (VPS/SPS/PPS) from the first packet when not parsed by libavformat demuxer.
This codec is “special”???
I always thought that:
264/AVC
265/HEVC
I'm sorry but don't get the point. Please write a little more in writings about the details.
This codec is “special”???
It is talking about H.264 or HEVC, nothing else, so there shall be nothing special, or I might have misunderstood what you are trying to say.
The next picture
Would you please explain more about what is mentioned by this picture in writings? What is the problem here?
There was mismatch of the values for --output-csp between NVEnc and QSVEnc, so I've changed that value of QSVEnc to match those of NVEnc.
HEVC codec, is it 265?
driver release for intel QSVENC 7.69 is mentioned nvidia NVENC, is this normal? Are there any errors in the code, due to incorrect routings?
HEVC codec, is it 265?
Yes.
Are there any errors in the code, due to incorrect routings?
This is nothing related to errors, it's only changing the option values (i420 → yuv420, i422 → yuv422, i444 → yuv444) and nothing else.
driver release for intel QSVENC 7.69 is mentioned nvidia NVENC, is this normal?
Yes, there is nothing strange. I'm also developing another encoder NVEnc using NVENC, and options are similar. Therefore, I should keep the options values consistent when I can, but I noticed that the values were accidentally named different for --output-csp, so I mentioned it for the reason why I changed the option values.
The nature of this is simply that I changed the option values for --output-csp, and that is all.
aaa, OK