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 <g...@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?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
