GNOME Bugzilla – Bug 734223
glimagesink: last-sample property useless for planar YUV formats
Last modified: 2018-11-03 11:30:59 UTC
W/GStreamer+default(10996): 0:00:05.788143615 0x608b7af0 gstglutils.c:522:gst_gl_context_set_error Cannot download GL luminance/luminance alpha textures This makes the convert-sample and last-sample properties on playbin useless with planar YUV formats. Can we somehow keep around the original data until it is changed in GL and use that for mapping instead of downloading from GL?
IIUC, what glimagesink receives as the input buffer is the buffer that is stored in the last-sample property. The uploaded RGBA texture is a separate GstBuffer stored internal to glimagesink. If you already have GLMemory (or EGL images) being passed then you are going to have to download no matter what you try and do with glimagesink. What's upstream of glimagesink?
avdec_h264 :) I worked around this by inserting a tee in front of glimagesink (as tee will drop the ALLOCATION query). The problem seems to be that the GL bufferpool is used upstream.
Hmm, so planar YUV buffers should be passed in avdec_h264 ! glimagesink which should not have the NEED_DOWNLOAD memory flag set which should just return the data pointer used to upload.
Need to figure out which part of that breaks :)
I think a simple solution is to make GlMemory a bit more lazy, and not upload right away on unmap() calls.
It's already as lazy as it could be... It doesn't upload on unmap... It only sets a flag that determines if the next map call requires an upload.
It seems as thought the convert-sample machinery ends up making a copy of the memory. As we only copy the GPU side memory, the original data is lost for the memory used to download. Looking at basesrc, it makes the buffer writable to mark a discontinuity. (gdb) bt
+ Trace 234051
Thread 1 (Thread 0x7ffff7fc0700 (LWP 20764))
Yay, so we should probably share the other memory somehow too? And ideally not copy but share :)
Created attachment 285348 [details] convert_frame test program This is a test program to reproduce the issue with.
Possibly half fixed by commit 08b1d27e14e28ed028d73de1e5f7ec2e9c0a0d71 Author: Matthew Waters <matthew@centricular.com> Date: Wed Feb 25 00:00:48 2015 +1100 glmemory: allow sharing between buffers There was no real reason why the flag was set. We should be able to handle it. Fixes last-sample handling on gl sinks
Created attachment 303923 [details] [review] glimagesink: set the caps features to sysmem for last-sample So here's a patch that fixes the issue. My question about it is if one, it's ok to mangle with the caps on the sample like this to allow videoconvert to negotiate with appsrc in the convert-sample machinery. The second question is whether the caps should also include the original GLMemory caps features so that applications can still detect GL textures with caps features.
Any update on this ?
No
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/129.