ffmpeg concat drops audio frames

Question

I have an mp4 file and I want to take two sequential sections of the video out and render them as individual files, later recombining them back into the original video. For instance, with my video video.mp4, I can run

ffmpeg -i video.mp4 -ss 56 -t 4 out1.mp4
ffmpeg -i video.mp4 -ss 60 -t 4 out2.mp4

creating out1.mp4 which contains 00:00:56 to 00:01:00 of video.mp4, and out2.mp4 which contains 00:01:00 to 00:01:04. However, later I want to be able to recombine them again quickly (i.e., without reencoding), so I use the concat demuxer,

ffmpeg -f concat -safe 0 -i files.txt -c copy concat.mp4

where files.txt contains

file out1.mp4
file out2.mp4

which theoretically should give me back 00:00:56 to 00:01:04 of video.mp4, however there are always dropped audio frames where the concatenation occurs, creating a very unpleasant sound artifact, an audio blip, if you will.

I have tried using async and -af apad on initially creating the two sections of the video but I am still faced with the same problem, and have not found the solution elsewhere. I have experienced this issue in multiple different use cases, so hopefully this simple example will shed some light on the real problem.

Lotz

Answer 1

I suggest you export segments to MOV with PCM audio, then concat those but with re-encoding audio.

ffmpeg -i video.mp4 -c:a pcm_s16le -ss 56 -t 4 out1.mov
...

and then

ffmpeg -f concat -safe 0 -i files.txt -c:v copy concat.mp4

Bullet

Sorry I was using -c copy.. I edited to include that. But your solution works! Can you explain why or provide any sources that would provide more details. My assumption would be that originally I was encoding the audio as AAC, and the compression could have had at noticeable (when concatenating) effect at the boundaries. Would this be correct? – Lotz

DCT-based audio codecs like MP3, AAC rely on neighbouring audio frames for decoding. At the start of the stream, there's a priming frame which serves that purpose. It has a negative timestamp, so during concat, its TS clashes with the final packets of the preceding file and it gets dropped by concat. PCM is self-contained for decoding, so doesn't suffer from this. – Bullet

@Bullet Isn't there any "not DCT-Based" codec supported by the MP4 container so we don't need to change container just for that ? – Cattalo