[Ffmpeg-devel] New/extended filter API discussion

Robert Swain robert.swain
Thu Jan 4 16:12:21 CET 2007


Benjamin Zores wrote:
> On 1/4/07, Luca Abeni <lucabe72 at email.it> wrote:
>> Hi Benjamin (and all),
>> On Thu, 2007-01-04 at 12:24 +0100, Benjamin Zores wrote:
>> [...]
>> > Here are a few more thoughts and concerns about the libavfilter design.
>> >
>> I agree, but in my opinion we should not limit libavfilter to "filter
>> chains", but we should allow "filter graphs" (meaning that a filter can
>> have more than 1 input, and more than 1 output).
> I hadn't said we should limit to chain, it's the bare minimum 
> requirement imho.
> The filter graphs approach is much better, comparable to GStreamer or
> DirectShow filters.

Indeed. I like the filter graph concept.


>> In my original idea, I considered the filter graph as static. But maybe
>> I overlooked something. Why would this dynamic append / prepend be
>> needed? I do not know mplayer, but couldn't post-proc, deinterlacing,
>> OSD, etc be supported by statically inserting the (disabled) filters at
>> program startup, and dynamically enabling them when needed?
> Let's suppose some video app (Freevo, MythTV, whatever ... that is a
> frontend to various player and so ffmpeg) and that will call the
> player by itself (i.e. it is not done by end user). User will then be
> able to talk with the frontend which will then talk with the player
> and so, might add new filters once the playback already has started.
> Not considering this approach would result in the frontend having to
> chain as much filters as possible (the one that might be called by
> user) and disable them all by default until user ask for implicit
> enable of them, which isn't optimal.
> Dynamically adding a new filter isn't done that often and thus, it
> should be just a matter of regenerating the static graph i guess (but
> then we can call it dynamic graph ;-)

A good point.


>> As you can see from this email my ideas are still confused, but I am
>> trying to formalize them and write a more clear and concrete proposal
>> that I will send in the next days.
> waiting for them ;-)

Me too and I'm taking down notes. It seems like you've made some good progress 
with your design.

Thanks to everyone for their input so far. :)

More information about the ffmpeg-devel mailing list