Opened 17 months ago

Last modified 12 months ago

#9966 open defect

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

Reported by: 0kajuna0 Owned by:
Priority: important Component: avformat
Version: git-master Keywords: crash abort mov
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Attachments (1)

ffmpeg-20221009-183935.log.zip (256.2 KB ) - added by 0kajuna0 17 months ago.
full log

Download all attachments as: .zip

Change History (9)

by 0kajuna0, 17 months ago

full log

comment:1 by Carl Eugen Hoyos, 17 months ago

Component: ffmpegavformat
Keywords: crash abort mov added
Priority: normalimportant

Please provide the input file.

comment:2 by 0kajuna0, 17 months ago

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

comment:3 by mkver, 17 months ago

File available here.

comment:4 by Carl Eugen Hoyos, 17 months ago

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

comment:5 by Carl Eugen Hoyos, 17 months ago

Reproduced by developer: set
Status: newopen

Regression since b4dcd351ec50caaa484bc5c66b4a8d5557a0f1ea related to ticket #4704

comment:6 by Balling, 12 months ago

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

Last edited 12 months ago by Balling (previous) (diff)

comment:7 by quinkblack, 12 months ago

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.

comment:8 by Balling, 12 months ago

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/

Last edited 12 months ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.