After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734040 - tsdemux: Handle sparse streams
tsdemux: Handle sparse streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-31 13:42 UTC by Edward Hervey
Modified: 2014-10-20 10:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tsdemux: send initial GAP event on sparse streams for faster startup with playbin (4.17 KB, patch)
2014-08-02 10:34 UTC, Tim-Philipp Müller
committed Details | Review

Description Edward Hervey 2014-07-31 13:42:36 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.
Comment 1 Edward Hervey 2014-07-31 13:43:36 UTC
Work in progress is here : https://github.com/thaytan/gst-plugins-bad/commits/tsdemux-gap
Comment 2 Tim-Philipp Müller 2014-08-02 10:34:27 UTC
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.
Comment 3 Guillaume Desmottes 2014-09-23 13:46:05 UTC
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?
Comment 4 Edward Hervey 2014-09-23 13:48:13 UTC
That's only when the pad was just added. The comment above that line explains why :)
Comment 5 Edward Hervey 2014-10-20 10:36:13 UTC
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