On Mon, Dec 19, 2016 at 05:39:53PM +0100, Nicolas George wrote: > Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit : > > Changing from AVFilterFrame to AVFrame could have been done using > > a new set of API functions and deprecating the old. > > > > Things like that were not done as it wasnt needed without a public > > API, i dont think theres anything we really needed to do that we > > would not have been able to with a public API if that was the > > constraint under which we worked. > > Most projects work under the constraint of a stable public API. > > > Theres a big difference between the "wish to redesign" and the "need to > > redesign" > > more so the "wish to redesign" might not end before the loss of > > interrest in the code as such, And the next developer might have a new > > and different "wish to redesign". > > With this you might never reach the point of having a stable API no > > matter what man power you have as with more man might come more > > wishes. > > All this is certainly true, but it requires manpower. We do not have it; > mostly, we only have me.
> > > I really think we should draw a line at some point and commit ourselfs > > to some stable API. > > I agree, but it should be done only when the API and design are good > enough. I do not think they are right now. A clue to prove that: when > something breaks around libavfilter in ffmpeg.c, you have to ask me, > showing that the code is complex, more than it should be and I think I > can make it simpler. I would very much be in favor of this though i wonder what mistake we did to end here, the original design was intended to be very simple ... > > And even larger projects with plenty of manpower and API stability, from > time to time, decide to start fresh. > > > But theres another issue we should keep in mind. I think if someone > > forked libavfilter, documented it well, added a plugin interface and > > commited himself to a stable API and had a bit PR success iam not sure > > which side would win. > > That would be great! That would mean a version of libavfilter with good > documentation, stable API and a plugin interface. We could merge it and > I could start working on something else entirely, possibly asynchronous > I/O. > > But before that would happen, I would expect the people interested to > make contact, on the mailing-list or with me personally, and we could > discuss how to do it together, without forking. That would be, of > course, even better. > > Alas, the state of affairs now is that I cannot even find someone to > discuss fine points of API evolution. my interrest is having a stable public API and a plugin interface and iam interrested discussing that. Iam also interrested in discussing clearly defined problems, reproducable issues and solutions. about fine details i dont really care and your libavfilter patches are sometimes complex making it not a trivial quick thing to discuss them > > More to the point: is this discussion meant to be an objection to the > patch itself? its not an objection to the patch > > Right now, because a not of necessary structures and functions are > internal, plugins are not possible, so this patch is not making things > any worse. I am all in favour of allowing plugins eventually, but I > think the only reasonable course of action is: first a good API, then > make it stable, then make it public. You complain that noone else is working on libavfilter how many people know what _NEEDS_ to be done to make the API good enough for a first public and stable API ? while i have a long todo and maybe no time for this, as it is i cant even work on making libavfilter public+stable. Its not a technical issue, its one of peoples requirements on what they require to be changed first. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
