Skip to main content
Super User

Return to Answer

corrected audio frame length
Source Link
Gyan
Gyan
  • 37.1k
  • 6
  • 64
  • 106

Use

ffmpeg -ss 01:19:22 -t 00:1:43 -i "in.mp4" -c copy -avoid_negative_ts make_zero out.mp4

Most compressed video uses temporal compression, so frames rely on other frames for full decoding. If you trim a video using copy mode, some frames after your inpoint may rely on frames before the inpoint for decoding. If so, those frames have to be included. Those frames are assigned negative timestamps so good video players use them for decoding but not for presentation. The video is shown from the inpoint onwards. Since all audio frames are keyframes, audio trimming is precise and A/V sync is preserved.

Apparently, video editors don't seem to pay heed to PTS so they show all frames stored in the file. My command above forces positive TS for all stored frames, so the video/audio will remain in sync*.

*Not completely true. For MDCT-based audio codecs like MP3/AAC, the previous frame is included with negative PTS, since it's needed for decoding. Maybe your NLE will decode that frame, leading to a 221 - 2.523 ms async. Workaround is to re-encode the audio.

Use

ffmpeg -ss 01:19:22 -t 00:1:43 -i "in.mp4" -c copy -avoid_negative_ts make_zero out.mp4

Most compressed video uses temporal compression, so frames rely on other frames for full decoding. If you trim a video using copy mode, some frames after your inpoint may rely on frames before the inpoint for decoding. If so, those frames have to be included. Those frames are assigned negative timestamps so good video players use them for decoding but not for presentation. The video is shown from the inpoint onwards. Since all audio frames are keyframes, audio trimming is precise and A/V sync is preserved.

Apparently, video editors don't seem to pay heed to PTS so they show all frames stored in the file. My command above forces positive TS for all stored frames, so the video/audio will remain in sync*.

*Not completely true. For MDCT-based audio codecs like MP3/AAC, the previous frame is included with negative PTS, since it's needed for decoding. Maybe your NLE will decode that frame, leading to a 2 - 2.5 ms async. Workaround is to re-encode the audio.

Use

ffmpeg -ss 01:19:22 -t 00:1:43 -i "in.mp4" -c copy -avoid_negative_ts make_zero out.mp4

Most compressed video uses temporal compression, so frames rely on other frames for full decoding. If you trim a video using copy mode, some frames after your inpoint may rely on frames before the inpoint for decoding. If so, those frames have to be included. Those frames are assigned negative timestamps so good video players use them for decoding but not for presentation. The video is shown from the inpoint onwards. Since all audio frames are keyframes, audio trimming is precise and A/V sync is preserved.

Apparently, video editors don't seem to pay heed to PTS so they show all frames stored in the file. My command above forces positive TS for all stored frames, so the video/audio will remain in sync*.

*Not completely true. For MDCT-based audio codecs like MP3/AAC, the previous frame is included with negative PTS, since it's needed for decoding. Maybe your NLE will decode that frame, leading to a 21 - 23 ms async. Workaround is to re-encode the audio.

Source Link
Gyan
Gyan
  • 37.1k
  • 6
  • 64
  • 106

Use

ffmpeg -ss 01:19:22 -t 00:1:43 -i "in.mp4" -c copy -avoid_negative_ts make_zero out.mp4

Most compressed video uses temporal compression, so frames rely on other frames for full decoding. If you trim a video using copy mode, some frames after your inpoint may rely on frames before the inpoint for decoding. If so, those frames have to be included. Those frames are assigned negative timestamps so good video players use them for decoding but not for presentation. The video is shown from the inpoint onwards. Since all audio frames are keyframes, audio trimming is precise and A/V sync is preserved.

Apparently, video editors don't seem to pay heed to PTS so they show all frames stored in the file. My command above forces positive TS for all stored frames, so the video/audio will remain in sync*.

*Not completely true. For MDCT-based audio codecs like MP3/AAC, the previous frame is included with negative PTS, since it's needed for decoding. Maybe your NLE will decode that frame, leading to a 2 - 2.5 ms async. Workaround is to re-encode the audio.