2018-09-27 0:15 GMT+02:00, Mark Thompson <[email protected]>: > On 26/09/18 22:43, Carl Eugen Hoyos wrote: >> 2018-09-25 0:16 GMT+02:00, Mark Thompson <[email protected]>: >>> ffmpeg | branch: master | Mark Thompson <[email protected]> | 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.)
But max_br is already unsigned, what's wrong with making cpb_br_nal_factor also unsigned? > I used int64_t because that's the type of bitrate, on the other side of the > comparison. Does that simplify things for the compiler? Thank you for explaining, Carl Eugen _______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
