[FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Michael Niedermayer]

On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:
> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Tue, Jan 30, 2018 at 02:24:12PM +0700, Muhammad Faiz wrote:
> >> Move REGISTER_FILTER to FILTER_TABLE in configure.
> >> Auto generate filter extern and filter table.
> >> Sort filter table, use bsearch on avfilter_get_by_name.
> >> Define next pointer at filter extern, no need to initialize
> >> next pointer at run time, so AVFilter can be set to const.
> >
> >> Make avfilter_register always return error.
> >
> > That breaks API
> 
> No. Because with current API, it is impossible to implement external filter.
> 
> 
> > Its also a step away from supporting plugins.
> > Why plugins matter ? Because having plugin
> > support is a big advantage, it allows a much wider
> > community to work on, write and maintain filters.
> >
> > With plugins, people can write filters that are
> > written in languages other than C. Or filters which
> > some developer in FFmpeg doesnt want. Or they can be
> > maintained externally by people who just do not like us.
> > Or by people who perfer a FOSS license different from
> > LGPL/GPL/BSD. Iam sure others can come up with more
> > reasons ...
> >
> > Of course avfilter_register() isnt enough for plugins
> > but it or something equivalent is needed for plugins.
> >
> > So i would prefer if avfilter_register() stays supported
> > indefinitly or in case a different system is written for
> > plugins then until that system is in place.
> 
> It just returns error and logs error message that currently external
> filter is unsupported. If someone wants to implement support for
> external filter, it can be easily added later using separate
> list/table.

Iam not sure "easily" is true

We started out with a fully public API that allowed external filters.
and little by little its removed or made private.
each individual change may be easy to undo but as a whole moving
libavfilter back to having a public API is not that easy anymore

IIRC the arguments to make things private where that people wanted to
improve the API. But from the idea and impression of a plan like:
1. make it private
2. design and implement better API
3. make it public again

Somehow now people lost sight and interrest in 3. and even 2. is becoming
less interresting. But the problem is really without 2 + 3 actually happening
doing 1 seems like not a good idea at all.

To me it seems even mentioning external filters and public API makes some
people angry.
But really that has to be the goal at some point. To again have a public API

Is the plan to have 2 seperrate lists at that point ?
one static for internal filters and one dynamic for externally registered
ones ?

Iam not objecting to the patch, theres nothing i have that uses the call
but iam a bit concerned about interrest_to_remove > interrest_in_public_api

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180130/b51d1828/attachment.sig>