[Bug 764725] splitmuxsink: deadlock on stream error

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=764725

--- Comment #6 from Xavier Claessens <xclaesse at gmail.com> ---
Thinking a bit more about it, maybe it's a bug in my side actually.
Splitmuxsink unblock streaming threads when receiving EOS on the reference pad,
or when state change to READY or NULL. So I think the proper thing to do is
sending eos on every pads when there is a StreamError coming from upstream.

What my code is currently doing is first gst_element_release_request_pad() on
splitmuxsink's pads before changing its state to NULL. But releasing the pad,
takes the pad lock which is already held by the pad probe that blocks in
handle_mq_input(). So that deadlock.

I changed my code to first send EOS on each pad, then releasing request pads,
then setting state to NULL, and it seems to work like that.

So maybe this bug is INVALID, it's up to the user (me) to handle stream errors
correctly?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.