GstCollectPads-related freeze in pads mgmt

[Sebastian Dröge]

On Sa, 2014-01-11 at 15:12 +0200, Andrey Utkin wrote:

> > Or am I talking about something different? :) If that's the case I could
> > tell you how it is supposed to work, otherwise please provide a testcase
> > or describe your pipeline setup again.
> 
> Yes, please tell how it is supposed to work.

What should work in theory is the following:

a) Add a pad probe on the srcpad in front of the muxer with
GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM. No need to block.
b) Send an EOS event to the source of the branch you want to remove
c) Let everything pass in the pad probe until the EOS event. If EOS
event, unlink srcpad and muxer, drop EOS event, remove probe, do
whatever. It doesn't matter much
d) now it is guaranteed that there is no data flow and everything is
drained
e) From the probe callback now trigger another thread. This other thread
will then shut down all elements (sink to source), remove them from the
bin, unref them, etc.. Then create new elements in their place, link
stuff, sync states, make sure to set up segments and everything properly
to pass the muxer the expected running time from the new elements and
done.


e) is necessary from another thread and can't be done from the pad probe
because the pad probe happens from the streaming thread of these
elements. You can't set them to NULL state from the streaming thread, or
you will deadlock.


If this doesn't work you found a bug that we should fix, but for that it
should be trivial to produce a simple testcase then :)

-- 
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/7d1724a0/attachment-0001.pgp>