[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 #11 from Jan Schmidt <thaytan at noraisin.net> ---
(In reply to Xavier Claessens from comment #10)
> (In reply to Jan Schmidt from comment #8)
> > Review of attachment 324300 [details] [review] [review]:
> > 
> > Please put some explanation in the commit message. It's always easier to
> > find things in the commit history with better commit messages.
> 
> Right, done.
> 
> > ::: gst/multifile/gstsplitmuxsink.c
> > @@ +1141,3 @@
> > +            splitmux->max_in_running_time);
> > +        event = gst_event_new_gap (pos, GST_CLOCK_TIME_NONE);
> > +        gst_pad_send_event (ctx->sinkpad, event);
> > 
> > How well did you test this, and with which mux formats? I'm not entirely
> > sure it won't introduce actual gaps in the playback of the resulting pieces
> > with at least some formats
> 
> I tested with the command from comment #5. It reliably deadlock without the
> patch, and works fine with it. I didn't notice problems with GAPs recorded,
> but you're right that we should drop those dummy events. Updated the patch
> doing that.
> 
> > @@ +1273,2 @@
> >        (GstPadProbeCallback) handle_mq_input, ctx, (GDestroyNotify)
> >        _pad_block_destroy_sink_notify);
> > 
> > Why did you move the pad probe from the multiqueue sink pad to the ghostpad?
> 
> Added a comment explaining why. I have to send an event into the mq without
> triggering handle_mq_input().

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.

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.

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