[FFmpeg-devel] [PATCH] avutils/hwcontext_qsv: set the source device in qsv_device_create

Xu, Guangxin guangxin.xu at intel.com
Sun Mar 14 04:28:40 EET 2021


> You are hacking it to lie to the hwcontext implementation around how the
> device was derived, so the test fails because it finds a different derivation
> structure to what it created?  That seems correct?
> 
> Your command-line was:
> 
> $ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device
> opencl=ocl at intel -hwaccel qsv -c:v h264_qsv -hwaccel_output_format qsv -i
> $input -filter_hw_device ocl -vf
> 'hwmap=derive_device=opencl,format=opencl,unsharp_opencl,hwmap=der
> ive_device=qsv:reverse=1:extra_hw_frames=32'  -c:v hevc_qsv  -y test.h265
> 
> So that's trying to make five device references in turn:
> 
> 1. Make a VAAPI device explicitly.
> 2. Derive an OpenCL device from the VAAPI device 1.
> 3. Make a libmfx device implicitly (because a libmfx decoder was requested).
> 4. Derive a new OpenCL device from the libmfx device 3 (you told the filter
> graph about device 2, but then didn't use it anywhere).
> 5. Derive a libmfx device from the OpenCL device 4, which should return
> libmfx device 3.
> 
> What's going wrong?  Step 4 fails to create an OpenCL device because
> devices 1/2 and device 3 aren't actually connected together at all.
> 
> How to solve that?  Either we can fix the connection, or we could just use the
> device we already have in step 4 rather than trying to create a new one.
> 
> To fix the connection, derive device 3 from device 1.  This doesn't work in the
> ffmpeg utility because the hacky support in ffmpeg_qsv.c doesn't support
> the normal device stuff.  It would work in your own program.
> 
> Using the existing device (by using device 2 rather than deriving a new on at
> step 4) looks like it should work:
> 
> $ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device
> opencl=ocl at intel -hwaccel qsv -c:v h264_qsv -hwaccel_output_format qsv -i
> $input -filter_hw_device ocl -vf
> 'hwmap,format=opencl,unsharp_opencl,hwmap=derive_device=qsv:revers
> e=1:extra_hw_frames=32'  -c:v hevc_qsv  -y test.h265
> 
> Unfortunately it doesn't, and for the same reason that the first approach
> didn't - devices 1 and 3 aren't connected, so the OpenCL mapping is being
> given frames in the wrong device context and therefore fails (in fact the Intel
> ICD crashes with an abort, which is about the best you can hope for with this
> sort of undefined behaviour).
> 
> 
> So, how can we make this work?  Well, the weird libmfx hacks are causing the
> problem, so let's just duck that by dumping the pointless wrapper decoder
> and using the normal decoder directly:
Hi Mark,
Thanks for the detailed explaining. I will try the vaapi path.

thanks
> 
> $ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi -
> hwaccel_output_format vaapi -i $input -vf
> 'hwmap=derive_device=opencl,format=opencl,unsharp_opencl,hwmap=der
> ive_device=qsv:reverse=1:extra_hw_frames=32'  -c:v hevc_qsv  -y test.h265
> 
> If you want to make it work with the libmfx wrapper decoder, then I think
> the most sensible way is to implement
> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX in that decoder so it
> works like the others and the ffmpeg_qsv.c hacks can be removed entirely.
> 
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-request at ffmpeg.org
> with subject "unsubscribe".


More information about the ffmpeg-devel mailing list