[FFmpeg-devel] [PATCH 2/2] avfilter/vf_scale2ref: switch to FFFrameSync
Michael Niedermayer
michael at niedermayer.cc
Thu Mar 14 02:00:37 EET 2024
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240314/6f9f0a1a/attachment.sig>
More information about the ffmpeg-devel
mailing list