[FFmpeg-devel] [PATCH] avcodec/mlz: simplify

[Paul B Mahol]

On 7/1/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Sat, Jul 01, 2017 at 02:18:17PM +0200, Paul B Mahol wrote:
>> On 7/1/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> > On Sat, Jul 01, 2017 at 12:05:52PM +0200, Paul B Mahol wrote:
>> >> Signed-off-by: Paul B Mahol <onemda at 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.
>
> ok, but please change the commit message then as the code before and
> afterwards dont read in the same endianness so this is not a
> simplification but a bugfix then

Hmm, on second look you are probably right.
They changed to this in R23 version and I failed to create file that
triggers this path.
So I will not apply this mostly because R23 support needs more work.