[PATCH] hang in demux_mkv

[sh_fs_mplayer@…]

According to the EBML specs, both signed and unsigned MKV data integers have a possible length from 0 to 8 bytes, inclusive. In particular, integers with a length of 0 bytes are valid both for signed and unsigned values, and are defined to have a value of 0 in both cases[1].

Current mplayer versions do not correctly deal with 0-byte integers in MKV files. When encountering such a value, mplayer will enter a busy loop, preventing further parsing of the MKV file in question and also wasting cputime until the process is terminated through external means. This problem will occur with both the 'lavf' and the 'mkv' mkv demuxer, since they use the same code for EBML integer value parsing.
What this comes down to is that there are valid MKV files that will be played back correctly by other software but will hang mplayer, even though parsing them correctly is not difficult.

I am attaching a small MKV file (without any actual data streams) that triggers the uint part of this bug in current mplayer SVN (i.e. rev 31906) for verification purposes.

The problem is caused by lack of support for 0-length values in ebml_read_uint() and ebml_read_int() in libmpdemux/ebml.c, and can be easily fixed for both cases. I'll follow up with a simple patch that does this.

[1] <​http://www.matroska.org/technical/specs/rfc/index.html>, section 2.4.

[sh_fs_mplayer@…]

Demonstration matroska file

[sh_fs_mplayer@…]

Proposed patch

[sh_fs_mplayer@…]

Here's my proposed patch.

[sh_fs_mplayer@…]

Quick correction: The LAVF demuxer is actually not affected by this, and mplayer will play mkv files containing 0byte-ints fine if started using '-demuxer lavf' or with an equivalent config file option.
In absence of any such options (or with '-demuxer mkv') however, the current svn version of mplayer (r:32033) will hang when pointed at a problematic mkv file.

[compn]

lavf mkv demuxer is now default so this probably wont be fixed any time soon.