[FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161219/c13fa61c/attachment.sig>