GstCollectPads-related freeze in pads mgmt
Sebastian Dröge
sebastian at centricular.com
Fri Jan 3 03:45:17 PST 2014
On Fr, 2014-01-03 at 11:33 +0100, Sebastian Dröge wrote:
> On Do, 2014-01-02 at 23:44 +0200, Andrey Utkin wrote:
> > The problem i experience can be reproduced with my GstTq sketch:
> > github.com/krieger-od/gst_tq , if you change line 14 to "gboolean
> > release_sinkpads = FALSE;".
> >
> > So we have such a pipeline: http://whdd.org/bin.png
> > It is in playing state.
> > Then we want to release both tq srcpads, which are linked with
> > mpegtsmux element.
> > It works when we release also muxer sinkpads in order.
> > But it freezes the app if we don't release muxer sinkpads immediately.
> > This can happen, for example, if we want to connect them with
> > something else. Or, what i have in my app at the moment, the actual
> > muxer element and its pads are unavailable, and application level has
> > access to other pads that lead to muxer, and these available pads are
> > not of requestable type, but of "sometimes" type. I know that
> > technically this can be changed, but anyway, what about the first
> > usecase?
>
> Can you open a bug about this with a minimal testcase?
>
> Blocking (downstream block at least) the srcpads in front of the muxer
> and the removing them should work just fine and not deadlock. There must
> be no streaming thread inside collectpads in the muxer at that time, and
> also not in the future until you unblock. There might be more calls to
> the block callback though and you must block there too.
Note that you need to block the most upstream pad that you want to
remove. So if you want to remove the tee srcpad, the queue and the bin
srcpad (the ghostpad), you need to block the tee srcpad. Blocking at the
bin srcpad should still make sure that the pad's streaming thread is not
inside the muxer.
Also depending on what you want to do, you can also use an idle probe.
--
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: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140103/10b2921a/attachment.pgp>
More information about the gstreamer-devel
mailing list