[Bug 678384] [API] [GstVideoOverlayComposition] port to 0.11

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=678384
  GStreamer | gst-plugins-base | git

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.i.m at zen.co.uk

--- Comment #1 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-06-19 14:14:13 UTC ---
You are certainly right about the effective split into a decoding stage and a
blending stage. And there have been suggestions that the 0.10 overlay
composition API is not very 'GStreamer-y' for some reason, whatnot with
attaching metadata to video buffers instead of sending it in separate streams.

However, I'm not sure that splitting the decoding stage and the overlay is the
most desirable way here.

There is of course some appeal in just needing one generic overlay/mixer
element, and just using decoders otherwise, but I don't know how well that'll
work with extra features that we might want. If you have an overlay, the
decoder/overlay stage is tightly coupled, and can interact much more naturally
with the requirements of the downstream video renderer. In terms of
negotiation, supported features, etc. If you have the decoder split out, you
need to basically proxy that to the decoder, which feels unnatural. And a dummy
format just for the meta seems a bit weird too. I feel that the extremely
limited format-support (ARGB only) and the convenient and automatic
conversions/scaling under the hood are a strength.

I think there's also a case to be made for some kind of delta-video format, so
that e.g. dvdsubdec can output raw video without allocating a whole frame; or
ximagesrc can only output regions that changed since the last capture. I think
that needs to be more generic and flexible than an overlay format though, with
more negotiation etc. and should be handled independently.

Anyway, a lot of things *can* be done, but personally I think we should for now
continue with the approach we know works well and that doesn't require redesign
of various important bits of infrastructure and elements for no apparent (to me
anyway) gain. A generic overlay base class would be ace of course, but that
also can still be added later, no?

It would be more interesting to make sure all of this integrates nicely with
e.g. cluttersink and applications (so e.g. totem can render text/pango markup
itself via cluttersink, and textoverlay can render things in the display
resolution rather than the resolution of the video, etc.)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.