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

Don Moir donmoir at comcast.net
Fri Oct 19 01:10:52 CEST 2012

> Sorry late joining to the party...
>> Is it supposed to be an extensible filtering framework that 3rd
>> party devs write filters for and use for a lot of video processing,
>> like Avisynth and VapourSynth? Is it supposed to be something to
>> mainly be used as a C API from others' applications? Just ffmpeg.c?
>> Whats the goal and direction of libavfilter as library? I think
>> it could really benefit from some sort of public statement, declaration
>> or documentation of this.
> http://wiki.multimedia.cx/index.php?title=Libavfilter was what I
> originally read that described its purpose.
> "FFmpeg's already well-known libavcodec module has become the de facto
> standard library for video decoding and encoding in free software
> projects. Unfortunately, no similar standard library has surfaced for
> audio/video filtering and otherwise working with audio/video stream
> once it has been decoded. Various multimedia projects (such as
> MPlayer, Xine, GStreamer, VirtualDub, etc.) have implemented their own
> filter systems to various degrees of success. What is needed is a high
> quality audio and video filter API - efficient, flexible enough to
> meet all the requirements which have led various projects to invent
> their own filter system, and yet easy to use or develop new filters
> with. This proposal is to implement a high quality video API and
> filter library for FFmpeg, where it can be easily used by other
> multimedia-related software projects."
> It appears from that page that the goal is to be some type of
> centralized filter repository/highly functional filter system?
> If the goal is to provide filters that programs like mplayer/VLC/FFmpeg can use,
> that would seem to be a different target than a full fledged
> filter/scripting system, like
> AviSynth is.
> Is the goal to be as flexible/user friendly as avisynth, or to provide
> filters for other programs?
> I guess the OP is saying that if you try and become like AviSynth, it
> could speed adoption,
> since AviSynth does some "community friendly" things like easier
> scripting (though still basically
> creating a filtergraph) and simplified development.
> At the same time, FFmpeg itself would benefit from some AviSynth like
> abilities, for instance, I
> have no idea how to do the equivalent of something like following in
> one command in FFmpeg:
> a = movie('input', :from => 10:00, :to => 10:30)
> b = movie('input2')
> c = fade_in(a, b, :seconds => 10, :overlap => 5)
> d = add_overlay(c, :from => 1:00 => to: 200)

Whenever an email comes across about libavfilter I think why would anyone use that. I guess its more of a generalized approach and 
there might actually be some useful things in there.

>From my perspective and with the above example these kind of things are better done in the app and via hardware. For example, an 
alpha value is just about as easy and as fast as it can be via the hardware. And of course many visual effects are better done in 
the hardware but maybe not an option for some.

overlays are just an extension of the app.

A while back I needed audio waveform data and just about the same time a filter was being written for libavfilter to do this. For me 
I needed finer control over it and to also create peak data files so next time it would much faster so again just rolled my own.

Just my 2 cents and really I do think about it from time to time. 

More information about the ffmpeg-devel mailing list