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. _______________________________________________ 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".