Possibly invalid restriction for CTTS sample_offset field

[Robert Swain]

Summary of the bug:

libavformat/mov.c logs an error for a CTTS box sample_offset that is, as far as I can tell, valid according to the ISO/IEC 14496-12 and Apple specifications.

How to reproduce:

The check is here: ​https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/master:/libavformat/mov.c#l3322

         if (FFNABS(duration) < -(1<<28) && i+2<entries) {
             av_log(c->fc, AV_LOG_WARNING, "CTTS invalid\n");
             av_freep(&sc->ctts_data);
             sc->ctts_count = 0;
             return 0;
         }

A slightly different form of the check was originally introduced as a fix for ​https://trac.ffmpeg.org/ticket/385 with the commit message:

commit 4093220029a4d77f272c491e9299680480a08c00
Author: Michael Niedermayer <michael@niedermayer.cc>
Date:   Thu Mar 8 07:10:57 2012 +0100

    mov: Discard invalid CTTS.

    Fixes Ticket385

    Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

There are no comments on the code nor does the commit message nor code explain why the check is correct.

As the Apple specification is publicly and freely available I'll link it here: ​https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-SW19 I wasn't able to find anything in that specification nor in ISO/IEC 14496-12 section 8.6.1.3 about the sample_offset having a reduced range than the data type of the field.

The code enforces that the CTTS box sample_offset (the duration variable in the code in mov.c - also, why is it called duration?) is required to be <= 2^{28. Why is this?}

[Robert Swain]

An additional piece of information about the case I encountered in a different file but that I am unable to share - the video track's mdhd box time_scale field has a value of: 2086482457. The largest ctts sample_offset value in this file is 346769080, which is an unsigned value as the ctts box version is 0 in this file. log2(346769080) ~ 28.3694000241 so just over 28 bits.

[Balling]

How would you fix that? Please note that STTS was recently made unsigned: 203b0e3561dea1ec459be226d805abe73e7535e5 but not everywhere it is handled, see ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211116141533.1708-1-ffmpeg@gyani.pro/

The muxer should be adjusted to be able to write larger durations in the
stts but that's a larger undertaking which I'll do later.

[Balling]

Looks related: #8895

apparently CTTS

since it was written with only MP4 in mind, which only has unsigned value in the CTTS box (MOV can have signed values)

[Balling]

Log2(346769080) ~ 28.3694000241 so just over 28 bits.

Can you provide that file, please?