Should fix ticket #9622 Signed-off-by: James Almer <jamr...@gmail.com> --- I'm not sure if this is ok or not. The AV_PKT_DATA_SKIP_SAMPLES doxy states the skip samples value is a little endian uint32 value, so even if the mov demuxer wrote a truncated int64_t value in sti->skip_samples (which, being an int, can be negative), it would still be "valid" when written into the packet as side data.
Chromium's fix is https://chromium-review.googlesource.com/c/chromium/src/+/3424556 where you can see they have been reading the skip samples value from AV_PKT_DATA_SKIP_SAMPLES as an int. libavformat/demux.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/demux.c b/libavformat/demux.c index f895f0ba85..09d539af68 100644 --- a/libavformat/demux.c +++ b/libavformat/demux.c @@ -1354,6 +1354,7 @@ static int read_frame_internal(AVFormatContext *s, AVPacket *pkt) } if (sti->start_skip_samples && (pkt->pts == 0 || pkt->pts == RELATIVE_TS_BASE)) sti->skip_samples = sti->start_skip_samples; + sti->skip_samples = FFMAX(0, sti->skip_samples); if (sti->skip_samples || discard_padding) { uint8_t *p = av_packet_new_side_data(pkt, AV_PKT_DATA_SKIP_SAMPLES, 10); if (p) { -- 2.34.1 _______________________________________________ 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".