Opened 3 weeks ago

Last modified 2 weeks ago

#7461 new defect

Application provided invalid, non monotonically increasing dts to muxer

Reported by: Anuskuss Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


I'm trying to stretch an AC3 audio file to match the frame rate of a video file but it gives me the error mentioned in the title:

$ ffmpeg -i input.ac3 -af "atempo=0.95904" output.ac3
[ac3 @ 0000020faaca1b40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 58808576 >= 744704

I tried to find the broken part...

ffmpeg -t 1175.072 -i input.ac3 -af "atempo=0.95904" part1.ac3
ffmpeg -ss 1175.264 -i input.ac3 -af "atempo=0.95904" part2.ac3

...and work around it (since it's silence anyway)

ffmpeg -i input.ac3 -f lavfi -i "anullsrc=r=48000:cl=5.1" -filter_complex
-map "[F]" output.ac3

Still errors. I tried a number of things like -fflags +igndts or encoding it twice (first without arguments and then with -af atempo) but I'm trying to accomplish that with only one encoding if possible.

$ ffmpeg -version
ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 7.3.1 (GCC) 20180722

Change History (7)

comment:2 Changed 3 weeks ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Keywords non monotonically increasing dts to muxer removed
  • Version set to unspecified

Please test current FFmpeg git head and provide the command line you tested together with the complete, uncut console output to make this a valid ticket.

comment:3 Changed 3 weeks ago by Anuskuss

I somewhat figured out where the problem is but still can't fix it. I extracted the packet information with ffprobe -show_packets and compared the faulty file with the no-arguments reencoded file.

       BAD           GOOD
  pts=105756480  pts=105756480
  dts=105756480  dts=105756480
  duration=2880  duration=2880
  size=1536      size=1536
  pos=56403456   pos=56403456
  pts=105759360  pts=105759360
  dts=105759360  dts=105759360
  duration=2880  duration=2880
* size=768       size=1536
* pos=56404992   pos=56404992
  pts=105762240  pts=105762240
  dts=105762240  dts=105762240
  duration=2880  duration=2880
* size=768       size=1536
* pos=56405760   pos=56406528
  pts=105765120  pts=105765120
  dts=105765120  dts=105765120
  duration=2880  duration=2880
* size=768       size=1536
* pos=56406528   pos=56408064
  pts=105768000  pts=105768000
  dts=105768000  dts=105768000
  duration=2880  duration=2880
* size=768       size=1536
* pos=56407296   pos=56409600
  pts=105770880  pts=105770880
  dts=105770880  dts=105770880
  duration=2880  duration=2880
* size=768       size=1536
* pos=56408064   pos=56411136
  pts=105773760  pts=105773760
  dts=105773760  dts=105773760
  duration=2880  duration=2880
* size=768       size=1536
* pos=56408832   pos=56412672
  pts=105776640  pts=105776640
  dts=105776640  dts=105776640
  duration=2880  duration=2880
  size=1536      size=1536
* pos=56409600   pos=56414208

As you can see, all of the sudden the size changes from 1536 to 768 for only six samples. Now when I do -af "atrim=end_pts=105759360", the audio length goes down to 36:43.328 (2203.328) instead of my previously tested 19:35.072 (1175.072).

If I however divide the pts (105759360) by the duration (2880) and multiply with the duration_time (0.032) I get 19:35.104 (1175.104). This has to be a AC3 property because I have no idea why it cuts at 36:43.328 when the error is clearly at 19:35.104.

Unfortunately the problem still persists since the DTS is still messed up. This is what I tried so far:

ffmpeg -i input.ac3 -ab 384k -af "atrim=start_pts=105759360:end_pts=105776640" bad.ac3
# has to be done separately because there's no bitrate filter

ffmpeg -i input.ac3 -i bad.ac3 -ab 384k -filter_complex
 [P1][B][P2]concat=n=3:v=0:a=1[C]; # works
 [C]atempo=0.95904[F]"             # fails
-map "[F]" output.ac3

Is there a way to fix the DTS without reencoding twice?

ffmpeg -i input.ac3 -loglevel verbose -ab 384k -af "atempo=0.95904" output.ac3

comment:4 Changed 3 weeks ago by cehoyos

Sorry for being unclear: Please post the command line you tested together with the complete, uncut console output here on the tracker to make this a valid ticket.

comment:5 Changed 3 weeks ago by Anuskuss

@cehoyos Unfortunately I can't do that since comments are limited to 262144 characters; that's why I have posted it to PrivateBin? (look at the last two lines of my previous comment). I can however split it into multiple comments if you'd want me to or I can format it better so it's easier to understand:

Command used:

ffmpeg -i input.ac3 -loglevel verbose -ab 384k -af "atempo=0.95904" output.ac3

Console output:

Last edited 3 weeks ago by Anuskuss (previous) (diff)

comment:6 Changed 3 weeks ago by Anuskuss

I think I can fix the file with -af aresample=async=1 but there seems to be no way to combine aresample and atempo in one reencode (throws the same error when I do).

comment:7 Changed 2 weeks ago by Anuskuss

I think I got my timings wrong the first time, but this works.

Find last position without error

ffmpeg -t 1175.040 -i input.ac3 -c copy p1.ac3

Find first position without error

ffmpeg -ss 1175.328 -i input.ac3 -c copy -y p3.ac3

Substitute silence

ffmpeg -f lavfi -i "anullsrc=r=48000:cl=5.1" -t 0.288 p2.ac3

Concat and filter

ffmpeg -i "concat:p1.ac3|p2.ac3|p3.ac3" -af "atempo=0.95904" fin.ac3

One filter (like [0]atrim;[0]atrim;[A][B]concat,atempo) does not work.
Ticket can be closed since it's not really a priority and I don't think this will get resolved anyway.

Note: See TracTickets for help on using tickets.