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 735833 - matroskademux: parse error at end of file
matroskademux: parse error at end of file
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.4.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-09-01 17:36 UTC by Arnaud Vrac
Modified: 2014-09-11 14:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
matroska-demux: Don't handle parse errors at the end of file as an error (2.33 KB, patch)
2014-09-04 13:22 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Arnaud Vrac 2014-09-01 17:36:10 UTC
The last seconds of the following mkv file are not played in push mode because of a parse error:

http://absolut.zogzog.org/share/samples/mkv/Samurai_Champloo_10_%5bBlu-Ray%5d%5b720p%5d%5bnirvanaj%5d.mkv

I've checked the file with mkvinfo (from mkvtoolnix utilities), and indeed the file should be 365173088 bytes long, when it is actually 365173111. It seems there are 23 bytes of 0 padded at the end of the file, I'm not sure it's valid.

Anyway, the demuxer just makes playback abort abruptly when the parse error happens, without first flushing the pipeline, so a few seconds of video and audio is lost. So two things here:

 - could the parse error be avoided ?
 - could the pipeline be drained before sending an error ?
Comment 1 Sebastian Dröge (slomo) 2014-09-02 06:40:48 UTC
matroskademux and our demuxers in general should probably be a bit more tolerant to errors, and not error out immediately on the first error they see but try to resynchronize.
Comment 2 Arnaud Vrac 2014-09-02 09:35:49 UTC
Note that in this case matroskademux does try to skip to the next cluster, but this fallback code does not handle EOS it seems.
Comment 3 Sebastian Dröge (slomo) 2014-09-04 07:49:19 UTC
I can't download the file, it just gives a 403 forbidden.
Comment 4 Arnaud Vrac 2014-09-04 08:08:30 UTC
Sorry it's working now
Comment 5 Sebastian Dröge (slomo) 2014-09-04 08:49:45 UTC
Thanks. You're right, it tries that already but does not consider EOS as non-error.
Comment 6 Sebastian Dröge (slomo) 2014-09-04 13:22:07 UTC
Created attachment 285371 [details] [review]
matroska-demux: Don't handle parse errors at the end of file as an error
Comment 7 Sebastian Dröge (slomo) 2014-09-04 13:23:37 UTC
Now this only has the side effect that we won't report an error either if there is some useable media at the beginning, followed by a few hundred MB of garbage. Not sure what to do about this.
Comment 8 Arnaud Vrac 2014-09-04 13:37:14 UTC
Could we use the top Segment size and not try to skip to a Cluster after this size ?

For example, for this file we have:

* Filesize is 365173111
* Segment start at 40, header 12, size 365173036 -> ends at 365173088
* Last Cluster ends at 365168693, then you have Cues that end at 365173088

So in this case we could stop searching for Clusters at 365173088, and ignore the garbage at the end completely.
Comment 9 Arnaud Vrac 2014-09-04 15:24:17 UTC
BTW this would also fix the issue in push mode.
Comment 10 Sebastian Dröge (slomo) 2014-09-05 08:37:09 UTC
This here now ignores errors, but only if they happen after the segment.

commit a3a5530518a74c57be982c0a68776dda23e3edca
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Thu Sep 4 16:21:20 2014 +0300

    matroska-demux: Don't handle parse errors at the end of file as an error
    
    But only if they happen after the Matroska segment.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=735833
Comment 11 Sebastian Dröge (slomo) 2014-09-05 08:38:19 UTC
In push mode too btw