[FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field

[Alexander Strasser]

On 2024-10-15 15:09 +0200, Anton Khirnov wrote:
> Quoting James Almer (2024-10-15 14:54:08)
> > On 10/15/2024 6:57 AM, Anton Khirnov wrote:
> > > avfilter_process_command() may or may not return ENOSYS whether that
> > > flag is set or not, so I don't see what exactly would it be useful for.
> >
> > I see, although I wouldn't expect ENOSYS for any other case than
> > "unsupported". If a command fails, imo it would be EINVAL, or maybe ENOMEM.
>
> Correct, but
> * some commands work on all filters; for now it's just "ping", but we
>   can add more in the future;
> * the "enable" command works on all filters flagged with
>   AVFILTER_FLAG_SUPPORT_TIMELINE; again, we may add more such
>   "semi-generic" commands in the future;
> * filters that do implement the process_command() callback will still
>   return ENOSYS when you send them a command they do not support.
>
> So checking for the existence of process_command() does not really tell
> you anything specific, and the same would hold for the hypothetical flag
> that would replace it.
>
> >
> > > Same holds for printing the capability in fftools - just what is the
> > > user expected to do with that information?
> >
> > Know they can use the send command interrupt for a given filter without
> > having it unconditionally fail, i guess. But for that matter, is the
> > list of supported commands available anywhere for the user? Is there an
> > API to query them, or is it expected to be only in the documentation?
> > If there's no API, then maybe printing this is pointless.
>
> There is no such API, which I agree would be useful - but if it did
> exist we would again not need the flag.

For me that flag is more about if some filter brings commands of its own.

Generic stuff that we will add should not be indicated with the C flag.
Though adding more flags for the generic stuff like we have with T now
should be fine for some time to come before it gets unwieldy.

Listing and querying of filter caps has much room for improvement, but
as long as no one has particular interest in doing that,  at least I
don't see it as very important right now.


  Alexander