On 17.12.2015 10:54, Hendrik Leppkes wrote:
> On Wed, Dec 16, 2015 at 8:20 PM, Andreas Cadhalpun
> <andreas.cadhal...@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.cadhal...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
