[FFmpeg-devel] [PATCH] on2avc: limit number of bits to 30 in get_egolomb

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Thu Dec 17 23:28:29 CET 2015


On 17.12.2015 10:54, Hendrik Leppkes wrote:
> On Wed, Dec 16, 2015 at 8:20 PM, Andreas Cadhalpun
> <andreas.cadhalpun at googlemail.com> wrote:
>> More don't fit into the integer output.
>>
>> Also use get_bits_long, since get_bits only supports reading up to 25
>> bits, while get_bits_long supports the full integer range.
>>
>> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun at googlemail.com>
>> ---
>>  libavcodec/on2avc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
>> index 15f4dd1..10861b5 100644
>> --- a/libavcodec/on2avc.c
>> +++ b/libavcodec/on2avc.c
>> @@ -211,9 +211,9 @@ static inline int get_egolomb(GetBitContext *gb)
>>  {
>>      int v = 4;
>>
>> -    while (get_bits1(gb)) v++;
>> +    while (get_bits1(gb) && v < 30) v++;
>>
>> -    return (1 << v) + get_bits(gb, v);
>> +    return (1 << v) + get_bits_long(gb, v);
>>  }
>>
> 
> Just arbitrarily cutting the read short will make it lose its
> bitstream position. While you may argue that this is likely a broken
> file, maybe you should still consume as much data as the golomb
> indicates, and just cap the return value?

This is a potentially very large (or even infinite) loop, so there has
to be a cutoff somewhere. Otherwise e.g. v could overflow, not to
mention that it could take ages to finish.
Since I don't think that a value larger than an integer is valid here,
I prefer not to worry about supporting such values, until I get to see
a sample, where handling them is useful.

Best regards,
Andreas



More information about the ffmpeg-devel mailing list