[FFmpeg-devel] [PATCH] fix parsing of broken mp3 streams

[Michael Niedermayer]

On Thu, Apr 30, 2009 at 01:46:40PM +0200, Zdenek Kabelac wrote:
> 2009/4/30 Michael Niedermayer <michaelni at gmx.at>:
> > On Wed, Apr 29, 2009 at 11:24:56PM +0200, Zdenek Kabelac wrote:
> >> 2009/4/23 Michael Niedermayer <michaelni at gmx.at>:
> >> > On Thu, Apr 23, 2009 at 10:27:58AM +0200, Zdenek Kabelac wrote:
> >> >> 2009/4/22 Michael Niedermayer <michaelni at gmx.at>:
> > [...]
> >> > please start a new thread for each individual thing and keep on topic
> >> > api inconsistencies, handling of multiple mp3 frames, avi vbr mp3 muxing,
> >> > invalid mp3 frame handling, hacking apiexample, passing more than 1 frame
> >> > to decoders, fixing a bug in the mp3 decoder, ......
> >>
> >> I've found some time to look deeper into the issue of those missing mp3 packets.
> >>
> >> My original patch was fixing decoder (and I still IMHO think it should
> >> be applied - as there is no reason to keep unlimited buffer scanning -
> >> just look into the code - it really is a bug to scan buffer and not
> >> decrease the buffer size counter - I'm really puzzled why it takes so
> >> much to fix such simple code ?)
> >
> > Because the order is
> > 1. description of the problem
> > 2. reproduceable test case
> > 3. analysis of the problem, that is understanding what happens and what is
> > ? wrong
> > 4. finding a solution
> > 5. implementing the solution
> >
> > you present us with 5. and its up to us to interpolate 1-4 from that and
> > in addition you argue about weird missuses of the API that may or may not
> > be related to the whole.
> > My experience shows that patches that fix such mysterious bugs are most
> > of the time worse than the code before.
> >
> >
> >>
> >> The reason why ffmpeg doesn't see it as a problem is - its' using
> >> mpegaudio_parser.c which I've missed to check - my fault.
> >> Thus ffmpeg will not push broken data to decoder without a real mp3
> >> packet inside - thus the problem has no chance to show in ffmpeg.
> >
> > thats is nonsese, there are containers that do not use a parser for mp3
> > and this makes me feel another step more uneasy about the patch
> 
> My main concern was about different result from parsing .avi streams -
> but in this case ffmpeg uses mpegaudio_parser.c to parse mp3 stream,
> thus if you know the format which is accessing directly codec and
> doesn't go through this parser file - I'll be probably able to create

nut does not require a parser

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

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090430/103b3285/attachment.pgp>