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 617563 - matroskademux: pelicula.mkv doesn't preroll/play due to audio track without data
matroskademux: pelicula.mkv doesn't preroll/play due to audio track without data
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.x
Other Linux
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-03 19:32 UTC by Cristian Aravena Romero
Modified: 2016-02-16 17:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30



Description Cristian Aravena Romero 2010-05-03 19:32:48 UTC
Open Bug in Launchpad
https://bugs.launchpad.net/bugs/574712

"Not work totem with movie. With VLC work fine"

Movie: http://launchpadlibrarian.net/47627924/pelicula.mkv
Comment 1 Tim-Philipp Müller 2010-05-03 19:53:04 UTC
The file advertises an AC-3 audio track, but there's not actually any audio data in the file, so the pipeline never prerolls. Not really sure who's fault this is - matroskademux? playbin2?
Comment 2 Cristian Aravena Romero 2010-05-03 21:04:46 UTC
$ dpkg -l | grep gstreamer0.10-plugins-base
ii  gstreamer0.10-plugins-base            0.10.28-1                                       GStreamer plugins from the "base" set
ii  gstreamer0.10-plugins-base-apps       0.10.28-1                                       GStreamer helper programs from the "base" se
Comment 3 Sebastian Dröge (slomo) 2010-05-05 12:21:31 UTC
(In reply to comment #1)
> The file advertises an AC-3 audio track, but there's not actually any audio
> data in the file, so the pipeline never prerolls. Not really sure who's fault
> this is - matroskademux? playbin2?

I guess this should be fixed in decodebin2... if a pad was exposed but never had data while all other pads had a lot of data (maybe 1-2s of data?) it should be removed again.
Comment 4 Wim Taymans 2010-05-13 11:08:05 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > The file advertises an AC-3 audio track, but there's not actually any audio
> > data in the file, so the pipeline never prerolls. Not really sure who's fault
> > this is - matroskademux? playbin2?
> 
> I guess this should be fixed in decodebin2... if a pad was exposed but never
> had data while all other pads had a lot of data (maybe 1-2s of data?) it should
> be removed again.

This is going to be tricky, when the demuxer fired no_more_pads, we link the sinks and stop looking for the queue overrun signals..
Comment 5 Cristian Aravena Romero 2011-06-06 13:42:43 UTC
See bug 651968
Comment 6 Vincent Penquerc'h 2011-08-18 17:05:23 UTC
> I guess this should be fixed in decodebin2... if a pad was exposed but never
> had data while all other pads had a lot of data (maybe 1-2s of data?) it should
> be removed again.

We'd need that "sparse" event then, so as to avoid removing subtitles and the like which might not come through till after a good while.
Comment 7 Tim-Philipp Müller 2012-10-03 23:30:31 UTC
I think the demuxer should send a GAP event here, and that should make everything and the audio sink preroll as if there was silence data. Also see bug #685273 (Pre-rolling on GAP events doesn't work properly for audio sinks).
Comment 8 Tim-Philipp Müller 2016-02-16 17:32:47 UTC
Plays 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