[FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Tue Jan 31 02:57:31 EET 2017

On 31.01.2017 00:59, Steinar H. Gunderson wrote:
> On Tue, Jan 31, 2017 at 12:49:56AM +0100, Andreas Cadhalpun wrote:
>>> How can you get a negative run, which would be required for this to happen?
>> Some values in ff_dc_alpha_run_vlc_le.table are negative, e.g.:
>>  ff_dc_alpha_run_vlc_le.table[32] = {-1, 0}
> This sounds like a strangeness in constructing the table, which shouldn't be
> papered over in the inner loop of the decoder.

Maybe, I don't know what the contents of the table should be, but the following
are {-1, 0}: 32, 33, 64, 96, 128

> I might be missing something
> in how this table is used internally in the bitstream reader, but a code of
> 32 should just immediately hit 0 in the LSB and be interpreted as run=0.
> (There are no invalid codes in this VLC, so nothing like run=-1 should ever
> happen.)
> Do you have an actual input where your code makes a difference?

Yes, without this patch ubsan reports:
src/libavcodec/speedhq.c:206:13: runtime error: index -1 out of bounds for type 'uint8_t [128]'

Best regards,

More information about the ffmpeg-devel mailing list