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

[Michael Niedermayer]

On Wed, Apr 15, 2020 at 03:00:32PM -0700, Josh Allmann 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...)

I also would be in favor of some out of tree filter support.
Let me explain why
Some real ideas i was toying around:
Some video source to simulate N body gravitational interaction and
another idea was one to simulate the spread of an epidemic amongth
points moving around ...

Iam not sure these things would belong in-tree
And as things are, if anyone works on anything like such filters which
are not generic multimedia filters. They run the risk to get their work
rejected "doesnt belong in FFmpeg" and then that has no reasonable place
to go.
For me at least that risk has been a factor in moving some random ideas about
writing one or another filter down my todo and rather work on something else

With "out of tree filter" support one would know that filters which are 
outside the scope of multimedia would have a place to go.
I think its also in the spirit of open source ...

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200416/37c61169/attachment.sig>