[MPlayer-dev-eng] [PATCH] Fix hang on demux of matroska files with 0byte-ints using 'mkv' demuxer

[Michael Niedermayer]

On Thu, Oct 07, 2010 at 08:17:29AM +0200, Reimar Döffinger wrote:
> On Thu, Oct 07, 2010 at 03:13:54AM +0200, Michael Niedermayer wrote:
> > On Sun, Sep 05, 2010 at 11:36:06AM +0200, Reimar Döffinger wrote:
> > > On Wed, Sep 01, 2010 at 12:00:42AM +0200, Aurelien Jacobs wrote:
> > > > On Sun, Aug 29, 2010 at 06:28:39PM +0200, Sebastian Hagen wrote:
> > > > > Hello *,
> > > > > 
> > > > > Mplayer's 'mkv' matroska file demuxer has a bug preventing it from
> > > > > parsing integers with a length of 0 bytes correctly, even though those
> > > > > are valid according to the Matroska specs[1]. Thus, attempting to play
> > > > > mkv files containing such integers without explicitly specifying
> > > > > '-demuxer lavf' will result in an mplayer hang on demux.
> > > > 
> > > > What are you talking about exactly ?
> > > > '-demuxer lavf' is the default behavior.
> > > > And if you are using '-demuxer mkv', you are explicitly asking for
> > > > trouble...
> > > 
> > > Could you please have a look that there's nothing _obvious_ wrong
> > > with the patch?
> > > And then let's just apply all these patches, even with lavf the default
> > > it is easy enough for a malicious file to manage to end up with the mkv
> > > demuxer by failing with the lavf one, and I don't think completely
> > > removing the native one is an option, so we really can't just leave
> > > these things.
> > 
> > why is completely removing the native one not an option?
> 
> Two reasons: rc4 will be used together with FFmpeg 0.6 where the demuxer
> has a load of issues still, so we have to maintain it for that anyway.

drop support for 0.6 then, or send a patch to backport the fixes to 0.6
and make sure mplayer requires the updated 0.6
I can talk with the 0.6 people if they dont like the patch but i see no
reason why they wouldnt, the backported other fixes


> Then there's the MAX_STREAMS issues that will not be fixed until the
> next major bump.

mplayer can bump it locally, especially with aurels spliting of different
ABI parts you can enable just the MAX_STREAMS. of course that would mean
no shared libav*, i prefer the times when shared wasnt supported in a way
that blocked moving forward

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20101007/b5c0f71b/attachment.pgp>