On 31/01/2020 14:17, James Almer wrote:
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.
Great!
Thanks Jeyapal and James.
/alfred
_______________________________________________
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".
