[FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
george at nsup.org
Mon Dec 19 10:25:14 EET 2016
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
> 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
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
Removing the recursiveness in request_frame() (last year's patch
series), threading, the move to real frames, etc., would have been
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel