On 1/31/2020 10:08 AM, Jeyapal, Karthick wrote: > > 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.hegges...@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
Applied. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
