[FFmpeg-devel] [PATCH v3] lavfi: add new iteration API

Josh de Kock josh at itanimul.li
Tue Apr 14 11:52:31 EEST 2020


Hi,

On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote:
> Hi,
> 
> On Sat, 24 Mar 2018 at 14:40, Josh de Kock <josh at itanimul.li> wrote:
> >
> > Signed-off-by: Josh de Kock <josh at itanimul.li>
> > ---
> >  configure                |  29 +-
> >  doc/APIchanges           |   4 +
> >  doc/writing_filters.txt  |   6 +-
> >  libavfilter/allfilters.c | 823 +++++++++++++++++++++++++----------------------
> >  libavfilter/avfilter.c   |  50 +--
> >  libavfilter/avfilter.h   |  29 +-
> >  libavfilter/version.h    |   3 +
> >  7 files changed, 489 insertions(+), 455 deletions(-)
> >
> 
> This is a couple years too late, but wanted to drop a note that this
> particular API change was breaking : it made avfilter_register a
> no-op. The consequence is that it's much more difficult to maintain
> filters out-of-tree; preserving the old behavior without changes to
> user code requires a special build of ffmpeg that has the filter
> configured/compiled in. The recommended workaround of using
> avfilter_graph_alloc_filter requires more effort to wire the filter in
> explicitly. It also doesn't allow for conveniences such as using
> avfilter_graph_parse, since there doesn't seem to be a way to make
> filters accessible via avfilter_get_by_name outside of ffmpeg compile
> time.
> 
> If there is another workaround that I'm missing, please let me know,
> or if there's some deeper rationale for the decision to disable this
> feature.

This was actually an intentional change, there was some trouble with how
external codecs/filters/etc should be handled.

Since this was an unsupported use-case which was quite sensitive to ABI the
change was there to explicitly prevent people (ab)using the API like this.  It
was also to prepare for potentially a new API to implement this in a proper
fashion (but as you can see this was never completed).

I did begin working on this again a little while back but due to an unfortunate
data-loss I will have to start from scratch to continue working on it (yes, yes
'where's your backup?' I know). It's likely to be something I will be working
on in the future since I will be doing FFmpeg stuff again soon.

There is also the discussion of 'do we want this?' from a more ideological
perspective which we will have to re-discuss, maybe something like gstreamer is
more suited for the majority of the use-cases (?).

-- 
Josh


More information about the ffmpeg-devel mailing list