[MPlayer-cvslog] CVS: main/libmpdemux demux_audio.c,1.32,1.33

[Rich Felker]

On Mon, Apr 18, 2005 at 09:57:08AM +0200, Reimar D?nger wrote:
> Hi,
> > > It's not quite as bad as before where some files would not play at all,
> > > but still...
> > 
> > Well your code was definitely broken. Not only was it incredibly slow;
> > I have a perfectly valid cbr 128kbit mp3 file that WILL NOT PLAY with
> > your code due to it making up artificial mp1 headers in the middle of
> > the mp3...
> 
> My problem is that I cannot see how that code could have this effect
> - unless the added support for mp1 and mp2 broke it??

Yes. The bug in your code did not cause problems until mp1/2 support
was added.

> It sure will find invalid headers, but they should be "forgotten"
> after seeing that it is not a mp1/mp2 file.

Well, they're not. They break the header-chain and prevent it from
ever finding MIN_MP3_HDRS consecutive compatible headers.

> Concerning the high CPU usage at he beginning: This stems from
> brute-force scanning up to the first 30k of the file - but this is
> tuneable by both modifiying the n < 30000 comparison in the loop and
> the MIN_MP3_HDRS define.

An acceptable alternative would be brute force scanning, but only
considering header _chains_ in deciding what type the file is
(sequences of headers each pointing to the next one, or at least to a
point before the next one). If you have better ideas I'm welcome to
hear them. But breaking playback of 100% valid cbr mp3 files (which
happened in my case) for the sake of supporting shitty broken files
with random data all over them is not acceptable.

Rich