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

[Tobias Rapp]

On 31.01.2018 10:03, wm4 wrote:
> 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).

Thanks for clarifying, so don't count my comment as an disagreement on 
the patch.

Regards,
Tobias