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

[Paul B Mahol]

On 4/16/20, Josh Allmann <joshua.allmann at gmail.com> wrote:
> On Tue, 14 Apr 2020 at 01:53, Josh de Kock <josh at itanimul.li> wrote:
>>
>> 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 (?).
>>
>
> Thanks for the explanation Josh. For what it's worth, count me as
> being at least one API user for which out-of-tree filter capability
> would be very helpful. (And to preempt some other reactions, "use
> gstreamer" is not really helpful for us either...)
>

You must know that out of tree filters will never be supported.


> Josh
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".