Am 01.07.17 um 19:03 schrieb Paul B Mahol:
> On 7/1/17, Thilo Borgmann <thilo.borgm...@mail.de> wrote:
>> Am 01.07.17 um 14:42 schrieb Paul B Mahol:
>>> On 7/1/17, Michael Niedermayer <mich...@niedermayer.cc> wrote:
>>>> On Sat, Jul 01, 2017 at 02:18:17PM +0200, Paul B Mahol wrote:
>>>>> 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.
>>>>
>>>> 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?
>
> Probably. I can not confirm because I failed to create sample with
> path that triggers this code.
Well it should get applied only if it could properly be tested for both
endianness cases.
-Thilo
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
