On Wed, Mar 13, 2024 at 08:43:58PM -0300, James Almer wrote:
> On 3/13/2024 8:41 PM, Michael Niedermayer wrote:
> > On Wed, Mar 13, 2024 at 01:24:25PM +0100, Niklas Haas wrote:
> > > From: Niklas Haas <git@haasn.dev>
> > > 
> > > This filter's existing design has a number of issues:
> > > 
> > > - There is no guarantee whatsoever about the order in which frames are
> > >    pushed onto the main and ref link, due to this being entirely
> > >    dependent on the order in which downstream filters decide to request
> > >    frames from their various inputs. As such, there is absolutely no
> > >    synchronization for ref streams with dynamically changing resolutions
> > >    (see e.g. fate/h264/reinit-*).
> > > 
> > > - For some (likely historical) reason, this filter outputs its ref
> > >    stream as a second ref output, which is in principle completely
> > >    unnecessary (complex filter graph users can just duplicate the input
> > >    pin), but in practice only required to allow this filter to
> > >    "eventually" see changes to the ref stream (see first point). In
> > >    particular, this means that if the user uses the "wrong" pin, this
> > >    filter may break completely.
> > > 
> > > - The default filter activation function is fundamentally incapable of
> > >    handling filters with multiple inputs cleanly, because doing so
> > >    requires both knowledge of how these inputs should be internally
> > >    ordered, but also how to handle EOF conditions on either input (or
> > >    downstream). Both of these are best left to the filter specific
> > >    options. (See #10795 for the consequences of using the default
> > >    activate with multiple inputs).
> > > 
> > > Switching this filter to framesync fixes all three points:
> > > 
> > > - ff_framesync_activate() correctly handles multiple inputs and EOF
> > >    conditions (and is configurable with the framesync-specific options)
> > > - framesync only supports a single output, so we can (indeed must) drop
> > >    the redundant ref output stream
> > > 
> > > Update documentation, changelog and tests to correspond to the new usage
> > > pattern.
> > > 
> > > Fixes: https://trac.ffmpeg.org/ticket/10795
> > > ---
> > >   Changelog                                |   2 +
> > >   doc/filters.texi                         |  10 +-
> > >   libavfilter/vf_scale.c                   | 130 ++++++++++++-----------
> > >   tests/filtergraphs/scale2ref_keep_aspect |   3 +-
> > >   4 files changed, 76 insertions(+), 69 deletions(-)
> > 
> > this causes
> > ./ffplay --help
> > to segfault
> 
> Unrelated to this crash, but why does that command line output every single
> option from every single filter? It's several thousand printed lines.
> Shouldn't that be the output of --longhelp or similar, and leave --help to
> print some basic non filter specific options?

I think the help handling should be consistent between the tools, iam not sure
why it is not currently

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable