[Bug 763711] splitmuxsink: deadlock when one streams doesn't have regular buffers

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Jan Schmidt <thaytan at noraisin.net> ---
(In reply to Xavier Claessens from comment #13)
> (In reply to Jan Schmidt from comment #11)
> > I don't think that's needed - handle_mq_input() will just pass the custom
> > event anyway (and works here if I just revert those 2 lines). Moving the
> > probe to the externally visible pad can cause problems if the app or other
> > plugins install their own probes and interfere with the internal one.
> 
> Hm, in some older versions of the patch that was causing deadlocks, but it
> seems to work now indeed. I didn't know it was safe to send an event on a
> pad from within a blocking probe on that same pad.
> 
> > There's a different stall I found which we should also address if pads don't
> > all EOS in the same fragment - if pads are already EOS when the new fragment
> > starts, the EOS isn't repeated into the muxer things never finish up.
> 
> I think my patch fix that case already. restart_context() resets
> ctx->out_eos to FALSE and the custom event will wakeup that queue.
>

No - once there's EOS on a pad, there won't be any more data to trigger
handle_mq_input again. There's also a second problem - once EOS has passed on
the mq sink pad, all further events that aren't either flush-start or
stream-start are discarded by the pad.

I think when handling the unblock event on any mq srcpad, it needs to iterate
the other contexts and check if their mq srcpad has GST_PAD_FLAG_EOS without
ctx->out_eos - i.e., was the pad at EOS but hasn't sent an EOS in this
fragment.

If the iterator then sets ctx->out_eos as normal, we can still be sure that one
and only one EOS is sent per pad.

> If you're happy with the patch, could you please push it, I don't have
> permission for that. Thanks.

Are you OK to work on that extra lock? A unit test would, of course, also be
cool if you're up for that.

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