<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">Hello Vector thanks for your examples that help me to solve my SIGSEGV : I was trying to retrieve a unusefull byte buffer by calling map/unmap on the GstBuffer, seems strange this SIGSEGV .... but others problems are still present : - in file gstvaapivideometa_texture.c ( method gst_buffer_add_texture_upload_meta()), the code below is not compatible with the gst_buffer_add_video_gl_texture_upload_meta api : the method need a <code>GstVideoGLTextureType[4] </code><code>(because a memcpy is made on the 4 elements) and only a</code><code> </code><code><code>GstVideoGLTextureType</code>[1] </code><code>is given</code><code> </code>meta = gst_buffer_add_video_gl_texture_upload_meta (buffer, GST_VIDEO_GL_TEXTURE_ORIENTATION_X_NORMAL_Y_NORMAL, 1, &meta_texture->texture_type, gst_vaapi_texture_upload, meta_texture, (GBoxedCopyFunc) meta_texture_copy, (GBoxedFreeFunc) meta_texture_free); - in file gstvideometa.c (method gst_buffer_add_video_gl_texture_upload_meta()), memcpy (meta->texture_type, texture_type, sizeof (texture_type[0]) * 4); when there is only one texture (major case), it seems the caller need to feel the <code>GstVideoGLTextureType[4]</code> with a "invalid" value to be defined (GST_VIDEO_GL_TEXTURE_TYPE_INVALID for example) GstVideoGLTextureType texture_type[4] = {meta_texture->texture_type, GST_VIDEO_GL_TEXTURE_TYPE_INVALID, GST_VIDEO_GL_TEXTURE_TYPE_INVALID, GST_VIDEO_GL_TEXTURE_TYPE_INVALID}; - in gst_vaapi_texture_glx_new_wrapped(), a default gl_api seems to be searched once by calling the method gl_get_current_api() before reception of the query allocation containing my "gst.gl.GstGLContext" in my case, the GL version is "4.5.0 NVIDIA 358.16", GL_CONTEXT_PROFILE_MASK = 0 (seems to be a bug on nvidia card) : the method gl_get_current_api() can't decode the version and return GST_VAAPI_GL_API_NONE !! my gl_api (GL_API_OPENGL) contained in the GLContext (in the query allocation) is never read, nor the environment variable GST_GL_API, ........................................ to continue, I modify gl_get_current_api() to return GST_VAAPI_GL_API_OPENGL - the last problems is vaapi gstvaapiutils_glx.c:986:gl_unbind_pixmap_object: failed to release pixmap ?? christophe Le 18/01/2016 11:32, Víctor M. Jáquez L. a écrit : </div> <blockquote cite="mid:20160118103243.GA31123@mir.local.igalia.com" type="cite"> <pre wrap="">Hi Christophe On 01/17/16 at 11:32am, Christophe Lafolet wrote: </pre> <blockquote type="cite"> <pre wrap="">Hello, I've troubles with VAAPI and OpenGL :) I'm developping a Java OpenGL application with dynamic streams and use DecodeBin + AppSink to be notified of buffer reception. No problem when I disable VAAPI plugin selection and do texture upload myself. Now I want to use hardware decoding It's not clear to me which API should I use to shared openGL context with VAAPI - in this post : <a class="moz-txt-link-freetext" href="http://ystreet00.blogspot.com.au/2015/09/gstreamer-16-and-opengl-contexts.html">http://ystreet00.blogspot.com.au/2015/09/gstreamer-16-and-opengl-contexts.html</a> the new way should be to set a context on GST_MESSAGE_NEED_CONTEXT reception but the VAAPI plugin seems only verify that the given context contains a VAAPI display and delegate to element_class->set_context() but this callback is unset for VaapiDecode so no context is saved Question : why do I need to add a VAAPI display in this context ? DecodeBin is a black box for me and I'm surprised to specify a VAAPI display. </pre> </blockquote> <pre wrap=""> The virtual method call to parent class is a requirement for gstreamer 1.7: <a class="moz-txt-link-freetext" href="https://bugzilla.gnome.org/show_bug.cgi?id=757598#c2">https://bugzilla.gnome.org/show_bug.cgi?id=757598#c2</a> But you are using GStreamer 1.6, that's why that method is not resolved by the GstElement class. gstvaapidecode negotiates the GstGLContext in the allocation query because it needs to know which type of display backend to use in the GstVideoGLTextureUploadMeta callbacks (GLX or EGL). But it doesn't hold the context. The meta callbacks are going to be called in the rendering context. But that's a good catch: perhaps vaapidecode should request for a GstGLContext through the GstContext mechanism to know earlier the used display backend, and to avoid the propose_allocation() function in the appsink. Nonetheless, that will not solve your problem. The mechanism explained in Matthew's blog post is when you use glimagesink as a substitute of appsink, using its signal 'client-draw', where you will get a GstBuffer with a texture to render. This mechanism is used (experimentally) in WebKitGTK+: <a class="moz-txt-link-freetext" href="https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp#L727">https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp#L727</a> </pre> <blockquote type="cite"> <pre wrap="">- the old way seems to use allocation query : AppSink do not provide configurable "signal" to add callback to handle allocation query : I update the AppSink.propose_allocation field directly from Java with my callback and it works ... yes So, I add GstVideoGLTextureUploadMeta to the allocation query : "gst.gl.GstGLContext" with a gl_context build with gst_gl_context_new_wrapped(), VAAPI detects my parameters (GST_GL_PLATFORM_GLX, GST_GL_API_OPENGL) but a SIGSEGV is generated later. I receive samples containing no raw data (OK), a VideoGLTextureUploadMeta with one texture (OK) but can't upload </pre> </blockquote> <pre wrap=""> That's the way it should work. The meta callbacks should be called under the application gl context and they will upload the buffer into the texture: GstVideoGLTextureUploadMeta* meta; if ((meta = gst_buffer_get_video_gl_texture_upload_meta(buffer))) { if (meta->n_textures == 1) { // BRGx & BGRA formats use only one texture. guint ids[4] = { texture.id(), 0, 0, 0 }; if (gst_video_gl_texture_upload_meta_upload(meta, ids)) return; } } Which vaapi backend are you using? Some how I guess that is the vdpau one. Can you open a bug with the back trace? </pre> <blockquote type="cite"> <pre wrap="">Is there a example to use VAAPI + meta:GstVideoGLTextureUploadMeta ? </pre> </blockquote> <pre wrap=""> the element gstglupload does a good job <a class="moz-txt-link-freetext" href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglupload.c">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglupload.c</a> </pre> <blockquote type="cite"> <pre wrap=""> My config : Linux + X11 + GLX gstreamer 1.6.2-1 gstreamer-vaapi 0.7.0 gstopengl not used. </pre> </blockquote> <pre wrap=""> vmjl _______________________________________________ gstreamer-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </pre> </blockquote> </body> </html>