On Thu, 1 Dec 2022, Chris Ribble wrote:
This reverts commit 03d81a044ad587ea83567f75dc36bc3d64278199.
This change broke the ability to read mp4 files which contain a trun
atom with a sample of size zero (FFmpeg exits while parsing the moof).
Can you explain why those files are considered valid, or why it makes
sense to generate such files?
Thanks,
Marton
Signed-off-by: Chris Ribble <chris.rib...@resi.io>
---
libavformat/mov.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 29bd3103e3..b67b7cd9d2 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5293,8 +5293,6 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
distance++;
if (av_sat_add64(dts, sample_duration) != dts +
(uint64_t)sample_duration)
return AVERROR_INVALIDDATA;
- if (!sample_size)
- return AVERROR_INVALIDDATA;
dts += sample_duration;
offset += sample_size;
sc->data_size += sample_size;
--
2.37.4
_______________________________________________
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".
_______________________________________________
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".
