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?
-Thilo
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
