Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > APIs in FFmpeg will change as long as the project is alive. > > new developers join, older ones leave, peoples goals and oppinions > change. The libavfilter API is based on the lessons learned from > previous projects and frameworks, in that way this codebase has a quite > long timeline and many experienced developers from multiple other > free software projects upon whos shoulders this rests in some sense. > > If we only make the API public once the ultimate global optimum is > reached we will never do so.
I was not referring to a hypothetical global optimum, but right now we are nowhere near a local optimum: you have certainly noticed that since I pushed the 45k patch making filter_frame non-recursive, I had to fix several bugs. Well, there are still a few of them lurking, and then we need to reap the benefits of the design change. Two days ago, I outlined my plans for lavfi: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204686.html I say: first do all these points, because any of these might require a surprise rework of some internal API. Then (in parallel when relevant), adapt ffmpeg.c to work with the cleaned-up API of lavfi and fix the scheduling. Then wait a year, to be sure. Then start working on external filters. Does it seem unreasonable? I can assure you, when the last points in the plan will be done, I will be so fed up with it that I will easily leave the API alone for a year. There are plenty of other parts of the code I would like to work on. For reference, I am halfway through the second item in the plan. Probably more than halfway, actually. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
