[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