[FFmpeg-devel] [PATCH] dashenc: check pts to prevent division by zero error
Jeyapal, Karthick
kjeyapal at akamai.com
Fri Jan 31 15:08:41 EET 2020
On 1/30/20 3:28 PM, Alfred E. Heggestad wrote:
> this usecase will cause a division by zero trap:
>
> 1. dashenc has received one frame
> 2. os->max_pts and os->start_pts have same value
> 3. delta between max_pts and start_pts is 0
> 4. av_rescale_q(0, x, y) returns 0
> 5. this value is used as denominator in division
> 6. Bang! -> segfault
>
> this fix checks that max_pts > start_pts.
> the fix has been tested and works.
>
> please review and suggest better fixes.
>
> Signed-off-by: Alfred E. Heggestad <alfred.heggestad at gmail.com>
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index f555f208a7..3b651b9514 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1883,7 +1883,7 @@ static int dash_flush(AVFormatContext *s, int
> final, int stream)
>
> st->time_base,
>
> AV_TIME_BASE_Q));
>
> - if (!os->muxer_overhead)
> + if (!os->muxer_overhead && os->max_pts > os->start_pts)
> os->muxer_overhead = ((int64_t) (range_length -
> os->total_pkt_size) *
> 8 * AV_TIME_BASE) /
> av_rescale_q(os->max_pts - os->start_pts,
LGTM.
This actually exposes a corner case bug in overhead calculation logic.
Guess we will need to come up with a better logic for it.
Until then, this fix will atleast make sure things don’t crash.
Thanks,
Karthick
More information about the ffmpeg-devel
mailing list