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

[Sebastian Dröge]

On Fr, 2014-01-10 at 18:15 +0200, Andrey Utkin wrote:
> Currently i'm having problem with pipeline going back to PLAYING state
> because of source element task paused and not going back to work.
> I guess that's what really happens is that we attach a new branch (not
> necessarily to tee directly linked with source element, it also can be
> linked through a chain of other tees and queues).
> Newly-linked pipeline part affects state of elements in all pipeline,
> automatically.
> Source element task pushes data though each tee srcpad. With the pad
> which is linked to fakesink everything is ok, but some pad is in fact
> in "flushing" state (i guess because pipeline part behind it is
> currently being reconfigured due to  linking of new elements), which
> makes source element task to get paused. Unfortunately, setting
> pipeline to PLAYING state, even repeatedly, does not help.
> It should be very hard to block all pushing tasks in the pipeline to
> add new pipeline branch safely, because my pipelines have a lot of
> queue elements.
> Below is a listing of last lines from source task thread, with GST_DEBUG=5.
> Any ideas how to overcome this? Either to avoid stopping source task,
> or to make it get up again.
> Inserting queue between source element and first tee doesn't change anything.

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.

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.

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.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140111/46a025c4/attachment.pgp>