GNOME Bugzilla – Bug 729588
glimagesink: cannot play 1080p on RPI
Last modified: 2014-05-09 08:15:19 UTC
720p is ok, but it's not possible to play a 1080p stream whereas it was possible with eglglessink on RPI, with gpu_mem=128. It fails when creating the 4th eglimage: eglCreateImageKHR: failed to create image for buffer 0x5 target 12465 error 0x300c. I thought recent improvement in gstglbufferpool/upload may have safe enough resources but still not enough. I should mention that this when using also omxvideodec, and it complains about having not enough resources. If I use fakevideodec then it works. So I guess the diff with eglglessink is maybe that we are leaking a texture or we generate an additional FBO. I'll investigate this one.
commit 2115f11f0b29b0f48e377557fc4ca2ae3a0701e7 Author: Julien Isorce <julien.isorce@collabora.co.uk> Date: Tue May 6 11:27:47 2014 +0100 gl: no need to initialize a frame buffer object to upload an eglimage Fix https://bugzilla.gnome.org/show_bug.cgi?id=729588
It seems my fix http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=2115f11f0b29b0f48e377557fc4ca2ae3a0701e7 made too many assumptions. Indeed http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=6f4fd7086745720c39cc1d6bfd7a1c4c845caf99 breaks it. Well the proper fix would be to know in gst_gl_upload_init_format(GstGLUpload * upload, GstVideoInfo * in_info) that it will be an eglimage. I'm thinking about changing API a bit to add a third parameter: gst_gl_upload_init_format (GstGLUpload * upload, GstVideoInfo * in_info, const gchar *mem_type) any suggestion ?
Either that or make the whole upload process lazy and init the GL stuff on the first buffer passed through. Should be fairly simple to do.
I think once the caps are negotiated and fixed, in set_caps it's a good time to initialize stuffs like FBO. Doing it at rendering time could lead to some sync problems. There is generally a pre rolled buffer but I think we cannot rely on that. So best thing is to keep FBO initialization when it's done currently. Just need a way to tell gstglupload to pre-init stuffs or not. And do pre-init by default.
Created attachment 276166 [details] [review] gl/upload: set initted to TRUE when _init_upload succeeded
Created attachment 276167 [details] [review] gl/upload: add gst_gl_upload_set_lazy and set it not lazy by default
Created attachment 276168 [details] [review] gl/bufferpool: ensure to not initialize a frame buffer object to upload an EGLImage
I just have a doubt for 276166 as you made changes today :)
Review of attachment 276167 [details] [review]: I'm not a fan of this. The use case you are presenting is for not allocating a fbo when using EGLImages however the concept of uploading (using EGLImages) and converting (where the fbo is) are two seperate processes. glupload is now only really concerned with getting the data onto the GPU, which does not use a fbo. You will need to change the colorconvert code to support the fast path of not converting when the video info's are the same.
Review of attachment 276168 [details] [review]: See previous review and bug #729278
All right, I prefer to focus on bug #729278 And I confirm your commit a49a3717109db6a29f03a2ec2f561d1fbb56adaf fixed back the current bug. commit a49a3717109db6a29f03a2ec2f561d1fbb56adaf Author: Matthew Waters <ystreet00@gmail.com> Date: Thu May 8 13:46:29 2014 +1000 gl/upload: implement lazy init Rename init_format to set_format Also I'll push attachment 276167 [details] [review] separately