[FFmpeg-user] Concatenating two MPEG4 AAC movies fails with "invalid, clipping"

Moritz Barsnick barsnick at gmx.net
Thu May 21 18:03:59 CEST 2015


On Thu, May 21, 2015 at 17:14:13 +0200, Nikolas Borrel-Jensen wrote:
> I’m concatenating two AAC encoded movies in a mp4 container as

AAC? Are you sure? One doesn't even have an audio track. I'm not sure
how the concat demuxer handles that. But anyway:

> ffmpeg -f concat -i /concat_scripts -c:a copy -c:v copy output.mp4
> 
> but I get a bunch of error messages like
> 
> [mp4 @ 0x7fbc61821400] st:0 PTS: 5433 DTS: 5412 < 35774 invalid, clipping
> [concat @ 0x7fbc61801200] Invalid stream index 1
> [mp4 @ 0x7fbc61821400] st:0 PTS: 5453 DTS: 5432 < 35775 invalid, clipping

You are requested to post the complete command line and the full, uncut
console output. And that for many very good reasons. One of them: I
suspect you are using a wrong or old version of ffmpeg.

That's why the other common request is for you to use as new a version
of ffmpeg as possible. Recent binary builds from git are available for
many platforms, if you can't build yourself.

With my recent ffmpeg, I get:
[...]
Press [q] to stop, [?] for help
[concat @ 0x9e15d60] New audio stream 0:1 at pos:44 and DTS:3.10168s
[mp4 @ 0x9e1fb40] Non-monotonous DTS in output stream 0:0; previous: 35600, current: 1822; changing to 35601. This may result in incorrect timestamps in the output file.
[mp4 @ 0x9e1fb40] Non-monotonous DTS in output stream 0:0; previous: 35601, current: 1842; changing to 35602. This may result in incorrect timestamps in the output file.
[mp4 @ 0x9e1fb40] Non-monotonous DTS in output stream 0:0; previous: 35602, current: 1862; changing to 35603. This may result in incorrect timestamps in the output file.

The resulting file does _not_ play well for me, but: That's probably a
different issue. I don't have the solution for that and leave that
question open.

Incidentally, what works for me is the MPEG-TS method described here:
https://trac.ffmpeg.org/wiki/Concatenate#protocol
But the audio from the second file incorrectly starts at the beginning
of the resulting video, it seems the concat protocol doesn't handle
that as expected. Your intro video would need some blank audio to fill
the gap (either inserted when you generate the intro, or generated by
ffmpeg during your conversion to match the second video).

Moritz


More information about the ffmpeg-user mailing list