[MPlayer-dev-eng] Re: [PATCH] don't skip first mp3 frame

[D Richard Felker III]

On Thu, Jan 06, 2005 at 04:07:23PM +0100, Reimar Döffinger wrote:
> Hi,
> 
> On Thu, Jan 06, 2005 at 03:40:14PM +0100, Jindrich Makovicka wrote:
> > Reimar Döffinger wrote:
> > >On Tue, Jan 04, 2005 at 10:44:40AM +0100, Jindrich Makovicka wrote:
> > >>Reimar Döffinger wrote:
> > >>>Please upload the sample. The samplerate if the first six headers are
> > >>>checked to match by the demuxer, so if there are bogus parameters in the
> > >>>first frame the demuxer should have made sure it will be skipped.
> > >>
> > >>incoming/mp3frame1
> > >
> > >That's an avi, so the change to the audio demuxer did not make a
> > >difference of course...
> > 
> > Yes, I mentioned it in my previous post.
> 
> Just thought I state it clearly...
> 
> > >But the samplerate seems to be detected correctly even without your
> > >patch... Can you explain more what exactly your patch is supposed to do?
> > 
> > Strange, for me, vanilla MPlayer detects 22050 Hz instead of correct 
> > 44100. The patch makes the decoder return samplerate and other stuff 
> > based on the second frame, as in the previous versions which skipped it.
> 
> Yes, you are right... I wonder what exactly is wrong with that first
> frame...
> 
> > >And do you know how that file was created?
> > 
> > tv capture using mencoder, then a part was cut out using avidemux. I 
> > have more files produced by the same means, all of them work. I agree 
> > the file is buggy, but older mplayer releases had no trouble.
> 
> I wonder if it's avidemux that broke it...
> 
> I think this should be fixed in a more general way, as only changing
> ad_mp3lib will still leave decoding with ffmpeg broken...

Are you sure it is broken with ffmpeg? IMO the problem is mp3lib's
broken mp3 header parser. Of course that's also used in the demuxer to
initialize some things, so maybe it's causing problems anywhere.
Anyway, in an otherwise-valid mp3 stream, you can NEVER get something
that parses as a header just by cutting the file somewhere bad.
However, mp3lib/mpg123 is notorious for misdetecting headers when
starting a stream in the middle, e.g. mp3 radio sites.

Anyone who understands the mp3 spec care to debug this?

Rich