[FFmpeg-devel] [FFmpeg-cvslog] avformat/mov: make STTS duration unsigned int

Gyan Doshi ffmpeg at gyani.pro
Mon Nov 22 15:27:32 EET 2021



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 <ffmpeg at 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


More information about the ffmpeg-devel mailing list