[gst-devel] [RFC] Videomixer/Imagemixer

Gergely Nagy algernon at bonehunter.rulez.org
Wed Mar 16 02:49:57 CET 2005


Hi!

As you might remember, I posted here earlier about video blending. Now
it is time to post once more. I cleaned up and simplified videomixer,
and submitted it to bugzilla (as imagemixer). It can blend to streams,
supports different blending modes, and so on.

Now, I'd like to re-implement videomixer on top of it (either as a
derived element, or as a bin, containing a bunch of stacked
imagemixers), and I'd need a little help here, idea-wise.

The first question is: do people want something that is 100% backwards
compatible with videomixer?

If yes, then the route to take is given, and I have no further questions
(well, except maybe a query whether another element, that suits my needs
better, would be accepted into gstreamer-plugins).

And now, the interesting part: ideas!

In whatever way videomixer is implemented, there must be a way to set
the properties of the different streams that get merged to the
background, on a per-stream basis (ie, blend this at 10,10, with an
opacity of 1.0, then this at 0, 200 at opacity 0.75, and so on). 

In current videomixer, this is done by having properties on the sink
pads of the mixer. It works, but I don't really like that.

Another option is to send property changes along the buffer (and then
videomixer stores those settings, and reuses them when a buffer without
xpos/ypos properties arrives). This doesn't seem clean enough either.

Yet another option is to invent an event for this. This might work
especially well when videomixer would be implemented as a bin,
containing a set of stacked imagemixer elements.

And the last option I see, is to create an API specific to videomixer to
do this.

So, the question boils down to: what would people prefer, videomixer
being derived from imagemixer, or a bin of imagemixers? And in what way
should the properties of blending be changeable?

-- 
Gergely Nagy





More information about the gstreamer-devel mailing list