[gst-devel] Gstreamer and Cocoa run loops

[Michael Smith]

I'm not familiar with the specifics of Cocoa, or what CFMessagePort
does/how it works, so I can't really comment on that.

However, in general, the approach you're using sounds very sensible.

My advice is usually:
 - if appropriate to your platform, simply run a GMainLoop and
integrate through that. Easy, and well documented.
 - Otherwise, connect to the sync-message signal on the bus. Then
handle that directly for any messages you do need to handle
synchronously (which is unusual), and dispatch to your native platform
event loop to handle messages asynchronously. This sounds like what
you're doing. Generally, the only tricky bit with that is getting the
reference counting right - which isn't hard, but can sometimes be not
quite obvious.

If you're having "weird delays and bugs" you need to figure out what's
causing that - your general approach is the right one.

Mike


On Sun, Jan 30, 2011 at 9:25 AM, Jonathan Lyons
<higher.orbital at gmail.com> wrote:
> I'm having a lot of difficulty integrating the bus of a Gstreamer pipeline with a Cocoa run loop. Right now I'm using a CFMessagePort to turn a sync signal on one thread into an async event on the main thread. However, this results in weird delays and bugs.
>
> Has anyone on this list tried this? Would it be better to run all media operations on another thread which itself runs a glib main loop?
>
> I look forward to any response. Thank you.
>
> On Jan 30, 2011, at 8:53 AM, Nicolas Bertrand wrote:
>
>> Hi,
>> I use gstreamer via pygst.
>> with the version 0.10.32 from launchpad dev. ppa I did not success to
>> execute add_buffer_probe = The callback is never executed.
>>
>> This works fine with an older version of python-gst / libgstreamer. (cf.
>> version details below)
>>
>> Code Example :
>>
>>   def _capture_start_cb(self, wbin, b) :
>>
>>         pad = self.get_by_name("JpegEncoder").src_pads().next()
>>
>>         self._grabprobe = pad.add_buffer_probe(self._cb_process_frame, True)
>>
>>
>>
>>     def  _cb_process_frame(self, pad, gst_buffer, ret):
>>
>>         """ Callbak to inidicate that buffer is available from probe """
>>
>>
>>
>>         pad.remove_buffer_probe(self._grabprobe)
>>
>>
>>         return True
>>
>>
>> Did somebody know if it is a misuse or a real problem ( in that case I
>> fill a bug) ?
>>
>> cheers,
>> nico
>>
>> Problem constated Versions :
>> Ubuntu/lucid (64 bits)
>> python-gst0.10 0.10.21-1~lucid1
>> libgstreamer0.10-0 0.10.32-1~lucid1
>>
>> No problem constated version :
>> Ubuntu/maverick (32 bits)
>> python-gst0.10 0.10.19.4-1~lucid1
>> libgstreamer0.10-0 0.10.32-1~lucid1
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>