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

[Robert Swain]

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