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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Mar 21 13:44:14 UTC 2016


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

--- Comment #13 from Xavier Claessens <xclaesse at gmail.com> ---
(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.


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

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


More information about the gstreamer-bugs mailing list