After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 683180 - [0.11] GstVideoOverlayComposition API changes review
[0.11] GstVideoOverlayComposition API changes review
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.11.x
Other Linux
: Normal blocker
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-09-01 22:58 UTC by Tim-Philipp Müller
Modified: 2012-09-05 09:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2012-09-01 22:58:24 UTC
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.
Comment 1 Mark Nauwelaerts 2012-09-02 09:25:21 UTC
The above case is not really covered now, and not before either in that dvbsuboverlay had to do an explicit conversion to ARGB.

But it makes a lot of sense to wonder about that and will see about adding some more _argb()/_ayuv() functions as well.
Comment 2 Mark Nauwelaerts 2012-09-05 08:18:22 UTC
Following commit should take care of this by extending the API.

Closing as such, feel free to re-open if something else/more was intended or hoped for (along with details preferably).

commit cd2e795154a617c14aa62ed3b1b5ab3476434163
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Wed Sep 5 09:46:16 2012 +0200

    videooverlaycomposition: add some _get_argb and _get_ayuv functions
    
    ... that will handle automatic conversion to indicated format.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683180
Comment 3 Tim-Philipp Müller 2012-09-05 09:49:28 UTC
Awesome, thanks a lot !