[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