concat files with ffmpeg and preserve exact frame timestamps

Question

I'm doing this to add a keyframe at 00:00:14.0000

1. ffmpeg -i trailer.mp4 -to 13.92 -copyts -c copy first-bun.mp4

2. ffmpeg -ss 14 -i trailer.mp4 -to 15 -video_track_timescale 90000 -copyts bun.mp4

3. ffmpeg -ss 16 -i trailer.mp4 -copyts -c copy third-bun.mp4

4.  create text file 
        file 'first-bun.mp4'
        file 'bun.mp4'
        file 'third-bun.mp4'

5.  ffmpeg -f concat -i concat.txt -c copy trailer-keyframed.mp4

This works, and the resulting file plays without a visible hitch, however, when I inspect the frames of the final output file to see if my keyframe is at the place where I expect it to be, I see that the keyframe is actually at 14.022 instead of 14.

        "media_type": "video",
        "stream_index": 0,
        "key_frame": 1,
        "pkt_pts": 1261980,
        "pkt_pts_time": "14.022000",
        "pkt_dts": 1261980,
        "pkt_dts_time": "14.022000",
        "best_effort_timestamp": 1261980,
        "best_effort_timestamp_time": "14.022000",

Further, there is no frame at 14, but rather at 13.96 and 14.04

Inspecting bun.mp4, I see a keyframe at 14, as I expect:

        "media_type": "video",
        "stream_index": 0,
        "key_frame": 1,
        "pkt_pts": 1260000,
        "pkt_pts_time": "14.000000",
        "pkt_dts": 1260000,
        "pkt_dts_time": "14.000000",
        "best_effort_timestamp": 1260000,
        "best_effort_timestamp_time": "14.000000",

Further inspecting the frames reveals that:

• first-bun.mp4 goes from 0 to 13.96
• bun.mp4 goes from 14 to 14.96
• third-bun.mp4 goes from 15 to the end.

An inspection of the original trailer.mp4 shows that there are no frames between 13.96 and 14, nor are there frames between 14.96 and 15.

Where is this adjustment coming from, and how can I prevent it?

full output of all commands: https://pastebin.com/10Zcdh4P

Answer 1

Audio codecs like AAC or MP3 have a priming sample before the first audio sample. The priming sample has a negative timestamp. For a 48 kHz stream, the timestamp will be -1024/48000 s = -0.0213s. What the concat demuxer does is add an offset to the timestamps of all files after the first one. The priming sample created in step 2 is affecting the timestamp post-offset.

If you skip audio during extraction and concat, and add it only at the end, you can avoid that.