Re: [FFmpeg-devel] [RFC] User-defined default enc/dec/mux/dem/etc

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Thilo
> Borgmann
> Sent: Tuesday, June 7, 2022 3:26 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: [FFmpeg-devel] [RFC] User-defined default enc/dec/mux/dem/etc
> 
> Hi,
> 
> currently, if -c:{a,v} is not given, the list of all codecs is successively
> searched until the first enc/dec is found.
> 
> If I have two or more enc/dec's for the same codec ID (like by having
> libx264, libfdk-aac, etc..) it will still be the first in the list that is
> found that is used if no -c:{v,a} is given. Having a list of user-defined
> default enc/dec's avoids having the user to always specify their favorite via
> -c:{v,a}.
> 
> This patch creates a (redundant) list of default codecs user-defined via
> configure options. This list is then searched before the complete list of
> codecs is searched so that all user defaults will be found first. An
> alternative would be messing with the order of codecs during configure and
> creation of lavc/codec_list.c to have the defaults found first - which I
> think is not a good idea. Maybe do something else entirely instead...?


> For the case you have hwaccel's for the codec ID in question, a default
> specified currently uses the hwaccel-enc/-dec even if no "-hwaccel something"
> is given on the command line. What would we want to happen? Stick to use only
> if given like auto hwaccel decoding?


I don't have much opinion on making codec priorities configurable, maybe it's
useful for somebody..
But with regards to automatic use of hw acceleration, I'm very clear on
that I don't think it makes any sense to do something like this.
There exist literally hundreds of reasons why a certain hw acceleration doesn't
work in a certain situation, environment, hw, sw, permissions, drivers, middle
ware, OS type, OS version, OS configuration, kernel version, firmware, kernel
params, virtualization, patches, updates, etc - and that's just the top level.
Besides all these things, the hw capabilities are most important to know and
consider. ffmpeg having an hevc_vaapi encoder, doesn't mean that it can be used
with the available hardware, just to give an example.

Configuring something like auto-hwaccel usage at build-time is rather a way 
to ensure frequent failure than doing any good IMO.

Even assuming it would be done and a hwaccel would be auto-selected - how would
you "unselect" it?
(for decoder, for filter graph, for encoder)


What _might_ make some sense for some and what I could imagine a little bit
better would be a kind of "defaults" configuration file which users can configure
to reduce the length of commands when typing - but that would be a runtime
configuration rather compile time.
I don't mind either way, though. Only "auto hwaccel" is something I find a bit
questionable.

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".