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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Florent Thiéry <florent.thiery at ubicast.eu> ---
(In reply to Julien Isorce from comment #14)
> That's huge!  We should avoid using useless Frame Buffer Objects in the
> glimagesink bin: gluploadelement ! glcolorconvert ! glimagesinkelement
> (Indeed a FBO by itself uses memory in addition to the pool of
> textures/eglimages)

After checking, the large memory amount does not seem to be allocated by gstgl
alone (at least not in 1.6.2), because with a small amount of reserved memory
(gpu_mem=64) i can display upto 2049x1000 YUY2 (glvideoconvert used) or
10000x1000 RGBA (glvideoconvert apparently in passthrough).

GST_DEBUG=glmemory*:5,3 gst-launch-1.0 videotestsrc pattern=2 num-buffers=1 !
video/x-raw\,\ format\=\(string\)YUY2\,\ width\=\(int\)2049\,\
height\=\(int\)1000 ! glimagesink
0:00:00.557045000   327   0xb32f20 DEBUG               glmemory
gstglmemory.c:669:_gl_mem_init: new GL texture context:<glcontextegl0>
memory:0xb29670 format:1 dimensions:2049x1000 stride:4100 size:4100000
0:00:00.855408000   327   0xaff780 FIXME               glshader
gstglshader.c:543:gst_gl_shader_compile: vertex shader info log:
0:00:00.879219000   327   0xaff780 ERROR                default
gstglutils.c:79:gst_gl_context_check_framebuffer_status:
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT
0:00:00.881039000   327   0xaff780 WARN                 default
gstglutils.c:426:gst_gl_context_set_error: GL framebuffer status incomplete
0:00:00.882494000   327   0xb32f20 WARN        glconvertelement
gstglcolorconvertelement.c:219:gst_gl_color_convert_element_prepare_output_buffer:<glcolorconvertelement0>
error: Failed to convert video buffer

I can make it crash also as RGBA, but the error is not the same:

[root at rpitest ~]# GST_DEBUG=glmemory*:5,3 gst-launch-1.0 videotestsrc pattern=2
num-buffers=1 ! video/x-raw\,\ format\=\(string\)RGBA\,\ width\=\(int\)11000\,\
height\=\(int\)10000 ! glimagesink
0:00:00.546419000   300   0xc35f20 DEBUG               glmemory
gstglmemory.c:669:_gl_mem_init: new GL texture context:<glcontextegl0>
memory:0xc2c670 format:4 dimensions:11000x10000 stride:44000 size:440000000
0:00:00.548851000   300   0xc35f20 WARN            glbufferpool
gstglbufferpool.c:300:gst_gl_buffer_pool_alloc:<glbufferpool1> Could not create
GL Memory
0:00:00.550773000   300   0xc35f20 WARN              bufferpool
gstbufferpool.c:300:do_alloc_buffer:<glbufferpool1> alloc function failed
0:00:00.552435000   300   0xc35f20 WARN              bufferpool
gstbufferpool.c:333:default_start:<glbufferpool1> failed to allocate buffer
0:00:00.554225000   300   0xc35f20 ERROR             bufferpool
gstbufferpool.c:531:gst_buffer_pool_set_active:

What happens with philippe's pipeline is that too many elements in the pipeline
rely on the GPU (rpicamsrc, maybe omx), which results in the gpu memory being
exhausted quite quickly. The culprit are most probably within rpicamsrc or
omxh264dec.

> This could help: https://bugzilla.gnome.org/show_bug.cgi?id=730927 .
> 
> Thierry could you check if glcolorconvert is really set to passthrough mode ? At least this one should not do any conversion. Also please check it does

I think that my RGBA test checks that, otherwise it would crash with a smaller
buffer.

> not create any FBO, even if it is put in passthrough. You can hack
> glimageisink(bin) by replacing glcolorconvert with identity.
> 
> You can look for theses traces:
> GST_TRACE ("creating FBO dimensions:%ux%u", width, height);

Indeed, no FBO is created with the RGBA case; 1 is created with the YUY2 case

> GST_LOG ("copying memory %p, tex %u into texture %i", src, src->tex_id,
> tex_id);
> GST_INFO ("Context, EXT_framebuffer_object supported: yes");
> (I searched where gl->GenFramebuffers is called)

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