[Bug 683180] New: [0.11] GstVideoOverlayComposition API changes review

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=683180
  GStreamer | gst-plugins-base | 0.11.x

           Summary: [0.11] GstVideoOverlayComposition API changes review
    Classification: Platform
           Product: GStreamer
           Version: 0.11.x
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: t.i.m at zen.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Note to self to clarify some potential issues with Mark's recent API changes.
Haven't looked at them in detail yet, but some of the _raw stuff doesn't look
right.

The goal of the original API was to make things easy for the overlay image
producer and the overlay image consumer and handle conversion/scaling
automagically etc. internally if the consumer can't do that itself.

There are two main use cases:

  a) producer creates overlay image and calls
      _composition_blend() utility function

  b) producer creates overlay image and
      consumer (e.g. gstreamer-vaapi) calls
      _get_argb()/_get_raw() to get to the
      overlay images and do the blending


In particular I'm wondering how the following case works now:

 - dvbsuboverlay creates an AYUV overlay image

 - gstreamer-vaapi wants an ARGB overlay image
   and does _get_raw().

Is that covered now ?

I'm not very fond of the _raw() API naming, I would like explicit
_argb()/_ayuv() functions as well, which would do automatic conversions +
caching. _raw() would then be for overlay consumers that can handle multiple
formats.

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