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 745109 - gloverlay: image is upside down
gloverlay: image is upside down
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-02-24 18:13 UTC by Xavier Claessens
Modified: 2015-03-03 20:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Screenshot (576.28 KB, image/png)
2015-02-24 18:13 UTC, Xavier Claessens

Description Xavier Claessens 2015-02-24 18:13:56 UTC
Created attachment 297799 [details]

See attached screenshot, on the left is the video playing with the overlay, on the right is the original image. I set only the "location" property on the gloverlay element.

The image is upside down, and its colors doesn't seems correct.
Comment 1 Xavier Claessens 2015-02-24 18:27:58 UTC
Can be reproduced with:

gst-launch-1.0 playbin uri=file://big_buck_bunny_720p_h264.mp4 video_sink="gloverlay location=\"gstreamer.jpeg\" ! glimagesink"
Comment 2 Xavier Claessens 2015-02-25 22:31:07 UTC
I was using the same image as in bug #745185. So it's surely a dup.

*** This bug has been marked as a duplicate of bug 745185 ***
Comment 3 Xavier Claessens 2015-03-02 16:33:22 UTC
Reopening, all jpeg files I've tested are upside down actually. It works fine with png files though.

I could still be related to bug #745185, though.
Comment 4 Nicolas Dufresne (ndufresne) 2015-03-03 20:27:06 UTC
commit eff94f929de3cb22b3dc0a24e39dcad72b369390
Author: Nicolas Dufresne <>
Date:   Tue Mar 3 15:22:38 2015 -0500

    gloverlay: Fix upside down and miss-aligned JPEG
    LibJPEG uses macroblock of 8x8 sample. In this element we use RGB and
    Y444, two 24bit formats that are stored in 32bit pixels. This mean we
    have 32x32 bytes macroblocks. For this reason, we need to allocate
    our buffer slightly larger. We also need to pass the line pointer in
    the right order, otherwise the image endup upside-down.

Take note that in case of libjpeg error, the element abort the process. I think this is why jpegdec is using long jump.