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 682276 - matroskademux: Discards all video until the first keyframe, even if container keyframe information is wrong
matroskademux: Discards all video until the first keyframe, even if container...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.0.2
Other Linux
: Normal normal
: 1.2.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-20 15:55 UTC by Arnaud Vrac
Modified: 2014-04-07 20:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Arnaud Vrac 2012-08-20 15:55:40 UTC 
Hi,

The following file (60MB) will not preroll when the video pad is connected:

http://absolut.zogzog.org/share/samples/mkv/tlf-terminator.2.judgment.day.720bd.sample.mkv

The video track is detected and caps are set, however no data is ever sent on the pad. The video plays fine with VLC or mplayer.
Comment 1 Edward Hervey 2012-09-14 07:30:41 UTC 
Confirmed, it times out with gst-discoverer-1.0 <file>
Comment 2 Edward Hervey 2012-09-14 07:40:03 UTC 
there is indeed something wrong, just doing matroskademux ! video/x-h264 ! fakesink results in the following output:

E (type: stream-start
E (type: caps
E (type: segment
E (type: tag
E (type: tag
E (type: segment
E (type: eos

with no buffers outputted
Comment 3 Debarshi Ray 2012-11-02 23:57:49 UTC 
Still present in 1.0.2.
Comment 4 Mark Nauwelaerts 2013-02-25 20:52:06 UTC 
This pretty much looks like bug #580980, and is likely due to matroskademux discarding (video) data until it comes across a keyframe.

It seems to be the only demuxer doing so (?), and IMHO trying to cater that much for (broken?) subsequent decoder likely creates more problems (such as this) than it avoids ...
Comment 5 Tim-Philipp Müller 2013-02-25 20:57:47 UTC 
I think I agree with you there.

(And in that scenario it could probably even detect the absence of keyframes in the index and conclude that something is not right, but may just as well let the parser and/or decoder handle it.)
Comment 6 Sebastian Dröge (slomo) 2013-02-26 08:13:40 UTC 
It is the only demuxer currently doing that but it would be useful to have that in other demuxers too. It's something that the decoder can't really do, the decoder still needs to decode all frames even if the QoS earliest_time is far in the future because it doesn't know when the next keyframe would be.
Comment 7 Sebastian Dröge (slomo) 2014-01-15 21:51:30 UTC 
My comment 6 does not make any sense at all, it must've been for another bug. Let's just fix this :)

commit 809d1059820aae5eec87ebffbd1608c12c44575d
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Jan 15 22:47:12 2014 +0100

    matroskademux: Don't skip all video frames until the first keyframe
    
    Instead do it like all other demuxers and let parsers and decoders
    handle that. The keyframe information inside the container might
    be completely wrong like in the sample file of the bug report,
    and if it is correct and we push no keyframes, then the parsers
    and decoders will handle that properly anyway.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=682276
Comment 8 Jürg Billeter 2014-04-07 20:45:57 UTC 
This change might have introduced a crash. See bug 727779.