What exactly is necessary here?

Python binding for gstgl API that allows sharing texture list between itnernal gstgl context and GL context from pyopengl. If we already have this then we should start a minimal example to see what is exactly missing or what are the involved problem we would have to solve.

I think this mostly depends on GObject-Introspection. There is a GstGL-1.0.gir/.typelib, someone will have to check how usable the is in Python and what is missing... and then probably teach GObject-Introspection about GL things.

lubosz could you describe your project https://github.com/lubosz/gst-gl-tests/tree/master/gst_opengl_editor
Is is compatible with pyopengl ? i.e. the purpose of this bug is to use a gltexture that comes from gstgl into a pyopengl scene. (setting up gstgl's context shares ressources with pyopengl context)

This project uses the pyopengl bindings for GL calls, but the GL context is created by GStreamer. The glsink's draw callback is used to render a scene using the video as a GL texture.
There currently is a regression in the gl plugins so my demo does not work.
The demo uses introspection bindings of the GL plugins. I wrote that patch for last GSoC.

The minimal examples are maybe also interesting:
https://github.com/lubosz/gst-gl-tests/tree/master/examples

They combine usages of Cairo, GL plugins and Gtk in different ways.

(In reply to Lubosz Sarnecki from comment #5)
> ...draw callback is used to render a scene

Awesome! We could still improve it by making the gl context share gl textures. So this bug is still relevant (marking bug as new).

> for last GSoC.
Which GSoC exactly ?

Thx for the details.

Maybe I should notice that plugins bad need to be compiled with Graphene for this demo.
I also use a combination of instrospected Graphene (which is currently quite buggy https://github.com/ebassi/graphene/issues/11) and numpy for linear algebra.

python-cairo from git is also needed for the demo to work.

Bisecting gst-gl showed this result

2c24b97cf05f60e20e83aabd56f0b3c79b58e3d1 is the first bad commit
commit 2c24b97cf05f60e20e83aabd56f0b3c79b58e3d1
Author: Matthew Waters <matthew@centricular.com>
Date:   Sun Oct 19 08:09:37 2014 +0400

    glx: ask for a GL3 core context


So 2c24b97cf05f60e20e83aabd56f0b3c79b58e3d1^ is required for the demo to work.

The GSoC I was working on this was 2014 for Pitivi, where I implemented the gltransformation plugin and gst-gl introspection bindings.
The changes for Pitivi are still not upstream, one reason is the regression, another is a missing abstraction for visual editors working with more plugins than just gltransformation.
The current Pitivi branch with this can be found here:
https://github.com/lubosz/pitivi/tree/transformation

Another project I am currently working on which builds upon this is a GStreamer VR player for the Oculus Rift. I will continue on these in March. For example on the GSt hackfest :)

After trying master again I noticed that GST_GL_API=opengl solved the problem with my demo. This was also not possible at some point, but is now.

I will port it to GL3, since it's the default in gst-gl now.
So the glsink's draw callback works fine again.

This is rather offtopic for the texture sharing issue, but it's a working method how to use gst-gl with pyopengl today.

I also wanted to point out this demo, which could maybe also be applied to a context created with pyopengl.

http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/qt/qglwtextureshare

I don't think there's anything else left to do in gstgl for this to work properly.  We have various toolkit integration with Gtk+, Qt and CoreAnimation using shared GL contexts.  It's just a matter of making it work for pyopengl.

As such, closing this and if there are any specific problems with pyopengl and libgstgl, please open new bugs.