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

[Thilo Borgmann]

Am 01.07.17 um 14:42 schrieb 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.

Do I understand correctly, this patch works with RM22 only and fails on RM23?

-Thilo