[FFmpeg-devel] [PATCH] AAC Pulse data boundaries
Mon Sep 15 02:55:39 CEST 2008
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
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.
Just listen to a slightly damaged file to find out which solution sounds
best. This really is the only way to be sure what is best ...
And btw, using get_bits(), a function with "side effects" as argument
to a macro like FFMIN() is a bad idea.
get_bits() > X ? get_bits() : X
is likely not what you meant.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel