What happens to just-requested tee srcpad in PLAYING pipeline?

[Andrey Utkin]

2014/1/11 Sebastian Dröge <sebastian at centricular.com>:
> Same as for the other mail, please try to provide a simple testcase for
> this kind of pipeline. Something that just has this dynamic pipeline
> logic and no other application logic.

Same as for other mail, i had tried to make testcase up, but haven't
reproduced the problem in reasonably simple elements set.

> From what I guess from your description there are two problems here:
> a) loosing state and b) flushing sinks
>
> Loosing state can happen here if you add a sink to your PLAYING pipeline
> that is not in PLAYING state itself yet. Try to sync the newly added
> elements' state to your pipeline state.
> gst_element_sync_state_with_parent() can be useful for this for example.

Interesting, thanks.
Would gst_element_set_state (pipeline, GST_STATE_PLAYING) differ in effect?

> Flushing sinks can happen if you actually did not properly block
> pipeline branch where you remove the sink. You need to block an srcpad
> upstream of the sink and upstream of the part of the pipeline you want
> to remove with BLOCK|IDLE and at least DATA_DOWNSTREAM. And have all
> these probe callbacks return GST_PROBE_OK, not PASS, not REMOVE. And
> then from one of these callbacks (or after one has triggered then in
> another thread) shut down the pipeline part you want to remove.
> For this first unlink the srcpad with the downstream pad, (then do any
> EOS logic or not) then remove elements from the bin, then set states to
> NULL and unref all the elements.

Removing from bin before setting state to NULL seems to make sense,
but as far as i remember removing element in non-NULL state from bin
raises warning which says you have to set it to NULL first. So is it
still OK to do as you have said?

-- 
Andrey Utkin