GNOME Bugzilla – Bug 745233
vaapidecode: set the GL context when creating a GstVaapiTexture (GLX)
Last modified: 2015-11-19 17:34:55 UTC
When glimagesink is used, this sink sends to vaapidecode the GL context to use in GLX. The merged EGL branch handle this right now. But, when meta:GLTextureUploadMeta is negotiated and vaapidecode tries to create a GstVaapTexture_glx with the processed texture, the element is not using the received GL context from the sink so the texture processing fails. I haven't tried with EGL, but it seems that the bits already are in place.
Just to confirm that enabling EGL and disabling GLX, the context sharing with the glimagesink works like a charm.
*** Bug 746650 has been marked as a duplicate of this bug. ***
Hi, is it possible to make this context sharing work for vaapi + GLX? Any pointers on how to do it would be helpful. Is this supposed to lead to a pipeline error or only suboptimal performance due to non-zero copy behaviour? The pipeline filesrc ! demux ! vaapidecode ! glimagesink works for some file formats (mp4/qtdemux), I assume without proper context sharing. But fails for others (e.g. avi/avidemux) with a negotiation failure. But i think this happens even with vaapisink, so maybe it's a different bug.
(In reply to Vasilis Liaskovitis from comment #3) > Hi, is it possible to make this context sharing work for vaapi + GLX? Any > pointers on how to do it would be helpful. Actually, I'm not sure if this bug is still valid. > > Is this supposed to lead to a pipeline error or only suboptimal performance > due to non-zero copy behaviour? gl elements are evolving constantly, and they are not supposed to be considered stable. So, one day they might be working, and the next, not. For example, right now, in gstreamer-1.4, as you pointed below, some streams are not negotiated with glimagesink, and some others are. But in gstreamer-1.5 must of them works. This bug, in the past, led to a pipeline error (different to negotiation), but now, as gl has become significantly better, GLX works, but when using OpenGL3 glimagesink has some complains. Right now, with gstreamer-1.5 (current master) GST_GL_WINDOW=x11 GST_GL_API=gles2 GST_GL_PLATFORM=egl - OK GST_GL_WINDOW=x11 GST_GL_API=opengl GST_GL_PLATFORM=glx - OK GST_GL_WINDOW=x11 GST_GL_API=opengl3 GST_GL_PLATFORM=glx - NOT OK These are the errors shown with opengl3 and glx: 0:00:00.335460953 11561 0x7fb400046450 ERROR glcontext gstglcontext.c:1078:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:2, GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_2D) 0:00:00.335489173 11561 0x7fb400046450 ERROR glcontext gstglcontext.c:1078:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:2, GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D) 0:00:00.335506643 11561 0x7fb400046450 ERROR glcontext gstglcontext.c:1078:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:2, GL_INVALID_ENUM in glGetTexLevelParameter[if]v(pname=GL_TEXTURE_BORDER) 0:00:00.335520615 11561 0x7fb400046450 ERROR glcontext gstglcontext.c:1078:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:2, GL_INVALID_ENUM in glDisable(GL_TEXTURE_2D) > > The pipeline filesrc ! demux ! vaapidecode ! glimagesink works for some file > formats (mp4/qtdemux), I assume without proper context sharing. But fails > for others (e.g. avi/avidemux) with a negotiation failure. But i think this > happens even with vaapisink, so maybe it's a different bug. In the case of gstreamer-1.4 the vaapidecode never links to the glimagesink and the preroll never occurs. I don't know if it is worth to fix since only happen in gstreamer-1.4.
thanks, I confirm that current master repos work with x11+opengl+GLX. Is context sharing always happening when creating the GstVaapTexture_glx (for performance reasons) or is it possible that the texture is copied due to different vaapi and sink gl contexts? Can I verify this from any particular log messages?
I have just pushed a couple commits which log the negotiated caps, either in vaapidecode and vaapipostroc, hence, if you run something like $ GST_GL_WINDOW=x11 GST_GL_API=opengl GST_GL_PLATFORM=glx \ gst-play-1.0 video.mp4 --videosink=glimagesink \ --gst-debug="vaapidecode:4,vaapipostproc:4" You should see something like: new src caps = video/x-raw(meta:GstVideoGLTextureUploadMeta) If so, the context has been shared and the sink uploads the frame from the decoder into its texture. The upload can be zero-copy or, at least, much more cheaper than mem copy.
thanks! yes i now see the GstVideoGLTextureUploadMeta with the gst-play example you mentioned. I don't see it in the gst-launch pipeline below though, is that expected? Are any changes needed in the pipeline? GST_DEBUG=4,*vaapi*:6 gst-launch-1.0 -v filesrc location=/opt/video.mp4 ! qtdemux ! vaapidecode ! glimagesink
(In reply to Vasilis Liaskovitis from comment #7) > thanks! yes i now see the GstVideoGLTextureUploadMeta with the gst-play > example you mentioned. > > I don't see it in the gst-launch pipeline below though, is that expected? > Are any changes needed in the pipeline? I see it. (gstreamer 1.5, current master) > > GST_DEBUG=4,*vaapi*:6 gst-launch-1.0 -v filesrc location=/opt/video.mp4 ! > qtdemux ! vaapidecode ! glimagesink Anyway, let's do not turn a bug tracker into a support forum.
Reviewing the bug, I realized that it just turned into a duplicated of bug 753099 *** This bug has been marked as a duplicate of bug 753099 ***