[Bug 725227] gstegl / eglglessink: EGLImage improvements

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725227
  GStreamer | gst-plugins-bad | unspecified

--- Comment #14 from Julien Isorce <julien.isorce at gmail.com> 2014-03-16 18:05:17 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > 
> > Note that there is another problem: eglDestroyImageKHR must be called in the gl
> > thread so we need to do something like in alloc_buffer with the blocking func.
> 
> Really? That seems completely suboptimal for the use case of EGLImage...

eglDestroyImageKHR is now called since this patch
https://bugzilla.gnome.org/show_bug.cgi?id=726337 (when using eglglessink with
omxvideodec). Then I checked the return value, it was ok and no egl error so it
seems to be ok but not after some time:

Indeed, thanks to Josep who added drain support
http://cgit.freedesktop.org/~adn770/gst-omx/commit/?h=drain&id=9e06a95be205d6bdaa7f12280ab336dbea6fdaf1,
using an adaptive stream it's possible to have the use case where there are
several resolution changes in a row.  I remember there were still errors around
eglimage after the 4 or 5th change.

So I guessed it was like gltextures that need to be deleted in the gl thread.
But you make me doubt about eglimage :). I thought it only depends if EGLimage
has been created with GL_NO_CONTEXT or not.

But maybe the errors are related to other stuffs. I have to check.

Anyway I'll do a unit test like creating / deleting lot of large EGLimages
using GstEGLImageBufferPool and see if there are any error / leak, when both
deleting in a different thread or in the glthread.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.