GstCollectPads-related freeze in pads mgmt

[Sebastian Dröge]

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.

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