[MPlayer-cvslog] r21666 - trunk/libmpdemux/demux_audio.c

[Reimar Döffinger]

Hello,
On Tue, Dec 19, 2006 at 11:01:01AM -0500, Rich Felker wrote:
> On Mon, Dec 18, 2006 at 09:44:33PM +0100, Michael Niedermayer wrote:
> > On Mon, Dec 18, 2006 at 04:14:23PM +0100, reimar wrote:
> > > Author: reimar
> > > Date: Mon Dec 18 16:14:23 2006
> > > New Revision: 21666
> > > 
> > > Modified:
> > >    trunk/libmpdemux/demux_audio.c
> > > 
> > > Log:
> > > Require 12 consecutive MPEG-audio headers before detecting as audio.
> > > Fixes misdetection of http://samples.mplayerhq.hu/FLV/flv_misdetected_as_mpa
> > 
> > i dont want to complain but there is no real upper bound on how many
> > consecutive valid mp3 frames a container might have ...
> 
> Indeed this is incorrect; I seem to recall the limit once being higher
> and being _lowered_ because some mp3 files were not playable. In any

No, that was not the case. There was a bug in the code that caused
detection to fail though (fix in r15216).
Main point against increasing this is that these frames will be lost for
non-seekable streams and very short files will not be recognized.

> case, a file should always be detected as mp3 when there is an id2v3
> header at the beginning immediately followed by a valid string of mp3
> headers, or when the mp3 headers start at the beginning of the file..

That does not work because there are too many files where the first
headers are broken.
A reduced value if such a code is found very soon in the file could be
considered though.

> And yes if this will misdetect other files then the mp3 detection
> needs to be moved later in the sequence, but not crippled like this!

All demuxers can misdetect with format like MXF that allow random crap
at the start of the file, so should we now try to put all last? Seems
difficult to do...
And moving it below lavf is pointless, then we can just rm it.
How about a patch with a proper solution instead of just stating the
obvious?

Greetings,
Reimar Döffinger