ffmpeg concat problem

[DuncanStone]

I am trying to concatenate a series of videos together and I am getting the same behaviour as this previous thread.

The cause appears to be different though. As far as I can tell all the clips are in stereo at 44100. The issue only occurs after trim however, and the error message (Non-monotonous DTS in output stream) is the same. Is there a way I can analyse the streams in more detail? I checked them with ffprobe and all the files report
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, <different> kb/s (default)
where the bitrate is the only difference, The bitrate is 2kb/s for some files and 69kb/s for others.

I have found various sources about the error on SO but none of them really helped and most of them aren't even answered.

I don't really expect to be handed a solution but if anyone could point me to resources where I can find out more about the encoding systems and DTS and audio channels and how ffmpeg deals with these that would be a big help. I know it is a complicated topic.

Files concatenate fine if not trimmed, they are all mp4s with h264+aac stereo 44100
The command I am using to trim (redact sections of the video and audio) looks something like this:

-y -i ./28443b00-4990-45a2-b7fe-99c67fff7efc.mp4 
-i "./redacted.png" 
-f lavfi -i anullsrc=cl=stereo:r=44100 
-filter_complex "[0:v][1:v]overlay = 0:0[0v]; 
[0v]trim=start=0.001:end=3.838,setpts=PTS-STARTPTS[2v]; 
[2:a]atrim=start=0.001:end=3.838,asetpts=PTS-STARTPTS[2a]; 
[0:v]trim=start=3.839:end=30.104,setpts=PTS-STARTPTS[3v]; 
[0:a]atrim=start=3.839:end=30.104,asetpts=PTS-STARTPTS[3a]; 
[1v][1a][2v][2a][3v][3a]concat=n=3:v=1:a=1[outv][outa] " 
-map [outv] -map [outa] -pix_fmt yuv420p -movflags +faststart 
./28443b00-4990-45a2-b7fe-99c67fff7efcredacted.mp4

Here are some example files after the trim.

The command I am using to concatenate looks something like this:

-safe 0 -f concat -i ./concat.txt -c:a aac -ar 48000 -b:a 128k -vcodec copy -hls_time 4 -hls_playlist_type vod  -hls_segment_filename ./full-%03d.ts ./3a9ef38c-f0b7-440d-9960-c2d2c2fb3be8.m3u8

Also please note: this is for software I am building so a one off solution that deals specifically with these example files is not going to work, it needs to be an automated way to a) redact both video and audio of sections of the files and then b) merge them into an HLS stream. I can ensure a certain format including aspect ratio, resolution, codecs, etc. for the input videos.

[ProWo]

I think the problem is the aac audio.
You could try streams with other audio codecs (g.e. mp2, ac3, uncompressed pcm).
If they work, you can convert the source audio to pcm and after merging the complete audio stream back to aac.

[DuncanStone]

You are correct, changing to another audio encoder solved that error. Unfortunately after solving the DTS error I had a framerate problem, in that the second video was encoded in fast forward in the concatenated stream. This was caused by the videos having different encoding framerates.

The solution I found for this also deals with the DTS issue and any other future issues of the same nature, namely using the concat filter instead of the concat demuxer as described here

I had avoided using this until now because of the verbosity of the command line arguments for larger operations. My assumption that the two were simply different ways of calling the same code was wrong. The commands I posted here are very fragile and basically do not handle any significant differences between files very well. The filter method detailed in the concat filter answer is much more robust and can be set up to not only handle differences like these, but configured to handle them in different ways.

[DuncanStone]

Update: For anyone in the future who comes here with the same problem, the solution I posted here, while it is powerful and solves many issues, ended up not being viable for me. The concat filter does not allow -vcodec copy and therefore the additional time required to re-encode and the additional server load this entails is not acceptable. The solution I will be implementing instead is to modify how the files are produced. Even with aac audio, if you ensure that the encoding of every video is exactly identical including both the codecs, video framerate, resolution, aspect ratio and everything to do with the audio, you can use the demuxer with -vcodec copy and -acodec copy and the operation is almost instantaneous. Luckily I am processing files that are recorded by the same application I am working on so I can control these details.