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

[Nicolas George]

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.

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.

More to the point: is this discussion meant to be an objection to the
patch itself?

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161219/42eff640/attachment.sig>