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

Tobias Rapp t.rapp at noa-archive.com
Wed Jan 31 10:08:23 EET 2018

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

> 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


More information about the ffmpeg-devel mailing list