[Bug 747297] gl: live rpicamsrc/omxh264dec/glimagesink pipeline fails

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=747297

--- Comment #22 from Julien Isorce <julien.isorce at gmail.com> ---
(In reply to Florent Thiéry from comment #21)
> Getting back at the precise issue this ticket is about, GPU memory-wise, for
> 1080p:
> - rpicamsrc takes 43 MB
> - omxh264dec takes 28 MB
> - omxh264enc takes 23 MB
> - glimagesink takes 59 MB for I420, 46 MB for RGBA, 61 MB for YUY2
> 
> Which means that for philippe's pipeline, we have 130 MB of required GPU
> memory, hence over 128 MB. It's possible to avoid it by raising the amount
> of gpu_mem to e.g. 256.


Great analysis.
Worth to mention that for RGBA, 1920*1080*4 is around 8 MB. So if glimagesink
uses 1 FBO and a pool a size 2, it should be around 24MB. So it sounds to me
that glimagesink(bin) is using 2 FBO and more textures and or/eglimage.

At least  filesrc ! qtdemux ! h264parse ! omxh264dec ! glimagesink  should work
for 1080p and 128 MB.

I also think rpicamsrc ! omxh264enc should work for 1080p and 128 MB of gpu
mem.

> 
> Before closing this issue, isn't it possible to detect that the problem is
> in fact a memory error "gst_gl_buffer_pool_alloc Could not create GL Memory"
> and not "gst_gl_context_set_error: GL framebuffer status incomplete", which
> is less explanatory ?

Good idea!. Maybe we could catch the gl error "GL_OUT_OF_MEMORY" with
glGetError. At least in Mesa it seems to be set, see
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/fbobject.c#n2636
(search for GL_OUT_OF_MEMORY)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.