appsrc + x11 + GLMemory

[Matthew Waters]

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/514381e7/attachment.sig>