Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
> Thompson
> Sent: Monday, January 10, 2022 9:57 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a
> hwdevice, search for existing device in both directions
> 
> On 10/01/2022 01:40, Soft Works wrote:
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
> >> Thompson
> >> Sent: Monday, January 10, 2022 1:57 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When
> deriving a
> >> hwdevice, search for existing device in both directions
> >>
> >> [trimmed somewhat]

> > To wrap things up a bit:
> >
> > - you want an approach which requires even more complicated filter
> >    command lines.
> 
> Ha, that characterisation isn't exactly neutral - the derivation in filter
> graphs is removed and replaced with explicit specification of devices.

The comparison in your other reply wasn't realistic. Actually it would
look similar to this:

BEFORE

ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf "hwmap=derive_device=vaapi,
format=vaapi,hwmap=derive_device=vulkan,scale_vulkan=w=1920:h=1080" -f null -

AFTER

ffmpeg -init_hw_device vaapi=vadev -init_hw_device qsv=qsvdev@vadev 
-init_hw_device vulkan=vkdev@vadev -hwaccel qsv -c:v h264_qsv -i input.mp4 
-vf "hwmap=hw_device=vadev,format=vaapi,hwmap=hw_device=vkdev,scale_vulkan=w=
1920:h=1080" -f null -


This is more like a ** to all those who are writing command lines by 
hand and surely not an improvement.
I have not been involved in the cli design, but from looking at the result
it's clear that there has always been a focus on allowing things to be 
done as easily as possible instead of needing to do extensive reading 
until you get it right (or give up).


> Perhaps you even want to add to the av_hwdevice_ctx_create_derived() API so
> it can take a YKNOW_ACTUALLY_DONT flag to indicate you don't want to create a
> new derived device, I don't know.

When you mean to add av_hwdevice_ctx_create_derived2() or 
av_hwdevice_ctx_create_derived_ex() which takes an additional parameter to
control this and which the ffmpeg-tool will use instead, that would be fine 
I think.
It would allow to make the change only for the cl tool without affecting
API consumers (regardless of whether such cases may exist or not).

softworkz


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".