On Fri, 23 Dec 2016 21:02:09 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Fri, Dec 23, 2016 at 06:51:38PM +0100, Nicolas George wrote: > > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > > > libavfilter had a public API that allowed filters to be implemented > > > these changes move it farther away from it > > > I do care about having some public API that allows filters > > > to be implemented. > > > You pointed out that you work alone and people dont review your lavfi > > > patches. I think if you integrate others goals more people would > > > > > > For example your plans can stay the same but include the declared > > > goal of making the API public once they are all done. And suddenly > > > i would be interrested in this. Of course it doesnt make days > > > have more hours or my todo shorter but pushing the public API away > > > makes me loose interrest for sure. > > > > > > Other people might have other ideas and goals too, which they want > > > lavfi to achieve. > > > If more things can be integrated more people might contribute ... > > > > You misunderstood: I am not excluding an API to allow external filters, > > I am saying that it is too soon to think about it. The way filters must > > be written is in a complete rework. Once it is stabilized, tested > > extensively, we know it will not changing again, then we can make parts > > of it public to allow external filters. > > > > Anything else would be a compatibility nightmare. Do you not agree? > > APIs in FFmpeg will change as long as the project is alive. > A public API for something as complicated and far-reaching as external filters or codecs should be tiny and concise, not expose the current internal API-vomit we have to the world. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
