<div dir="ltr">Hi Matt,<div><br></div><div>Cool, thanks for the follow up on OS X. I'm pretty sure that JOGL doesn't use XQuartz, so it is probably just a NSApp. For Linux and Windows, it relies on <a href="https://github.com/sgothel/jogl/blob/master/src/nativewindow/native/x11/Xmisc.c#L489">X11</a> and (if understand the native core correctly) on the <a href="https://github.com/sgothel/jogl/blob/master/src/nativewindow/native/win32/GDImisc.c#L121">win32 API</a>.</div><div><br></div><div>Do you want me to open an issue on the gstreamer tracker requesting the API enhancement, so at least the discussion is better focused?</div><div><br></div><div>Andres</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 4, 2015 at 1:55 AM, Matthew Waters <span dir="ltr"><<a href="mailto:ystreet00@gmail.com" target="_blank">ystreet00@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
On 04/09/15 04:36, Andres Colubri wrote:<br>
<blockquote type="cite">
<div dir="ltr">
<div>It looks it will be a bit more involved that originally
thought :-)</div>
<div><br>
</div>
<div>I'm working on Mac right now, and the native window is not
created neither with QT or GDK. Seems to be a straight
NSWindow, handled by JOGL:<br>
</div>
<div><br>
</div>
<div><a href="https://github.com/sgothel/jogl/blob/master/src/nativewindow/native/macosx/OSXmisc.m#L342" target="_blank">https://github.com/sgothel/jogl/blob/master/src/nativewindow/native/macosx/OSXmisc.m#L342</a><br>
</div>
<div><br>
</div>
<div>So I would imagine that I need to implement something
analogous to your <span style="font-size:12.8000001907349px">synchronous
bus callback on X, using the corresponding NSWindow API to
get the display, etc. This exceeds my current knowledge and
available time, but will try to find a way to work through
it.</span></div>
</div>
</blockquote>
<br></span>
On OS X, you actually don't need to wrap a display object and can
just use the default from gst_gl_display_new(), just the GL context
(as long as JOGL uses NSApp I believe). It's inferred from the
global NSApp object provided by Cocoa. If JOGL is actually using
XQuartz and therefore X11, then you'll have to deal with the X11
display as you would on a Linux system.<br>
<br>
There's also a CoreAnimation layer CAOpenGLLayer that is available
through GstGLCAOpenGLLayer that can be used if JOGL is using
CALayer's instead. See the the sink at <a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/caopengllayersink.m" target="_blank"></a><a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/caopengllayersink.m" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/caopengllayersink.m</a><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-size:12.8000001907349px">Only out of
curiosity, I wonder if it would be better to have a GstGL
function that takes the handles to the display and the GL
context, together with the window, platform, and gl api
identifiers, and internally creates the </span><span style="font-size:12.8000001907349px">GstContext wrapping the
context from the app... but this is nothing more than moving
the complexity from the user code into gstreamer, which is
something you might not want to do/support, quite
understandably.</span></div>
</div>
</blockquote>
<br></span>
I have thought about adding that before and it still might be
something we do to ease development.<br>
<br>
Cheers<br>
-Matt<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-size:12.8000001907349px">Thanks for all
your help!</span></div>
<div><span style="font-size:12.8000001907349px">Andres</span></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 2, 2015 at 10:47 AM, Andres
Colubri <span dir="ltr"><<a href="mailto:andres.colubri@gmail.com" target="_blank">andres.colubri@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Matt,
<div><br>
</div>
<div>Thanks a lot for your detailed answer! My application
is in fact written in Java, and uses JOGL to access the
GL API, as well as to handle the display across Mac,
Windows, and Linux. I will see how can I get the native
handle to the display (getting the handle to the context
is easy), and apply the techniques in the code you
linked to. I will post an update with links to my
source.</div>
<div><br>
</div>
<div>Best,</div>
<div>Andres</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 2, 2015 at 10:37
AM, Matthew Waters <span dir="ltr"><<a href="mailto:ystreet00@gmail.com" target="_blank"></a><a href="mailto:ystreet00@gmail.com" target="_blank">ystreet00@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On 02/09/15 18:20, Andres Colubri wrote:<br>
> Hi there,<br>
><br>
> I have a question about the GL plugins.
I'm implementing an OpenGL<br>
> application that uses gstreamer to play
videos, and my goal is to have<br>
> gstreamer uploading the frames to GL
textures, and the app rendering<br>
> these textres on its own GL surface. From
what I read online, I should<br>
> use a glupload element to copy the frames
into GL textures, and then<br>
> all I would need to do is to retrieve the
glids using appsink. I'm<br>
> able to pull the ids with the following
pipeline:<br>
><br>
> uridecodebin uri=%s ! videoconvert ! " +
caps + " ! videoscale !<br>
> glupload name=glup ! appsink name=sink<br>
><br>
> However, in order to render the textures,
gstreamer should use the<br>
> same GL context from my application.<br>
><br>
> Fromt looking at the cluttershare example<br>
> (<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/clutter/cluttershare.c" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/clutter/cluttershare.c</a>)<br>
> and other pieces of code I found on the
web, seems that I should pass<br>
> the handle of the GL context to gstreamer
with the following code:<br>
><br>
> GstElement *glupload =
gst_bin_get_by_name (GST_BIN (v->play),
"glup");<br>
> g_object_set (G_OBJECT (glupload),
"external-opengl-context",<br>
> context, NULL);<br>
> gst_object_unref (glupload);<br>
><br>
> However I get the following error:<br>
><br>
> (<unknown>:33272):
GLib-GObject-WARNING **: g_object_set_valist:<br>
> object class 'GstGLUploadElement' has no
property named<br>
> 'external-opengl-context'<br>
><br>
> GstGLFilter seems to have an
"other-context" property, but I don't<br>
> need to apply any filter on the frames,
just to pull them out of the<br>
> pipeline. Any ideas on how to do this?<br>
<br>
</div>
</div>
Hi,<br>
<br>
Ok, it seems like you're attempting to use 1.4 API
with a 1.5 gstreamer<br>
installation where the context sharing interface
was mostly rewritten to<br>
use GstContext [1].<br>
<br>
Here's what you need to do:<br>
1. Provide a display connection to GStreamer. The
easiest is to provide<br>
a GstGLDisplay wrapping your window system display
connection as you'll<br>
need it later as well to create a wrapped GL
context. What exactly is<br>
required depends on the exact window system used.
See [2] and [3] for<br>
some inspiration.<br>
2. Provide the GL context to GStreamer as a
GstGLContext. GStreamer<br>
will then create it's own GL context that shares
with the provided GL<br>
context. See [4] and [5] for an example.<br>
<br>
When you provide these GstContext's mostly depends
on your application<br>
but you essentially have two options as to when
you call<br>
gst_element_set_context() with the required
information (both display<br>
and GL context):<br>
1. At application start up before the pipeline is
running<br>
2. As a response to a NEED_CONTEXT message you
receive on the GstBus.<br>
<br>
See [6] for the current list of GstContext names
currently accepted by<br>
all the GL elements.<br>
<br>
Cheers<br>
-Matt<br>
<br>
P.S your pipeline doesn't contain any video format
conversion elements<br>
so whatever uridecodebin outputs will be pushed
into appsink. You can<br>
try adding glcolorconvert or videoconvert to
convert to a format you want.<br>
<br>
[1] - <a href="https://developer.gnome.org/gstreamer/stable/gstreamer-GstContext.html" rel="noreferrer" target="_blank">https://developer.gnome.org/gstreamer/stable/gstreamer-GstContext.html</a><br>
[2] -<br>
<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gtk/gtkgstglwidget.c#n421" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gtk/gtkgstglwidget.c#n421</a><br>
[3] -<br>
<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/qt/qtitem.cc#n114" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/qt/qtitem.cc#n114</a><br>
[4] -<br>
<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gtk/gtkgstglwidget.c#n471" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gtk/gtkgstglwidget.c#n471</a><br>
[5] -<br>
<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/qt/qtitem.cc#n265" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/qt/qtitem.cc#n265</a><br>
[6] -<br>
<a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglutils.c#n703" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglutils.c#n703</a><br>
<br>
Here's an example of a synchronous bus callback
for an X11 display:<br>
<br>
static GstGLDisplay *gl_display = NULL;<br>
static Display *x11_display = NULL;<br>
<br>
static void<br>
_open_x11 ()<br>
{<br>
if (!x11_display)<br>
x11_display = XOpenDisplay (NULL);<br>
}<br>
<br>
static gboolean<br>
sync_bus_call (GstBus *bus, GstMessage *msg,
gpointer data)<br>
{<br>
switch (GST_MESSAGE_TYPE (msg)) {<br>
case GST_MESSAGE_NEED_CONTEXT:<br>
{<br>
const gchar *context_type;<br>
GstContext *context = NULL;<br>
<br>
gst_message_parse_context_type (msg,
&context_type);<br>
g_print("got need context %s\n",
context_type);<br>
<br>
if (g_strcmp0 (context_type,
GST_GL_DISPLAY_CONTEXT_TYPE) == 0) {<br>
<br>
_open_x11 ();<br>
<br>
if (!gl_display)<br>
gl_display = GST_GL_DISPLAY<br>
(gst_gl_display_x11_new_with_display
(x11_display));<br>
<br>
context = gst_context_new
(GST_GL_DISPLAY_CONTEXT_TYPE, TRUE);<br>
gst_context_set_gl_display (context,
gl_display);<br>
<br>
gst_element_set_context (GST_ELEMENT
(msg->src), context);<br>
}<br>
<br>
/* Here you'd retrieve the GstGLContext like
in [4] and [5] and do a<br>
* similar thing as above with the display
but matching types/names<br>
* with the "gst.gl.app_context" case in [6]
*/<br>
<br>
if (context)<br>
gst_context_unref (context);<br>
break;<br>
}<br>
default:<br>
break;<br>
}<br>
<br>
return FALSE;<br>
}<br>
<br>
> Thanks!<br>
> Andres<br>
><br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>