[FFmpeg-devel] [PATCH] AAC Pulse data boundaries

Robert Swain robert.swain
Mon Sep 15 20:48:30 CEST 2008


2008/9/15 Michael Niedermayer <michaelni at gmx.at>:
> On Sun, Sep 14, 2008 at 10:48:17PM -0400, Alex Converse wrote:
>> On Sun, Sep 14, 2008 at 8:55 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
>>
>> > On Mon, Sep 15, 2008 at 12:36:21AM +0100, Robert Swain wrote:
>> > > 2008/9/14 Alex Converse <alex.converse at gmail.com>:
>> > > > Currently the AAC pulse_data tool can try to apply pulses to offsets
>> > outside
>> > > > of the boundaries of the spectral coefficients. This leads to a crash
>> > > > (SIGSEGV) with a stream generated wit the following command:
>> > > > zzuf -s16 -r0.001:0.1 -b1193- <
>> > > > mpeg4audio-conformance/compressedMp4/al04_08.mp4 > fuzzed.mp4
>> > > >
>> > > > Attached is a patch to clip pulse positioning to 1023.
>> > >
>> > > The code changes look OK but is clipping the best solution to this or
>> > > should those pulses rather be discarded? Michael?
>> > >
>> > > It would seem to me that if there are multiple pulses, clipping them
>> > > could lead to multiple pulses being applied to position 1023. Is a
>> > > spike in the spectral data better than no spike or vice versa? My
>> > > guess is that ignoring incorrectly positioned pulses may be a better
>> > > option.
>> >
>> > Well as you ask :)
>> > Bitstream errors should cause the data until the next resync possibility
>> > to be discarded. It also should discard some of the pevious data as the
>> > bitstream error likely happened earlier.
>> > In practice that likely means replacing the current frame by silence, that
>> > is before the windowing. Or maybe to duplicate the last frame.
>> >
>>
>> I was under the impression that the MPEG-4 Visual decoder accepts all kinds
>> of things that aren't quite legal.
>
> There are 2 different things
> 1. invalid bitstreams due to buggy encoders
> 2. invalid bitstreams due to bit/byte/block/sector/packet damage.
>
> Until we have seen a buggy encoder encoding invalid pulses its IMO
> reasonable to assume that no such encoder exists, if one does we
> will get a bugreport and can adapt our decoder.
> And if needed use error_recognition to decide where to draw the line
> between points 1 and 2.

How does this work? Count up invalid values and if the number of
invalid values read exceeds some threshold then the frame gets
discarded?

Rob




More information about the ffmpeg-devel mailing list