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 709839 - matroskademux: file with late audio stream start does not preroll
matroskademux: file with late audio stream start does not preroll
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.0
Other Linux
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-10 16:51 UTC by Arnaud Vrac
Modified: 2016-02-16 17:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Arnaud Vrac 2013-10-10 16:51:41 UTC
The following pipeline does not preroll:

gst-launch-1.0 playbin uri=http://absolut.zogzog.org/share/samples/mkv/mohicans.mkv

This is because the first audio buffer is at 13 seconds, so the queues get filled while prerolling. Could this be detected and fixed by sending a gap event ?

Note that this bug happens both in push and pull mode.
Comment 1 Thiago Sousa Santos 2013-11-06 02:57:08 UTC
I think a good solution would be to solve this in multiqueue, so it gets solved for all demuxers. Maybe have some startup state where the queues can grow infinitely until all sink pads have received data?

This would care for the delayed start of streams, but wouldn't solve for delays caused by bad interleaving of data.

A quick hack can also be to let matroskademux do its sync stream operation on all streams instead of only on subtitles while it is starting (no buffers found for all streams).
Comment 2 Sebastian Dröge (slomo) 2013-11-06 15:32:12 UTC
multiqueue already does that, the single queues are growing automatically until everything is pre-rolled.
Comment 3 Thiago Sousa Santos 2013-11-07 00:13:18 UTC
(In reply to comment #2)
> multiqueue already does that, the single queues are growing automatically until
> everything is pre-rolled.

<multiqueue0> queue 0: visible 76/76, bytes 2149428/2097152, time 2960000000/0

This queue is getting blocked after some time, the other queues haven't received any data yet. And the video stream is blocked at 0:00:03.160000000, it should go up to 13s before audio is received. That seems a lot to have buffered anyway.
Comment 4 Sebastian Dröge (slomo) 2013-11-11 14:05:12 UTC
Check the extra-size-* properties on multiqueue and how it e.g. increases max_size.visible in a few places. That's trying to make this work to a certain limit.
Comment 5 Sebastian Dröge (slomo) 2014-01-07 16:32:17 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=719893#c7  maybe related
Comment 6 Sebastian Dröge (slomo) 2014-01-14 19:21:42 UTC
The extra-size-* properties are not used and implemented currently. And multiqueue only increases the buffer limit until either a) none of the other single queues is empty, or b) the time or bytes limit is reached. Does this help?
Comment 7 Tim-Philipp Müller 2016-02-16 17:31:10 UTC
Seems to work fine for me now after

commit 77403d0afee635f2de6c2e53a23e1f50ad0d00fa
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Fri Aug 21 14:15:18 2015 +0100

    matroska-demux: send GAP events for lagging audio and video streams too
    
    Send GAP events for non-subtitle streams too if they lag too much
    behind, but use a higher threshold than for subtitles.
    
    This helps with fixing prerolling with a file where one of the
    audio streams only has data starting from 19s onwards. It's not
    a complete fix yet, it also requires changes elsewhere, such as
    in baseparse, to make sure caps are propagated.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=614460
    https://bugzilla.gnome.org/show_bug.cgi?id=753899