[gst-devel] Newbie question about Pipelines
Andy Wingo
wingo at pobox.com
Mon Aug 18 20:07:30 CEST 2008
Hi Manuel,
Sorry for the very late reply. Parentheses can be very distracting!
On Thu 31 Jul 2008 00:56, Manuel.Serrano at sophia.inria.fr writes:
> I'm currently developing a binding for Gstreamer for Hop
Neat!
> All the elements are linked together and an asynchronous event handler is
> attached for "pad-added" signals.
Asynchronous is probably bad in this case; the typical behaviour of a
demuxer is to create pads when it finds streams, then start pushing on
those pads. If you do not install a synchronous handler for pad-added to
link that pad downstream, there is a race between the pad addition and
when the streaming thread starts to push; if you lose, the element's
call to gst_pad_push() returns UNLINKED, and the pipeline stops.
Perhaps you have figured a way around this, blocking in the signal
emission and marshalling to the main thread. That sounds like you could
get into deadlocks though -- is that what you're doing?
If you need to do handle pad-added from the main thread, you probably
want to call gst_pad_set_blocked from within a stub handler, set a flag
to signal the main thread to do something, and then return from
pad-added, freeing up the streaming thread to do other things.
> Now, the problem comes from a second function, named "replay", that
> sets the pipeline state to GST_STATE_NULL, then to GST_STATE_READY.
Well, among the other possibilities is that you have run into a bug.
This is not the typical use case for gstreamer; if you want to rewind,
set the pipeline to PAUSED, seek, and then PLAYING. If you really want
to "replay", it's probably just as fast to pass around a thunk to call
to make a new pipeline instead of reusing an old one.
Regards,
Andy
--
http://wingolog.org/
More information about the gstreamer-devel
mailing list