appsrc + x11 + GLMemory

Matthew Waters ystreet00 at gmail.com
Sun Nov 1 08:46:34 UTC 2020


Also, the GL context that the GstGLMemory's are allocated from must be 
one that supports marshalling calls to another thread which your wrapped 
GstGLContext does not.  This is so that when GL operations are required 
(like deleting the texture, or copying the texture, or mapping the 
texture) they can be performed in the correct thread. The wrapped GL 
context does not support this and therefore, you should not be pushing 
GstGLMemory's from your wrapped GL context into the pipeline.  You would 
need to either retrieve the pipeline's GL context and allocate from 
that, or create your own not wrapped GL context.

On 1/11/20 7:38 pm, Matthew Waters wrote:
> Don't gst_gl_display_add_context() your wrapped GL context.  That 
> won't work.  The contexts stored by the GstGLDisplay all have their 
> own threads and your wrapped context does not which is why it's 
> failing the threading checks.
>
> On 30/10/20 11:02 pm, Antonio Ospite wrote:
>> Hi,
>>
>> I too am trying to do something like this: pushing an OpenGL texture
>> wrapped in GLMemory to GStreamer gl elements using appsrc.
>>
>> I think I applied Matthew's fixes to the example from Nikolay, but there
>> is still something missing.
>>
>> I am still getting the assertion 'context->priv->active_thread ==
>> g_thread_self ()' failed and it looks like it's from the gldownload
>> element.
>>
>> The logs seem to indicate that the contexts are shared (correctly?), see
>> the attached "log.txt" file produced with:
>> $ GST_DEBUG=*:3,GST_CONTEXT:7 ./appsrc-glcontext
>>
>> The issue comes from the GstGLDownloadElement which right now is the
>> only gl element in the pipeline, eventually some filters will be there
>> too and hopefully nvh264enc as well.
>>
>> The backtrace is in the attached 'gdb_backtrace.txt' file.
>>
>> I am attaching the updated code in case someone wants to take a look,
>> some of my doubts are marked with XXX in comments.
>>
>> I also tried using gstsrcbin and setting the appsrc in the "src"
>> property, as can be seen in the attached use-glsrcbin.diff file,
>> thinking that this might make things smoother, but it didn't seem to
>> improve anything at this stage.
>>
>> Any help appreciated.
>>
>> Thanks,
>>     Antonio
>>
>> On Sat, 6 Jun 2020 15:52:17 +1000
>> Matthew Waters <ystreet00 at gmail.com> wrote:
>>
>>> 1. external-oes textures are special and unless you are doing 
>>> EGLImage's
>>> or some custom thing, then they are not useful for you.  you most 
>>> likely
>>> want regular 2D textures.
>>> 2. If you set G_DEBUG=fatal-warnings and run your program in a 
>>> debugger,
>>> the program will stop on the first warning that is output.
>>> 3. With regards to the warnings, you are attempting to call a GStreamer
>>> OpenGL library function with an GstGLContext that is not current (the
>>> GLX context may be current but GStreamer does not and cannot know
>>> that).  The GstGLContext that you are providing to various GStreamer
>>> OpenGL functions is your wrapped application context.  This wrapped
>>> application context has special requirements for ensuring that the
>>> OpenGL context is current in the thread it is being called from and 
>>> will
>>> produce those warnings from gst_gl_context_thread_add if you fail to
>>> adhere to the API contract.  You must ensure that your application has
>>> the OpenGL context current for the wrapped GstGLContext and you must
>>> notify GStreamer of that by calling gst_gl_context_activate (context,
>>> TRUE) in the thread where the application provided context is current.
>>> 4. There are various confusions of RGB vs RGBA in your application.  
>>> All
>>> formats must be identical. i.e. GL_RGBA maps to GST_VIDEO_FORMAT_RGBA.
>>> The various gst_gl_format_*() functions can help you choose the correct
>>> OpenGL format and internal format for your textures.
>>> 5. There is no need to call glXSwapBuffers.  The fact that you are
>>> indicates you may be rendering to the front/back buffers which is not
>>> how rendering to a texture works.
>>>
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201101/d3d22536/attachment.sig>


More information about the gstreamer-devel mailing list