[FFmpeg-devel] [FFmpeg-cvslog] avformat/mov: make STTS duration unsigned int
Gyan Doshi
ffmpeg at gyani.pro
Mon Nov 22 17:06:30 EET 2021
On 2021-11-22 07:29 pm, Michael Niedermayer wrote:
> On Mon, Nov 22, 2021 at 06:57:32PM +0530, Gyan Doshi wrote:
>>
>> 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.
> this problem seems unrelated to the mov muxer, here framecrc is used instead
> of mov, it fails too and framecrc is happily accepting the wrong duration
The original error msg you posted is printed by the mov muxer and is
caused by the code block I pasted.
> ./ffmpeg -i ~/videos/mp4-negative-stts-problem.mp4 -c copy -t 3 -y -f framecrc -
>
> you can see here that the audio stream is truncated once the
> wrong duration occurs
That's due to interleaving and can be reproduced by a very large and
legal timestamp jump in one of the streams.
In mp4-negative-stts-problem.mp4, if I change the duration at offset
0x149ACB7 from FFFFFC9E to 0FFFFC9E
so it's a valid duration pre-patch, you get the same behaviour with framecrc
ffmpeg-4.4.1.exe -i mp4-negative-stts-problem-patched.mp4 -c copy -t 3 -y -f framecrc -
gives
0, 0, 0, 6399, 15493, 0x1bf11e9800
bitrate=248800.0kbits/s speed=N/A
1, 0, 0, 1023, 318, 0xe8c195ad
1, 1023, 1023, 1023, 543, 0x0d7b1ba9
1, 2046, 2046, 2362, 540, 0x71401059
0, 6399, 6399, 6399, 10770, 0x819bf607, F=0x0
1, 4408, 4408, 1023, 196, 0x19246a78
1, 5431, 5431, 1023, 453, 0xff79e208
0, 12798, 12798, 6399, 2103, 0x160b2eb3, F=0x0
1, 6454, 6454, 157, 446, 0x4394d6a2
1, 6611, 6611, 1023, 446, 0xa806de6b
1, 7634, 7634, 1023, 433, 0x606bdd56
1, 8657, 8657, 1023, 438, 0x4e13e0f0
0, 19197, 19197, 6399, 2637, 0xc6ba14ee, F=0x0
1, 9680, 9680, 1338, 426, 0x194bd9e9
1, 11018, 11018, 1023, 442, 0xfa35e018
0, 25596, 25596, 6399, 4770, 0x660c4900, F=0x0
1, 12041, 12041, 1023, 439, 0x35bcd9d1
1, 13064, 13064, 2362, 426, 0x9595e229
0, 31995, 31995, 6399, 5061, 0xc753d42f, F=0x0
1, 15426, 15426, 1023, 428, 0xcc04d5fd
1, 16449, 16449, 1023, 423, 0xcde7d049
1, 17472, 17472, 1023, 405, 0x01c4cba1
0, 38394, 38394, 6399, 6321, 0x5ef85181, F=0x0
1, 18495, 18495, 268434590, 421, 0xcb82ccf8
0, 44793, 44793, 6399, 6516, 0x100d9a6c, F=0x0
0, 51192, 51192, 6399, 4947, 0xaa8b81a6, F=0x0
0, 57591, 57591, 6399, 4757, 0x9edc5d0e, F=0x0
0, 63990, 63990, 6399, 4790, 0x2e0f48a8, F=0x0
0, 70389, 70389, 6399, 4869, 0x37b68637, F=0x0
0, 76788, 76788, 6399, 4826, 0x05906c8b, F=0x0
0, 83187, 83187, 6399, 4755, 0xd45b2b49, F=0x0
0, 89586, 89586, 6399, 4849, 0x997d64a8, F=0x0
0, 95985, 95985, 6399, 4879, 0xf1707281, F=0x0
0, 102384, 102384, 6399, 4977, 0x50839ad0, F=0x0
0, 108783, 108783, 6399, 4740, 0xdd2d4998, F=0x0
0, 115182, 115182, 6399, 4798, 0x55905414, F=0x0
0, 121581, 121581, 6399, 4951, 0x0c41a6ce, F=0x0
0, 127980, 127980, 6399, 4691, 0x4a541c7c, F=0x0
0, 134379, 134379, 6399, 4796, 0x3b403cc5, F=0x0
0, 140778, 140778, 6399, 4757, 0x546d682c, F=0x0
0, 147177, 147177, 6399, 4896, 0xd3fa714c, F=0x0
0, 153576, 153576, 6399, 4823, 0x1a803f47, F=0x0
0, 159975, 159975, 6399, 4922, 0xbf4e8e4a, F=0x0
0, 166374, 166374, 6399, 4900, 0xb3b59ed7, F=0x0
0, 172773, 172773, 6399, 4820, 0xcf4d7751, F=0x0
0, 179172, 179172, 6399, 4805, 0x78e05cbc, F=0x0
0, 185571, 185571, 6399, 4801, 0xe3be5df6, F=0x0
0, 191970, 191970, 6399, 4798, 0x9a5f6003, F=0x0
0, 198369, 198369, 6399, 4702, 0x383d0604, F=0x0
0, 204768, 204768, 6399, 4755, 0xcf2c3849, F=0x0
0, 211167, 211167, 6399, 4869, 0x9edc8732, F=0x0
0, 217566, 217566, 6399, 4789, 0x429f4a81, F=0x0
0, 223965, 223965, 6399, 4841, 0xe3ff61d0, F=0x0
0, 230364, 230364, 6399, 4687, 0x57fd2093, F=0x0
0, 236763, 236763, 6399, 4907, 0x46899bf7, F=0x0
0, 243162, 243162, 6399, 4699, 0x7b1b38be, F=0x0
0, 249561, 249561, 6399, 4799, 0x407f2442, F=0x0
0, 255960, 255960, 6399, 4839, 0x5ea867fc, F=0x0
0, 262359, 262359, 6399, 4828, 0xc3c55618, F=0x0
0, 268758, 268758, 6399, 4777, 0x27898276, F=0x0
0, 275157, 275157, 6399, 4759, 0xe80f2b54, F=0x0
0, 281556, 281556, 6399, 4886, 0x7de69458, F=0x0
0, 287955, 287955, 6399, 4849, 0xfa946cc6, F=0x0
frame= 46 fps=0.0 q=-1.0 Lsize= 4kB time=00:00:02.99 bitrate=
11.4kbits/s speed= 157x
video:231kB audio:7kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
The file which led to my patch was a recording of a very long
presentation with an intermission in between. Both streams had a large
legal offset at the same point in the timeline. After "correction",
there's a desync.
It may be a good idea to add a user-configurable lavf option to clamp
large duration values if the user thinks there's a writing error(s) in
an input.
Regards,
Gyan
More information about the ffmpeg-devel
mailing list