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 451908 - [ffmpegcolorspace] regression: doesn't accept GST_VIDEO_CAPS_RGBA
[ffmpegcolorspace] regression: doesn't accept GST_VIDEO_CAPS_RGBA
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
: 0.10.14
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-06-28 14:56 UTC by Tim-Philipp Müller
Modified: 2007-07-06 11:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot of the converted output. (9.29 KB, image/png)
2007-06-29 16:03 UTC, Jan Schmidt
Details

Description Tim-Philipp Müller 2007-06-28 14:56:35 UTC
ffmpegcolorspace doesn't accept certain RGBA formats any longer, most notably those output by pngdec and gdkpixbufdec.

Take a PNG with an alpha channel (e.g. the following on ubuntu feisty):

 gst-launch-0.10 filesrc location=/usr/share/example-content/logo-Ubuntu.png ! pngdec ! ffmpegcolorspace ! fakesink

errors out with not-negotiated.

This worked fine with core/base 0.10.12 + -good 0.10.5 (ie. versions in feisty), although strangely this also doesn't work with those versions:

   gst-launch-0.10 videotestsrc ! 'video/x-raw-rgb, bpp=(int)32, depth=(int)32, endianness=(int)4321, red_mask=(int)-16777216, green_mask=(int)16711680, blue_mask=(int)65280, alpha_mask=(int)255' ! ffmpegcolorspace ! fakesink
Comment 1 Jan Schmidt 2007-06-29 15:39:54 UTC
There was exactly one gstffmpegcolorspace change between 0.10.12 and 0.10.13:

        * gst/ffmpegcolorspace/gstffmpegcolorspace.c:
        (gst_ffmpegcsp_transform):
        * gst/videoscale/gstvideoscale.c: (gst_video_scale_transform):
        Basetransform copied the metadata for us.

I don't think that's what did it... Similarly, there doesn't look to be anything suspicious in pngdec's changelog. 

From the log, I suspect the problem is actually triggered by the acceptcaps changes that happened in core...
Comment 2 Jan Schmidt 2007-06-29 15:59:59 UTC
So, the problem is triggered by the acceptcaps changes in core, but caused by a mismatch in the pad caps pngdec uses for RGBA versus ffmpegcolorspace:

/pipeline0/pngdec0.src: caps = video/x-raw-rgb, width=(int)1501, height=(int)391, bpp=(int)32, framerate=(fraction)0/1, depth=(int)32, endianness=(int)4321, red_mask=(int)-16777216, green_mask=(int)16711680, blue_mask=(int)65280, alpha_mask=(int)255

This is "RGBA"

ffmpegcolorspace has:

      video/x-raw-rgb
                  width: [ 1, 2147483647 ]
                 height: [ 1, 2147483647 ]
              framerate: [ 0/1, 2147483647/1 ]
                    bpp: 32
                  depth: 32
               red_mask: 65280
             green_mask: 16711680
              blue_mask: -16777216
             alpha_mask: 255
             endianness: 4321

which is "BGRA".

If I hack ffmpegcolorspace to have the same masks as pngdec, it produces the attached image as output which is obviously not correct but seems to have the right colours, implying that the pngdec masks are right, and ffmpegcolorspace's are currently not, we just never noticed because it was accepting the caps anyway?
Comment 3 Jan Schmidt 2007-06-29 16:03:51 UTC
Created attachment 90884 [details]
screenshot of the converted output.

This screenshot is made using ximagesink, but xvimagesink and a YUV conversion produces the same result.
Comment 4 Jan Schmidt 2007-06-29 17:00:39 UTC
With the same hack, gdkpixbufdec produces output with R & B swapped for that file.

Something is wrong with our RGBA caps descriptions, but I can't remember how they're supposed to work, so I don't know what.
Comment 5 Wim Taymans 2007-07-05 10:11:00 UTC
ffmpeg has this:

PIX_FMT_RGBA32: layout in memory on LE : B G R A 
PIX_FMT_RGBA32: layout in memory on BE : A R G B

PIX_FMT_BGRA32: layout in memory on LE:  A R G B 
PIX_FMT_BGRA32: layout in memory on BE:  B G R A

there is no format describing R G B A on any architecture, pngdec cannot be linked. 
Comment 6 Jan Schmidt 2007-07-06 11:43:59 UTC
Fixed in CVS:

2007-07-06  Jan Schmidt  <thaytan@mad.scientist.com>

        * gst/ffmpegcolorspace/avcodec.h:
        * gst/ffmpegcolorspace/gstffmpegcodecmap.c:
        (gst_ffmpeg_pixfmt_to_caps), (gst_ffmpeg_caps_to_pixfmt),
        (gst_ffmpegcsp_avpicture_fill):
        * gst/ffmpegcolorspace/imgconvert.c: (img_convert),
        (img_get_alpha_info):
        Add 2 new pixel formats - ABGR32 and ARGB32, which are reflections
        of the existing BGRA32 and RGBA32 formats with the alpha at the other
        end of the word. Partially fixes #451908

and the sister commit in -good:

2007-07-06  Jan Schmidt  <thaytan@mad.scientist.com>

        * ext/libpng/gstpngdec.c: (gst_pngdec_caps_create_and_set):
        Remove endianness-flipping hack that seems to have been required
        only because of a bug in ffmpegcolorspace.
        Partially Fixes: #451908