[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 #10 from Xavier Claessens <xclaesse at gmail.com> ---
(In reply to Jan Schmidt from comment #8)
> Review of attachment 324300 [details] [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().

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