[gst-devel] [RFC] Videomixer/Imagemixer
ensonic at hora-obscura.de
Mon Mar 21 02:13:01 CET 2005
Thats what IPPLib (Interl Performance Primitives) provides:
A occludes B
A within B. A acts as a matte
for B. A shows only where B
αA*A*(1-αB) αA *(1-αB)
A outside B. NOT-B acts as a
matte for A. A shows only
where B is not visible.
Combination of (A IN B) and
(B OUT A). B is both
back-ground and matte for A.
Combination of (A OUT B)
and (B OUT A). A and B
mutually exclude each other.
αA *A + αB*B αA + αB
Blend without precedence
> 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?
More information about the gstreamer-devel