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

[Lynne]

Apr 14, 2020, 09:52 by josh at itanimul.li:

> 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 (?).
>

Nope, we definitely don't want to do this. NAK. Have you seen the trashfire of random
outdated proprietary (and free) plugins for gstreamer?
Removing the option of abusing the API like that was also somewhat motivated by
preventing that scenario from happening, at the cost of making fuzzing take longer.
This was answered in the original discussion, there's no reason to bring this up now,
nothing has changed.