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
<mich...@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
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
