[gst-devel] Newbie question about Pipelines

[Andy Wingo]

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/