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

[Michael Niedermayer]

On Mon, Dec 19, 2016 at 09:25:14AM +0100, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > i know, but at the time all this closing down of the API happened it
> > was said that this was temporary (not by you and i dont remember who
> > said so and not limited to libavfilter) and now over 4 years later
> > temporary seems to be changing into the permanent end.
> > 
> > IMHO if you want libavfilter to be a success in the long term it needs
> > to be a open system with clean API that anyone can use and add filters
> > to.
> > 
> > As it is libavfilter is limited to what ffmpeg developers want INSIDE
> > ffmpeg. If a filter doesnt fit into that it will likely be rejected.
> > Which makes sense if there are external filters / plugins. But if the
> > only way to use a filter in libavfilter is through it being accepted
> > into main ffmpeg git that just makes libavfilter unfit as a _general_
> > filter framework.
> 
> Well, all you write here is entirely true. Making it possible to use
> application-provided and plugin-provided filters in libavfilter is a
> worthy goal.
> 
> But you have to consider the other side of the coin: all the genericness
> of libavfilter requires a very complex API for filters, and keeping this
> API stable would put a tremendous constraint on its evolution.
> 

> Just consider Marton's recent patch to make support of unknown channel
> layouts the default. He could do it because he could review all the
> existing filters, check they were ready and make the small adjustments
> necessary. If there were foreign filters to accommodate, it would have
> been impossible.

changing a default is not a needed change, and this one was even
rolled back and forth on the ML a while


> 
> Removing the recursiveness in request_frame() (last year's patch
> series), threading, the move to real frames, etc., would have been
> equally impossible.

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.


> 
> The short of it is that libavfilter is still too young to allow that.
> The age must not be measured in years, but in manpower.

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.

I really think we should draw a line at some point and commit ourselfs
to some stable API.

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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/34cba926/attachment.sig>