[FFmpeg-devel] On libavfilter: A Summary of Issues

[Michael Niedermayer]

Hi

On Sat, Oct 06, 2012 at 07:38:36PM -0400, Derek Buitenhuis wrote:
[...]

> 
> 
> It's a Monolithic Library
> -------------------------

is it ?
all filters are registered through avfilter_register()
one could load a filter by whichever means and register it, it would
work.
A patch actually implementing such dynamic loading is welcome!
but see below also, there are other options ...


[...]

> Ideally there would be a -stable- and -long term- API and ABI for
> user written plugins. This, and I cannot stress this enough, is
> -essential-. If I write a plugin in 2012, and distro a binary under
> a commercial license, or simply just a freeware license, I should
> be able to load it in 2015. This is a something FOSS in general
> is VERY bad at all, and FFmpeg in particular. One of the reasons
> Avisynth has done so well to this way is that:
> 
> 1) Users may write closed source plugins.
> 2) They still work with AviSynth today. You can even still load 2.0
>    plugins in 2.5 and 2.6, if you are so inclined.

Now i dont agree with all the details of above paragraph but in the
general sense sure we arent disagreeing.

a stable API for libavfilter will be hard as long as we merge from
libav and try to stay compatible with them.

But skiping that problem with the libavfilter API. I would suggest
something else, write a libavfilter filter that dynamically loads
and wraps a *Synth filter.
This in one fell swoop fixes the problem of monolithsm and you also
have a stable API (if you belive *Synth is stable).


[...]
> There's No Real Scripting (No, Really)
> --------------------------------------
> 
> Don't kid ourselves. The "scripting" in libavfilter is not really scripting.
> There is no real language, or syntax, just a graph and a lackluster eval. On
> top of that you must specify it all in the cli arguments rather than script
> files, and the syntax is absolutely atrocious. To quote our own docs:
> 
>     ffmpeg -i opening.mkv -i episode.mkv -i ending.mkv -filter_complex \
>       '[0:0] [0:1] [0:2] [1:0] [1:1] [1:2] [2:0] [2:1] [2:2]
>        concat=n=3:v=1:a=2 [v] [a1] [a2]' \
>       -map '[v]' -map '[a1]' -map '[a2]' output.mkv
> 
> Yeah. No.

can you show how doing the same would look in *Synth ?


[...]
> The Public API is Overly Complex (Some Even Say Terrible)
> ---------------------------------------------------------
> 
> I'm going to compare again to Avisynth here. Its API for using it, and for
> writing plugins for it is super simple. It has a very low bar for entry.
> Get a buffer and metadata. Do stuff with it. Return a buffer, or skip. It's not
> nearly this simple in libavformat. Just look at what should be an
> extremely simple filter of no more than a few lines: vf_select.c. 443 lines.

libavfilter is designed to be efficient, fast and flexible. The API
you describe for AviSynth is clearly none of that.

There where plans to write a slow/simple API on top of the not so
simple one, but as you know this did not happen yet.

The good news though is if you write that *Synth wraper filter you get
its API and its API docs for free too. Which would make writing our
own (yet another) simple API maybe unneeded.


[...]
> It Offers Nothing Of Value; Filters or Otherwise
> ------------------------------------------------
> 
> Every filter in libavfilter is available in some other, better framework,
> and as been for a very long time. Usually in an easier-to-use capacity. Most
> of libavfilter consists of ancient mplayer plugins, or similar. They're no
> longer useful in 2012, either. Almost every single plugin in libavfilter has
> better working alternatives in other frameworks. To name some of the obvious
> ones:
> 
> - mvtools (No, exposing the motion estimation in libavcodec is not a valid
>   alternaive.)
> - Anything by tritical (TIVTC, EEDI3, etc)
> - FieldHints
> - SeparateFields
> - SelectEvery
> - AddGrain
> - QTGMC (Yes it's script. A good one. See an earlier point.)
> - DitherTools
> - Non-ancient copies of gradfun, and pals.
> - Many, many more. See Doom9.

these too would be fixed in one fell swoop with a *Synth wraper or
other filter wrapers.

once such wraper(s) are written they should be made to get enabled
seamlessly when a filter is requested that is not natively available
but in these frameworks


[...]

thanks

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121007/b41705f0/attachment.asc>