[Ffmpeg-devel] New/extended filter API discussion

Michael Niedermayer michaelni
Wed Jan 3 11:52:15 CET 2007


On Wed, Jan 03, 2007 at 10:06:39AM +0100, Luca Abeni wrote:
> Hi Robert,
> On Tue, 2007-01-02 at 21:33 +0000, Robert Swain wrote:
> > Hello,
> > 
> > I'm interested in working on some filters for use within FFmpeg. The fairly 
> > recent addition of libswscale suggested to me that, unless it was hacked in, 
> > there is some sort of filter API currently part of FFmpeg. The natural 
> > progression from the layout of the code would also lead to the conception of 
> > something like "libavfilter".
> There was some discussion about libavfilter last summer. Some previous
> threads on the mplayer G2 mailing list were cited, and someone (Rich, I
> think?) said he already had some design ideas.
> I tried to think about it for some time, and I started collecting ideas,
> but I never posted them on the mailing list (because my design ideas
> were still too confused).
> Anyway, ffmpeg is currently using libswscale by directly calling its
> sws_* functions. I believe that a good filters library should provide a
> more generic framework (offering an uniform API that allow to setup and
> use all the possible kind of video filters).
> So, I am interested in designing a library that permits to support both
> "push" and "pull" mode of operation, reducing to the minimum the number
> of copies (and the API provided by the library should support filters
> with more that one input, or more than one output).
> In my view, this library will only provide an interface, and will use
> other libraries (such as libswscale) to actually implement the filters.
> Does this make sense? 

do you mean every filter should be in its own lib? that would lead to 100
libs or so, this doesnt seem like a good idea, it rather looks like
unneccesary seperation
things like libswscale and libpostprocess should be supported through
wrapers like vf_scale.c in mplayer

> (BTW, I think the library will need to provide two
> separate APIs: one for audio and one for video... Or is it possible to
> design a filter API that can support both audio and video?)

yes 2 seperate APIs make most sense

> If there is interest, I can search for my old notes about possible
> avfilter designs / goals. But they are just random ideas, and I do not
> have big experience with filters... :) (this is another reason why I did
> not post my ideas on the mailing list)

there always is interrest in avfilter ideas ...


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070103/c0a06f1a/attachment.pgp>

More information about the ffmpeg-devel mailing list