[Bug 725227] gstegl / eglglessink: EGLImage improvements
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Sun Mar 16 10:41:09 PDT 2014
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.
More information about the gstreamer-bugs
mailing list