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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Mar 16 12:19:10 UTC 2016


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

--- Comment #4 from Xavier Claessens <xclaesse at gmail.com> ---
(In reply to Jan Schmidt from comment #2)
> (In reply to Xavier Claessens from comment #0)
> > 
> > Note that, even without splitmuxsink, if I understand correctly how
> > GstCollectPads works, it means that muxing a matroska with few subtitles
> > could result in huge memory usage, since it's going to queue video buffers
> > until it gets a subtitle... Imagine a movie that has a long periods with
> > nobody speaking...
> 
> Upstream elements are supposed to send GAP events on subtitle / sparse
> streams so that downstream elements get timely position updates even when
> there are large gaps in the data and avoid that problem.

Ok, fair enough, forget about that part then.

(In reply to Jan Schmidt from comment #3)
> I think the fix for this will be around handling the drained signal for the
> multiqueue when waiting for the fragment to drain out and using that to
> trigger completion as well.

My understanding is that we should send EOS event in all empty queues when
going to SPLITMUX_STATE_ENDING_FILE state. Not sure there is a drain signal
that would be emitted if the queue is already empty when we block in
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