[gstreamer-bugs] [Bug 166783] [PATCH] New plugin: imagemixer

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=166783
 GStreamer | gst-plugins | Ver: HEAD CVS





------- Additional Comments From Ronald Bultje  2005-06-04 10:57 -------
Gergely, I want to use this as generic image mixer. I've looked at videomixer,
it doesn't suffice. However, this doesn't either. What I need comes closer to
this, but it isn't just yet. Here's some requirements:

* one "main" input pad, output pad - formats between those linked. Basically
your bg_pad. I want those named sink/src because when only those two are used,
it acts as a passthrough. Always pad, etc. Required. Supported formats,
preferrably anything, but at least a few of the main YUV formats (e.g. I420,
YUY2, AYUV, Y444), for the obvious performance reasons (I don't want to convert
anything from/to AYUV just for this). It'd be nice if it did RGB, too, but this
is dreaming.
* request subpicture_sink_%d pads, with a slave format, possibly depending on
the input format (because this eases coding - no color conversion in this
element). Negotiation can be delayed. For blit, go over this list, blend over
main input (as your algorhythm already does), etc. It'd be nice to allow
blending AYUV over YUY2 (for performance), but not strictly required, because I
understand this will heavily complicate the code. At the very least, I need to
be able to blend Y444 and AYUV over both of their contraries. I also need
multiple input subpicture pads, one is not necessarily enough.
* Filler event support - definitely required. I may port the
ext/pango/gsttextoverlay.c algorhythm over to here, since it's well-tested and
known to work fine.
* The subpicture_sink_%d pads need properties for alignment/positioning. I'm
currently thinking of v-align, h-align (enum; bottom, top, middle) and v-offset,
h-offset (int; default e.g. 12. This is conveniently ignored for the 'middle'
value). For this, they need to be subclasses of GstRealPad, like in videomixer.
* I'm ok with keeping the blending implementations, although I won't need them
myself... Optimizations here would rock, of course.

Here's a few of the scenario's that I'm thinking of:
* blend a (static) JPEG image over video
* blend a (static) PNG image (with alpha) over video
* blend a scaled mini-video top-left over another video
* blend a rendered pango-text over a video
* blend a DVD subtitle over a video

I'm willing to do a lot of coding for this. But it needs to just work in the
end; it'll require quit a bit of coding, as far as I can see right now. It'd be
nice to have some easy test-cases for all of this (this can't be all too hard).

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.