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