[gst-devel] why/when are state changes needed in dynamically modified pipelines?

[Daniel Lenski]

On 9/12/07, Andy Wingo <wingo at pobox.com> wrote:
> Hi,
>
> On Wed 12 Sep 2007 15:47, "Daniel Lenski" <dlenski at gmail.com> writes:
>
> > When and why are state changes needed in dynamic pipeline creation?
>
> You want points at which you know what the status of dataflow is.
>
> In READY you know that no data is flowing; you can always link things
> then.

Thank you, Andy!  This is very helpful.  So, as a novice, I can
reliably create dynamic streams as long as I place them into the READY
state before linking in the new elements?  Why is it that after
linking the those new elements, I can put the stream into either
PAUSED or PLAYING state... with the same effect apparently?

> For some pipelines, however, all of the state is not ready in READY, as
> with decodebin. However you know that within a pad-added signal that
> the signal is coming from the streaming thread, so you know what the
> state of dataflow is (blocked in the callback for the signal).

And decodebin's state is not ready in READY because it is itself a
dynamically constructed bin, if I understand correctly, so it has to
wait for data to flow through its typefind element until it fully sets
up its state.  Is the dataflow for the whole pipeline automatically
blocked for the duration of the callback, and restored afterwards?

So, the signal is called in the context of the streaming thread...
sometimes in my non-working versions of this program, I've gotten
warning messages saying "can't change the state of the pipeline from
its streaming thread."

> You can know what the dataflow status is in PLAYING if you block pads,
> either synchronously or asynchronously and wait for the callback. In
> that case you can link/unlink in PLAYING.
>
> Linking/unlinking without blocking, in PLAYING, is racy, and you
> shouldn't do it; it might work sometimes, or the pipeline might error
> out. It should not crash GStreamer, however.

Good to know.  It has not crashed at all for me, the worst that
happens is the pipeline refuses to continue playing... I wasn't able
to track down the particular element or pad causing the problem.

> HTH,
>
> Andy.

Indeed it does!  Sounds like I will be able to reliably work with
dynamic pipelines as long as I set them to READY state before
modifying them.  And I figure out more of the details as I learn.

Thanks,
Dan