[gst-devel] Newbie question about Pipelines

[Manuel.Serrano at sophia.inria.fr]

Hello Andy,

First of all, thank you very for your help. I appreciate it.

> 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?
My problem, in deed, looks like a deadlock. The strange thing is that
when the "replay" function is invoked, the first pipeline stops and
the second one plays the audio content but no message are delivered on
the bus. If I call the "replay" function a second time, everything get
stuck.

> 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.
Pardon me, I do not understand your suggestion. My problem seems definitively
related to multi-threading because if I move the "pad-added" handler 
from the main thread to the thread that start the pipeline, everything
blocks. Are you suggesting the problem is coming from g_signal_connect_closure
used in a multi-threaded context.

> > 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
My intention here was just to stop the first pipeline before throwing it away.

> 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.
I realize that the name "replay" is confusing... The program I sent just
do exactly this. It creates a new pipeline and no longer uses the former
one...

Thanks again for your help.

-- 
Manuel