GNOME Bugzilla – Bug 728815
GstGLMemory mix stride and width
Last modified: 2014-05-02 13:10:30 UTC
I have not investigated too much but worth to open a bug before to forget. So in gst_gl_memory_setup_buffer we use GST_VIDEO_INFO_PLANE_STRIDE (info, i) as the stride param of gst_gl_memory_alloc whereas in gstglupload or gstglconvert we use the width. And we use this param to compute the maxsize http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglmemory.c#n485 And maxsize is used for g_malloc http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglmemory.c#n896 So when doing gst-launch videotestrc ! video/x-raw, format=RGB ! glimagesink 2 textures are allocated with their glmem maxsize set to 960 (stride), and the texture used for the FBO has its glmem maxsize set to 360. I tried to replace GST_VIDEO_INFO_PLANE_STRIDE (info, i) by _get_plane_width (info, i) here http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglmemory.c#n1087 and the above pipeline still works. Another thing is that the texture used for the FBO also has its glmem that does a g_malloc, is it really useful ? maybe for download ? but worth to allocate only if we actually do a download.
Yea, needs to be looked at before 1.4 As for download, yes that could be smarter but currently it just works (TM) :).
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.
Can this be closed then?