[FFmpeg-devel] [PATCH 2/2] avformat_seek_file: Dont attempt to rescale INT64_MIN/MAX

Clément Bœsch ubitux at gmail.com
Wed Jan 2 23:52:18 CET 2013


On Wed, Jan 02, 2013 at 11:33:00PM +0100, Michael Niedermayer wrote:
> This fixes a integer overflow in fate
> 
> Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> ---
>  libavformat/utils.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index cbf3263..096bb82 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2092,10 +2092,10 @@ int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, int
>              ts = av_rescale_q(ts, AV_TIME_BASE_Q, time_base);
>              min_ts = av_rescale_rnd(min_ts, time_base.den,
>                                      time_base.num * (int64_t)AV_TIME_BASE,
> -                                    AV_ROUND_UP);
> +                                    AV_ROUND_UP   | AV_ROUND_PASS_MINMAX);
>              max_ts = av_rescale_rnd(max_ts, time_base.den,
>                                      time_base.num * (int64_t)AV_TIME_BASE,
> -                                    AV_ROUND_DOWN);
> +                                    AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX);
>          }
>  
>          ret = s->iformat->read_seek2(s, stream_index, min_ts, ts, max_ts, flags);

This patch and the previous one LGTM, but please say somewhere what happen
when the min/max limits are passed (a comment in the code here, in rescale
function, in the flag documentation, or even just as a commit description,
wherever you want, but at least somewhere once).

(doesn't affect FATE?)

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130102/0e65a7be/attachment.asc>


More information about the ffmpeg-devel mailing list