[Bug 747297] gl: live rpicamsrc/omxh264dec/glimagesink pipeline fails
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Jan 5 01:44:28 PST 2016
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.
More information about the gstreamer-bugs
mailing list