Paul B Mahol: > On 8/1/20, Andreas Rheinhardt <andreas.rheinha...@gmail.com> wrote: >> The VLC codes in question originate from a Huffmann tree and so every >> sequence of bits that is longer than the longest code contains an >> initial sequence that is a valid code. Given that it has been checked >> during reading said tree (and once again in ff_init_vlc_sparse()) that >> the length of each code is <= 3 * the number of bits read at once when >> reading codes, get_vlc2() will always find a matching entry. >> >> These checks have been added in 71d3c25a7ef442ac2dd7b6fbf7c489ebc0b58e9b >> at a time when the length of the codes had not been checked when parsing >> the tree. >> >> For GCC 9 and the sample from ticket #2425 this led to a slight >> performance regression: The time for one call to smka_decode_frame() >> increased from 2053671 to 2064529 decicycles; for Clang 9, performance >> improved from 1521288 to 1508459 decicycles. >> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> >> --- >> libavcodec/smacker.c | 32 -------------------------------- >> 1 file changed, 32 deletions(-) >> > > Sure this does not continue under bitstream errors? > > Try some smart fuzzers. > I have now finally fuzzed my patches here and found no bugs at all (neither with ASAN nor with UBSan). I'll therefore apply it.
- Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
