[Ffmpeg-devel] New/extended filter API discussion

[Benjamin Zores]

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.

> > #2: one must be able to enable/disable filters at runtime.
> I agree (even if this looks more like a property of single filters... In
> my idea the filter graph is statically built during an initialization
> phase, but some - or all - filters can be dynamically configured -
> allowing to transform them in "short circuits", disabling them)

Yes, the state is probably just a property for each filter.

> 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 ;-)

> I think libavformat and libavcodec already provide something similar for
> codecs and formats (at least, I have some applications in which I
> register and use my own format that is not part of libavformat...). I
> expect libavfilter to work in a similar way.

ok i'm fine with it.

> 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 ;-)

Ben

-- 
"My life, and by extension everyone else's is meaningless."
Bender, Futurama