[gst-devel] [RFC] Videomixer/Imagemixer

[Stefan Kost]

Hi Gergely,

Thats what IPPLib (Interl Performance Primitives) provides:
OVER
  αA*A+(1-αA)*αB*B αA+(1-αA)*αB
  A occludes B
IN
  αA*A*αB αA*αB
  A within B. A acts as a matte
  for B. A shows only where B
  is visible.
OUT
  α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.
ATOP
  αA*A*αB+(1-αA)*αB*B αA*αB+(1-αA)*αB
  Combination of (A IN B) and
  (B OUT A). B is both
  back-ground and matte for A.
XOR
  αA*A*(1-αB)+(1-αA)*αB*B αA*(1-αB)+(1-αA)*αB
  Combination of (A OUT B)
  and (B OUT A). A and B
  mutually exclude each other.
PLUS
  αA *A + αB*B αA + αB
  Blend without precedence

> 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?
>