Assertion next_dts <= 2147483647 failed at libavformat/movenc.c:1137 Abort trap: 6

[0kajuna0]

Summary of the bug: Transcoding some files fails with

Assertion next_dts <= 2147483647 failed at libavformat/movenc.c:1137
Abort trap: 6

How to reproduce:

% ffmpeg -i in.mp4 out.mp4
ffmpeg version N-108577-g6bf99f8c93 Copyright (c) 2000-2022 the FFmpeg developers
  built with Apple clang version 14.0.0 (clang-1400.0.29.102)

Not sure if this is a problem with ffmpeg or with the files themselves. Will upload the full log and a sample input file

[0kajuna0]

full log

[Carl Eugen Hoyos]

Please provide the input file.

[0kajuna0]

I uploaded the file here ​https://streams.videolan.org/upload/

[mkver]

File available ​here.

[Carl Eugen Hoyos]

I cannot really test (x264 wrapper is broken here and it does not reproduce with the mpeg4 encoder) but it can be reproduced with the first 20MB of the input file and scaling to qcif.
Work-around seems to be to use -r 30

[Carl Eugen Hoyos]

Regression since b4dcd351ec50caaa484bc5c66b4a8d5557a0f1ea related to ticket #4704

[Balling]

So what, int64_t next_dts; is not enough??

But yeah here still happens after 2 minutes or so

Assertion next_dts <= 0x7fffffff failed at libavformat/movenc.c:1137

[quinkblack]

It's a known issue. There are multiple path to trigger assert failure.

Ref. ​https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=5626

It's complex.

[Balling]

Is this already implemented?

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.

In this already applied code: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211116141533.1708-1-ffmpeg@gyani.pro/