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

[GStreamer (bugzilla.gnome.org)]

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

           Summary: [API] [GstVideoOverlayComposition] port to 0.11
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Subject says it all, and pretty much needed if more elements are to use it.
This will presumably involve GstMeta (also according to IRC):
----
<__tim>       mnauw, for GstVideoOverlayComposition I think the idea was to
somehow make 
a meta for it
<mnauw>       yeah, that seems like a pretty "straightforward" map
<mnauw>       that is, stick something on a buffer -> put it in meta
<__tim>       mnauw, however, it kind of serves two purposes: (1) as a
container for overlay info, to attach to buffers and let some other component
do the blending, and (2) just helper/convenience API for elemen
ts that want to blend ARGB data onto raw pixels
<__tim>       so the easiest would imho be to just make a meta with one of
those objects in it, but perhaps there's something more clever
<__tim>       there's also the issue of a more general-purpose video mixing
kind of thing, but IMHO we should keep that generala thing separate from this
mostly subtitle-targetted API
<mnauw>       makes sense
<__tim>       mnauw, there's some possibly related interesting stuff there that
should ideally be queryable, like if the downstream component can handle
overlays (textoverlay could query that and then decide whether to blend or just
attach), whether it supports global alpha, whether it supports/needs
premultiplied alpha or not; in future perhaps whether it can do text/pango
markup rendering directly; an allocator for the pixels might be nice etc. :)
----

Note also that if overlay elements convert to using GstVideoOverlayComposition,
they become pretty much separated into a "decoder" phase, followed by an
overlay phase.  The latter phase is then pretty generic, both in the execution
(using overlay composition helper code) and in the algorithm on what data to
overlay onto what (based on timestamp comparison).

So one school of thought here might lead to introducing an overlay baseclass
(see e.g. suggested in bug #614612), which is re-use through inheritance.

Alternatively, one might go for re-use through composition (sort-of) and
introduce a separate caps type (or so) to carry basically empty buffers (or so)
with attached overlay composition data.  This could then be handed to a generic
overlay element that performs appropriate timestamp comparison and then either
performs the actual overlaying or attaches the overlay composition data to a
real video buffer (or sort of real in video/x-surface like case).  Perhaps
supporting 'relative' coordinates or so (in 0 ... 1.0 scale) is also useful in
this case.

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