OpenGL renderer window..

Hans Hony hanshony at gmail.com
Sat Feb 10 23:33:16 UTC 2018


Scratch that last request.

install order matters:
http://pythonhosted.org/pyobjc/install.html#manual-installation

pip3 install pyobjc-core
pip3 install pyobjc-framework-Cocoa
pip3 install pyobjc-framework-Quartz

from CoreFoundation import CFRunLoopRun
CFRunLoopRun() # in the main thread

Unfortunately the blocking call breaks my signal handlers.. but that's
another issue..

OpenGL display pops up now.

Thanks!
Hans


On Sat, Feb 10, 2018 at 2:49 PM, Hans Hony <hanshony at gmail.com> wrote:

> I'm not sure I understand all the semantic details of this conversation -
> by which, I mean, I'm not quite sure how to do that specifically.
>
> So, CFRunLoop - is imported from CoreFoundation.. which I seem to be able
> to obtain via ctypes or PyObjC..
>
> Now how I use that in my python application is another story.. (In
> retrospect this might be more approachable in C++)
>
> I'm assuming that CFRunLoopRun is a blocking call, and would need to be
> executed at the end of my application code's run loop.
>
> I think I have the perfect place for that to happen in mind.. but the
> import details look a little hairy.. I also have to assume that CFRunLoop
> would react to SIGINT or SIGTERM..
>
> Lastly, I understand that this problem is slightly outside the scope of
> gstreamer. So, if you can respond with meaningful tips, I would be
> greatful.. but I do understand that the end of scope is quickly approaching.
>
>
> On Fri, Feb 9, 2018 at 8:01 PM, Matthew Waters <ystreet00 at gmail.com>
> wrote:
>
>> On 10/02/18 10:29, Hans Hony wrote:
>>
>> Matt,
>> Thanks for the response.
>>
>> I'm not sure I follow.. I already have an instance of Glib.MainLoop for
>> the pipeline to run already.
>>
>> This is constructed on the main thread just after Gst.init(None) is
>> called.
>> But.. I am running GLib.MainLoop.run in it's own thread - is this okay?
>> That Thread is started from the main application, just before the
>> pipeline is started.
>>
>>
>> Unfortunately, no.  The CFRunLoop must be running on the main thread,
>> otherwise this will not work.
>>
>> Cheers
>> -Matt
>>
>>
>> What I have tried so far:
>>
>> import gi
>> gi.require_version('GstGL', '1.0')from gi.repository import GstGL
>>
>> self._context = Gst.Context.new(GstGL.GL_DISPLAY_CONTEXT_TYPE, True)
>> self._gldisplay = GstGL.GLDisplay()
>> self._gldisplay.new()
>> self._glwindow = self._gldisplay.create_window()
>> self._glwindow.show()
>> self._glcontext = GstGL.GLContext.new(self._gldisplay)
>> GstGL.context_set_gl_display(self._context, self._gldisplay)
>> outputsink = gst_elem.make('glimagesink')
>> outputsink.set_context(self._context)
>> print('----- context: %s' % str(outputsink.get_property('context')))
>>
>>
>> What I notice is that the constructed Element 'glimagesink' has a context
>> property which returns 'None' after construction.
>>
>> I can see that the python rocket bouncing.. so it's attempting to kick
>> the display.. but no window.
>>
>> Do I need to override something with the GST_MESSAGE_NEED_CONTEXT,
>> perhaps?
>>
>> I have attempted to connect this on the bus 'message::need-context', but
>> get no signal..
>>
>>
>>
>> On Thu, Feb 8, 2018 at 1:21 AM, Matthew Waters <ystreet00 at gmail.com>
>> wrote:
>>
>>> Mac OS X is special in that a CFRunLoop is required to be running on the
>>> main thread in order for glimagesink (and other UI operations) to perform
>>> correctly.
>>>
>>> That either means you need to run one yourself, use a toolkit that runs
>>> one or run a GMainLoop.
>>>
>>> Running your gst-launch-1.0 command with GST_DEBUG=gl*:7 would give you
>>> more information about what GStreamer is attempting to do, specifically
>>> around https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree
>>> /gst-libs/gst/gl/cocoa/gstgldisplay_cocoa.m#n105.
>>>
>>> On 08/02/18 06:49, Hans Hony wrote:
>>>
>>> I have a question about launching a simple video pipeline using
>>> 'glimagesink' with the python3 gi.repository.Gst.ElementFactory..
>>>
>>> On Mac OSX I can launch my pipeline with custom plugin:
>>> gst-launch-1.0 filesrc <avi> ! decodebin ! queue ! my_custom_plugin
>>> <props> ! autovideosink
>>>
>>> The output a default window titled 'OpenGL renderer'.. which I assume is
>>> gstglwindow_cocoa.m
>>> <https://github.com/GStreamer/gst-plugins-bad/blob/1.12/gst-libs/gst/gl/cocoa/gstglwindow_cocoa.m#L466> from
>>> gst-plugins-bad.. ?
>>>
>>> Likewise, 'glimagesink' will also open the 'OpenGL renderer' window when
>>> used in a bash gst-launch-1.0 command in the same way as 'autovideosink'. Also
>>> I notice when I launch the pipeline under bash, I can see:
>>>
>>>     Setting pipeline to PAUSED ...
>>>
>>>     Pipeline is PREROLLING ...
>>>
>>>     Got context from element 'sink': gst.gl.GLDisplay=context,
>>> gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayCocoa\)\ gldisplaycocoa0";
>>>
>>>
>>> However, when I launch the pipeline for gi.repository.Gst.ElementFactory
>>> (in python3) I have issues:
>>>
>>>    1. It fails horribly for ElementFactory.make('autovideosink') with *Illegal
>>>    instruction: 4* when NULL to READY is propagated.. so to fix that I
>>>    just didn't use 'autovideosink'..
>>>
>>>    2. It will propagate PLAY for ElementFactory.make('glimagesink')..
>>>    but nothing actually plays.. probably because the chain isn't correct
>>>
>>>    3. I cannot figure out how to hook the 'sync_message' to an OSX
>>>    window object with glimagesink from python?!? I see information in
>>>    gst-inspect-1.0 glimagesink.. but I can't find any examples to do this
>>>    specifically.
>>>
>>>    4. Secondarily, I see that I can use gi.repository.GstGL.GLDisplay(
>>>    ).new() to create:
>>>        <__gi__.GstGLDisplayCocoa object at 0x10e05eb88
>>>    (GstGLDisplayCocoa at 0x7fc7ba9439c0)>
>>>    .. which is seemingly what I want!
>>>
>>>    5. How to do hook this object up to 'glimagesink' ??
>>>
>>>
>>> You don't need to hook this up to GStreamer, it will create that
>>> automatically.
>>>
>>>
>>>    1. Finally, do I need to add:
>>>      pipeline.get_bus().connect('sync-message::element',
>>>    on_sync_message) with a function on_sync_message(bus, msg) ?
>>>
>>>
>>> This shouldn't be needed.
>>>
>>> From the Gtk examples I found there was a function which would update
>>> the GUI.. I assume that I would need to do this as well.. but the syntax is
>>> not clear immediately.
>>> More specifically:
>>> def on_sync_message(bus, msg): if msg.get_structure().get_name() == '
>>> prepare-window-handle':
>>> sink = msg.src
>>> sink.set_window_handle(<window_handle>)
>>> sink.set_render_rectangle(0, 0, <window.width>, <window.height>)
>>>
>>>
>>> This is for embedding glimagesink's output inside another application.
>>>
>>> Overall, I want to know:
>>>
>>>    1. How is it that gst-launch-1.0 works so well?
>>>
>>>
>>> Because, glimagesink is generally created and set to READY on the main
>>> thread. Otherwise, happy accident.
>>>
>>>
>>>    1. How can I use that functionality in my python3 gi code?
>>>
>>>
>>> Run a CFRunLoop/GMainLoop on the main thread.
>>>
>>>
>>>    1. How can I add another element to trigger that force-aspect-ratio
>>>    window magic?
>>>
>>>
>>> I'm not sure what you mean by this.
>>>
>>> Cheers
>>> -Matt
>>>
>>> $ brew list --versions | grep gst
>>>
>>> gst-plugins-bad 1.12.3
>>>
>>> gst-plugins-base 1.12.3
>>>
>>> gst-plugins-good 1.12.3
>>>
>>> gst-plugins-ugly 1.12.3
>>>
>>> gst-python 1.12.3
>>>
>>> gst-rtsp-server 1.12.3
>>>
>>> gstreamer 1.12.3
>>>
>>> Thanks,
>>> Hans
>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180210/f41a07b6/attachment-0001.html>


More information about the gstreamer-devel mailing list