On 7/1/17, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Sat, Jul 01, 2017 at 12:05:52PM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol <one...@gmail.com>
>> ---
>> libavcodec/mlz.c | 7 +------
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/libavcodec/mlz.c b/libavcodec/mlz.c
>> index ebce796..715ea5c 100644
>> --- a/libavcodec/mlz.c
>> +++ b/libavcodec/mlz.c
>> @@ -112,12 +112,7 @@ static int decode_string(MLZ* mlz, unsigned char
>> *buff, int string_code, int *fi
>> }
>>
>> static int input_code(GetBitContext* gb, int len) {
>> - int tmp_code = 0;
>> - int i;
>> - for (i = 0; i < len; ++i) {
>> - tmp_code |= get_bits1(gb) << i;
>> - }
>> - return tmp_code;
>> + return get_bitsz(gb, len);
>
> have you tested this ? (seems not triggered in fate, i ve only found
> fuzzed samples that trigger this with len >= 1 quickly)
> isnt this the opposite endianness ?
I created file with 22rev2 als encoder and decoding produce same hash,
before and after this patch.
ALS uses big endian bit reader.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
