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 <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.
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
_______________________________________________
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".
