2018-09-25 0:16 GMT+02:00, Mark Thompson <g...@videolan.org>: > ffmpeg | branch: master | Mark Thompson <s...@jkqxz.net> | Mon Sep 24 23:03:32 > 2018 +0100| [581b4125aa187f2cf848d7a27e6128573c80dc64] | committer: Mark > Thompson > > lavc/h264_levels: Avoid integer overflow in bitrate > > Fixes CID #1439656. > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=581b4125aa187f2cf848d7a27e6128573c80dc64 > --- > > libavcodec/h264_levels.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c > index 6b4e18a914..737b7dcf06 100644 > --- a/libavcodec/h264_levels.c > +++ b/libavcodec/h264_levels.c > @@ -105,7 +105,7 @@ const H264LevelDescriptor *ff_h264_guess_level(int > profile_idc, > if (level->constraint_set3_flag && no_cs3f) > continue; > > - if (bitrate > level->max_br * h264_get_br_factor(profile_idc)) > + if (bitrate > (int64_t)level->max_br * > h264_get_br_factor(profile_idc))
If the overflow is possible at all (I doubt it), wouldn't it be cleaner to change the type of cpb_br_nal_factor to uint32_t? Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
