I have noticed that ffmpeg sometimes writes invalid PTS timestamps when using -t on a M2TS input. Is this my mistake or is it a bug in ffmpeg?
Steps to reproduce:
Download this M2TS file and save it as 1.m2ts. This file contains one video stream with 25 fps (that is, one video frame takes exactly 0.04 s (40 ms)) and one audio stream that isn’t interesting for the purpose of this post.
Open the terminal, navigate into the directory that contains the file, and execute the following command:
ffmpeg.exe -i 1.m2ts -codec copy -map 0 -t 2 2.m2ts
Now examine the output file, 2.m2ts, and observe that the latest video frame’s PTS is 3.560, and that the PTS of the previous video frame is 3.480.
This obviously is wrong. After the frame at 3.480, the next frame should be presented at 3.520, not 3.560. Either ffmpeg has dropped the video frame that should come at 3.520, or it has written a wrong PTS to the last video frame (3.560 instead of 3.520).
Of course, when talking about “last” or “before”, I am referring to the order of the frames in time (more precisely, I have ordered the video frames by PTS), not the order of the frames in the file.
Question:
Is this a bug in ffmpeg, or is there a mistake in my command above?
ffmpeg version:
ffmpeg version 2024-01-14-git-34a47b97de-full_build-www.gyan.dev on Windows 10 x64 Enterprise
Further remarks:
I have noticed the problem with several of my M2TS files; I don’t have the time to test other formats. Unfortunately, I cannot provide my files for download. That’s the reason why I have linked to another file.
In other words: The problem is not specific for the file I have linked. Rather, I have encountered it with various video frame rates and audio tracks in various M2TS files from different sources.
I didn’t investigate the audio tracks with respect to similar gaps yet.
