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

[wm4]

On Wed, 31 Jan 2018 09:08:23 +0100
Tobias Rapp <t.rapp at noa-archive.com> wrote:

> On 30.01.2018 20:37, Michael Niedermayer wrote:
> > 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:  
> >>> 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  
> 
> I agree that having (again) a public filter API would be good. This 
> would give users the freedom to implement their own special-purpose 
> filters (see the "dumpwave" discussion).

Someone needs to design and write it.

Whether we have external filters is completely orthogonal to this
change. They were not possible before, because not enough API for
implementing them is public. They can be possible in the future, but
then registering them would need a different API anyway (one that
doesn't use global mutable state, but uses some sort of context
instead).