#2016 closed defect (invalid)
Mplayer crashes with certain chapter information in mkv files
| Reported by: | Owned by: | reimar | |
|---|---|---|---|
| Priority: | normal | Component: | demuxer |
| Version: | unspecified | Severity: | major |
| Keywords: | Cc: | cehoyos | |
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
Description
Crash looks like this:
$ mplayer out.mkv
MPlayer SVN-r33094-4.5.3 (C) 2000-2011 MPlayer Team
Playing out.mkv.
Cache fill: 11.38% (1966080 bytes)
libavformat file format detected.
Cache not filling, consider increasing -cache and/or -cache-min!
[matroska,webm @ 0x18e4ac0] Estimating duration from bitrate, this may be inaccurate
mplayer: utils.c:2175: compute_chapters_end: Assertion `s->chapters[i]->start <= s->chapters[i+1]->start' failed.
MPlayer interrupted by signal 6 in module: demux_open
- MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.
I managed to fix this crash by editing mkv file in question. I extracted chapters and removed second EditionEntry tag. There seemed to be a similar bug in ffpmeg code (same assertion) some time ago, but there was not enough information so the bug was closed[1]. I attach both original and fixed chapters.xml. I might be able to create a small sample if need be, but I guess this could be enough information to get you started. If you need more information, let me know.
Attachments (3)
Change History (10)
by , 12 years ago
| Attachment: | chapters.xml added |
|---|
by , 12 years ago
| Attachment: | chapters-fixed.xml added |
|---|
fixed chapters that work when merged with original mkv file
comment:1 by , 12 years ago
comment:2 by , 12 years ago
| Component: | vd → demuxer |
|---|
Mistakenly set component to vd, resetting to demuxer
comment:3 by , 12 years ago
| Cc: | added |
|---|
Is the crash also reproducible with FFmpeg?
If yes, please open a ticket on https://ffmpeg.org/trac/ffmpeg
Please upload a sample to http://www.datafilehost.com/ and post the download link here.
comment:4 by , 12 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
This was fixed in FFmpeg on April 1st, and the assert that causes the printout does not exist at all anymore.
Using MPlayer with such a heavily outdated FFmpeg is very much _not_ supported (in addition to not recommended).
comment:5 by , 12 years ago
Forgot to mention: FFmpeg commit ab11317c1f97db19eddebe1bc5d4cb5a53718c9f fixed it.
comment:6 by , 12 years ago
Indeed, you were right. Even though ffmpeg on my system is 0.7.7, mplayer package used bundled pre-0.7 version (I guess a problem of the packager here...)
Just in case anyone is interested, the sample file causing this is uploaded:
http://www.datafilehost.com/download-963a6caa.html
I tracked the bug to two chapters having the same UID, and some additional conditions had to be met (those 2 with same UID had to be in different EditionEntry subtags, and apparently there had to be one more chapter). I am attaching minimum reproducing chapters xml file.
For the record I was able to normally play the file with ffplay so it is really just the bundled ffmpeg that has the problem.
original chapters.xml that causes problems