> 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@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@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
