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 728439 - glimagesink: does not takes in account strides
glimagesink: does not takes in account strides
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal blocker
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-17 16:40 UTC by Andoni Morales
Modified: 2014-05-01 05:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Andoni Morales 2014-04-17 16:40:21 UTC 
With big_buck_bunny_480p_h264.mov vtdec produces buffers with the following properties:
n_planes = 1
stride = 1760
height = 480
size = 844800

osxvideosink displays the image correctly, but glimage sink produces the following errors:

gstglmemory.c:638:_gl_mem_copy_thread: Cannot copy between textures with backing data of differentsizes. input 819840 output 818880

Can be reproduced with:
gst-launch-1.0 filesrc location=/Users/fluendo/Downloads/big_buck_bunny_480p_h264.mov ! qtdemux ! vtdec ! glimagesink
Comment 1 Matthew Waters (ystreet00) 2014-04-27 13:30:27 UTC 
cross-ref https://bugzilla.gnome.org/show_bug.cgi?id=728815
Comment 2 Matthew Waters (ystreet00) 2014-05-01 04:13:24 UTC 
Should be fixed by:

commit 598a79a5e21a03aa59a14e0c5976cf6458b1b373
Author: Matthew Waters <ystreet00@gmail.com>
Date:   Thu May 1 13:57:16 2014 +1000

    gl/mem: implement texture copying between formats with strides properly
    
    Previously, we used the width to determine the amount of data to be
    copied using pbos.  This, makes it allocate enough data for the
    the strides as well.