On 26/09/18 22:43, Carl Eugen Hoyos wrote: > 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?
Some of the largest cases overflow 32-bit signed int - e.g. level 6.2 in High 10 allows up to 800000 * 3600 = 2880000000 bps. (High profile or lower doesn't have a cpbBrNalFactor large enough to hit this case.) I used int64_t because that's the type of bitrate, on the other side of the comparison. Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel