On Sun, Dec 18, 2016 at 07:41:14PM +0100, Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit : > > How does this patchset relate to the open-ness of the API ? > > you arent saying anything about the plans, goals, intend of this (or > > i missed it or fail to associate it with the patchset) > > I am doing this to accommodate people who object to having a different > view of AVFilterLink for the public API and the internal implementation, > mostly Hendrik, Andreas and Clément. > > As for me, I am pretty happy with the current code that gives a > different view of AVFilterLink to the public than the one used for > implementation. Something like that is needed because some fields have a > type that is not itself public. > > > Iam asking as it seems like this is moving libavfilter further away > > from being "open" and centralizing control over filters more. > > I most likely misinterpret this as i just see the change in the code > > and dont know the whole story but IMO we should move toward a clean and > > stable API that everyone can use. > > That also implies to allow filters to only use public API. > > while this patchset seems to make filters use more private api by > > making more needed API private. I think a open API and external > > filter support would drive developers and users towards libavfilter > > while locking it down would likely do the opposit >
> I am not sure I understand what you mean by openness. Do you mean > applications writing their own filter and inserting it in a filter > graph? yes and ideally also installable filters like plugins but really plugins are IMHO not hard, having an API that one can access is the imortant part. Even without a true plugin API other apps or users could link in filters build from a seperate package quite easily > If so, I can tell you it is not currently possible, and has not > been since at least 2012-06-12 (9d0bfc5 lavfi: make AVFilterPad opaque > after two major bumps.). i know, but at the time all this closing down of the API happened it was said that this was temporary (not by you and i dont remember who said so and not limited to libavfilter) and now over 4 years later temporary seems to be changing into the permanent end. IMHO if you want libavfilter to be a success in the long term it needs to be a open system with clean API that anyone can use and add filters to. As it is libavfilter is limited to what ffmpeg developers want INSIDE ffmpeg. If a filter doesnt fit into that it will likely be rejected. Which makes sense if there are external filters / plugins. But if the only way to use a filter in libavfilter is through it being accepted into main ffmpeg git that just makes libavfilter unfit as a _general_ filter framework. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
