[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