GNOME Bugzilla – Bug 734040
tsdemux: Handle sparse streams
Last modified: 2014-10-20 10:36:25 UTC
This bug report is about issues regarding sparse streams (mainly subtitles) 1) tsdemux only exposes pads (of the corresponding streams specified in the PMT) once it sees one PES on it. And only when all pads are added will tsdemux emit no-more pads. => If a sparse stream has the first PES very late, it will either cause decodebin to preroll much later than it could (still haven't emitted no-more-pads), or will arrive after decodebin has prerolled (the pad won't be exposed at all by decodebin, thereby missing the subtitle stream). 2) If we expose all pads at the beginning (and emit no-more-pads), we then have another issue with those sparse stream which is that downstream elements (and potentially the pipeline) won't preroll until we get that very late buffer. => We need to detect that (other/non-sparse) streams have moved forward by a certain amount, and push GAP events at a regular interval. 3) The PES on those sparse streams sometimes don't have a specified size. The current way we decide that we accumulated a whole PES (and push it downstream) is when we see the beginning of the following one on the same stream. The problem with this is that the next PES might be ... much much later, and it will eventually arrive too late for display. => In the same location where we push out GAP events, push out pending PES if there are any.
Work in progress is here : https://github.com/thaytan/gst-plugins-bad/commits/tsdemux-gap
Created attachment 282319 [details] [review] tsdemux: send initial GAP event on sparse streams for faster startup with playbin Signal sparse streams properly in stream-start event and force sending of pending sticky events which have been stored on the pad already and which otherwise would only be sent on the first buffer or serialized event (which means very late in case of subtitle streams). Playsink in playbin waits for stream-start or another serialized event, and if we don't do this it will wait for the multiqueue to run full before starting playback, which might take a couple of seconds.
Review of attachment 282319 [details] [review]: ::: gst/mpegtsdemux/tsdemux.c @@ +1486,3 @@ + if (stream->sparse) { + GST_DEBUG_OBJECT (stream->pad, "sparse stream, pushing GAP event"); + gst_pad_push_event (stream->pad, gst_event_new_gap (0, 0)); why are we passing (0, 0) to gst_event_new_gap()? Shouldn't we at least pass a proper timestamp as start_time?
That's only when the pad was just added. The comment above that line explains why :)
commit 2cd4f5d0c13bb9eaff9ca8303db5b76c9229522d Author: Tim-Philipp Müller <tim@centricular.com> Date: Sat Aug 2 11:29:37 2014 +0100 tsdemux: send initial GAP event on sparse streams for faster startup with playbin Signal sparse streams properly in stream-start event and force sending of pending sticky events which have been stored on the pad already and which otherwise would only be sent on the first buffer or serialized event (which means very late in case of subtitle streams). Playsink in playbin waits for stream-start or another serialized event, and if we don't do this it will wait for the multiqueue to run full before starting playback, which might take a couple of seconds. https://bugzilla.gnome.org/show_bug.cgi?id=734040 commit b59a9262c069d8f0c149ce4c9185c9a439ad6ece Author: Edward Hervey <bilboed@bilboed.com> Date: Mon Oct 20 12:30:50 2014 +0200 tsdemux: GAP detection All pads of a stream are now added at the beginning. In order to cope with streams that don't get any data (forever or for a long time) we detect gaps and push out GAP events when needed. Cleanups and commenting by Jan Schmidt <jan@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=734040