On 2021-11-22 06:50 pm, Michael Niedermayer wrote:
On Mon, Nov 22, 2021 at 02:17:24PM +0100, Michael Niedermayer wrote:
On Mon, Nov 22, 2021 at 09:49:26AM +0000, Gyan Doshi wrote:
ffmpeg | branch: master | Gyan Doshi <ffm...@gyani.pro> | Tue Nov 16 19:02:32
2021 +0530| [203b0e3561dea1ec459be226d805abe73e7535e5] | committer: Gyan Doshi
avformat/mov: make STTS duration unsigned int
As per 8.6.1.2.2 of ISO/IEC 14496-12:2015(E), STTS sample offsets
are to be always stored as uint32_t. So far, they have been signed ints
which led to desync in files with very large offsets.
The MOVStts struct was used to store CTTS offsets as well. These can be
negative in version 1. So a new struct MOVCtts was created and all
declarations for CTTS usage changed to MOVCtts.
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=203b0e3561dea1ec459be226d805abe73e7535e5
---
libavformat/isom.h | 9 +++++++--
libavformat/mov.c | 20 ++++++++++----------
libavformat/movenc.c | 2 +-
3 files changed, 18 insertions(+), 13 deletions(-)
This breaks:
./ffmpeg -i ~/videos/mp4-negative-stts-problem.mp4 -c copy -t 3 -y
file-negstts.mov
https://samples.ffmpeg.org/mov/mp4-negative-stts-problem.mp4
failure happens like this:
[mov @ 0x56332ba06800] Application provided duration: 4294966430 is invalid
That's triggered by this code in lavf/movenc.c
----
if (pkt->duration < 0 || pkt->duration > INT_MAX) {
av_log(s, AV_LOG_ERROR, "Application provided duration:
%"PRId64" is invalid\n", pkt->duration);
return AVERROR(EINVAL);
}
----
Since the spec allows duration up to uint32, the INT_MAX limit is wrong
and is another separate bug.
I'll change that when I correct the muxer.
Regards,
Gyan
_______________________________________________
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".
