Re: [gst-devel] how to make gstreamer run in separate thread

[Gregory P. <gre...@gm...>]

On Mon, May 3, 2010 at 11:32 AM, Edward Hervey <bi...@gm...> wrote:
> On Sun, 2010-05-02 at 17:20 +0400, Gregory Petrosyan wrote:
>> On Sun, Apr 25, 2010 at 10:35 PM, Alexey Chernov <4e...@gm...> wrote:
>> > Thank you guys for support, I finally managed to make gstreamer process
>> > callbacks in separate thread. The solution was to set bus handler with
>> > gst_bus_set_sync_handler() instead of gst_bus_add_watch() as wl2776 proposed,
>> > special thanks for him. So here're some things which I found out from this
>> > case:
>> > 1. Qt actually dispatches glib events and no additional g_main_loop_run() is
>> > necessary for Qt applications.
>> > 2. Qt seems to create separate glib context for glib objects which are created
>> > in separate QThread objects.
>> > 3. To make callbacks be called in separate thread where the certain gst
>> > objects were created you need to set them as a handler with
>> > gst_bus_set_sync_handler() to make them processed in the context of certain
>> > objects and not in the main context.
>>
>> Hi!
>>
>> I'm also trying to use GStreamer with Qt, and I'm experiencing some
>> weird problems.
>>
>> 1) I'm not sure if Qt dispatches glib events (on Windows, at least):
>> gst_bus_add_watch()'ed callback is never called
>
>  Use gst_bus_add_signal_watch(bus) and then connect to the 'message'
> event of the bus. If Qt is built with glib and uses the GMainLoop
> internally, the message signal will be emitted in the main thread.

Thanks,

If you mean that I should use g_signal_connect(bus, "message", ...)
after gst_bus_add_signal_watch(bus), then no, unfortunately that does
not work. Looks like default windows Qt version does not dispatch glib
events.

>> 2) gst_bus_set_sync_handler() works, but events that I send from it
>> (using Qt::QueuedConnection) seem to never reach the main loop, and I
>> don't even know how to debug this
>
>  It's a *synchronous* handler, therefore the callback you set will be
> called in the thread context of whoever emitted that message.

Sure, I know this :-)

I was trying to post Qt events from this synchronous handler to the
main thread (using QMetaObject::invokeMethod(&obj, "method",
Qt::QueuedConnection) to be precise).

                Gregory