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

[Zdenek Kabelac]

2009/4/30 Michael Niedermayer <michaelni at gmx.at>:
> 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
>

Yep - thanks for the hint  - it always good to learn yet another container.

upload.ffmpeg.org:/MPlayer/incoming/error_antiradar


Zdenek