[Bug 763711] splitmuxsink: deadlock when one streams doesn't have regular buffers
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun Mar 20 20:36:57 UTC 2016
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.
More information about the gstreamer-bugs
mailing list