To put this plainly, -ss and -t don't work very well or even consistently.

I'm trying to take a single input file1 and only encode from a certain start point, -ss, and for only a certain time, -t. I've checked and double checked my in times are what I want, down to the frame (calculated to milliseconds2), but ffmpeg adds anywhere from 10 to 19 frames to the beginning, which is more than a half a second. I need frame precise cuts at the in points. Out points can be off by a few if necessary.

I've run the following commands all with exactly the same results on 13 different files. All add the 10 to 19 frames to the beginning.

ffmpeg -ss 00:00:34.600 -t 00:26:40.400 -i 002.m2t [commands] 01.mp4
ffmpeg -i 002.m2t -ss 00:00:34.600 -t 00:26:40.400 [commands] 01.mp4
ffmpeg -ss 00:00:34.600 -i 002.m2t -t 00:26:40.400 [commands] 01.mp4

The [commands] section is exactly

-filter_complex "scale=852:480,setsar=1","eq=brightness=0.05:saturation=1.0" -crf 24 -c:a aac -b:a 64k -ac 1 -loglevel quiet -stats -movflags +faststart

I find many with the same issue, but no solutions. I thought at first that putting -ss and -t before -i would work, but as you can see I've tried moving them around and get exactly the same results.

Is there really no way to cut a video with frame precision in ffmpeg?

In the documentation I found -seek_timestamp which says

This option enables or disables seeking by timestamp in input files with the -ss option. It is disabled by default. If enabled, the argument to the -ss option is considered an actual timestamp, and is not offset by the start time of the file. This matters only for files which do not start from timestamp 0, such as transport streams.

I know m2t (see footnote 1) is a transport stream, so I tried using -seek_timestamp, but I get errors that seem to be about parsing the arguments. I've tried putting it in different places in the command too. Maybe the answer is here, but I'm having trouble with the syntax.


  1. The input files are MT2 HDV recorded via firewire from an old Sony cam direct to Vegas Pro.

  2. I import the files to Vegas Pro and trim them on the timeline like any other edit job, but instead of rendering in Vegas Pro, I export the events to eventually derive the ffmpeg commands, with -ss and -t effectively pulled directly from the Vegas Pro timeline. When I do this, the -ss 00:00:34.600 in the command above actually came from the Vegas Pro events like this: 00:00:34;18. The 18 at the end is 18 frames. Since this is 30 fps footage, I calculate the milliseconds needed for the ffmpeg command by dividing by 30. 18/30 = .6.

  • For TS files, ss should come after the file name. ss before -i relies on a global index in the container which TS files don't have. TS files timestamps also can be a bit offset since there's a delay often added to allow the streaming receiver to get initialized properly. Can you share a small sample of this input? ffmpeg -i 002.m2t -copyts -c copy -t 50 sample.ts and also an image of the expected frame for 00:00:34.600
    – Gyan
    Nov 24, 2018 at 5:08
  • @Gyan Thanks for waiting. Here's the expected frame for 00:00:34.600 and the copied first 50 seconds. I had to run the copy command without -copyts but verified that they are identical and can reproduce the issue on sample.ts when converting it to mp4.
    – user3643
    Nov 25, 2018 at 19:15
  • Why did copyts fail?
    – Gyan
    Nov 26, 2018 at 5:47
  • @gyan Not sure. Don't remember.
    – user3643
    Nov 26, 2018 at 6:11
  • 1
    I had a look. Slightly involved, so I'll post an answer in the morning.
    – Gyan
    Nov 28, 2018 at 18:32

1 Answer 1


Transport Stream files are meant for streaming, have no global header, and may be sliced or joined together without the help of a format-aware utility. Because of this, there'a a lot of metadata structure within a TS file that allows them to be playable even after such operations. What that allows, in turn, is having multiple streams of different duration starting and stopping at different times. A format-aware utility like ffmpeg will parse the metadata and respect these features whereas a video editor which is mainly designed for a static file-based and indexed media usually won't - not with full fidelity anyway.

In the sample, there are two streams - 1 video and 1 audio. Run the following to identify the start_time of each stream

ffprobe -show_entries stream=codec_type,start_time -v 0 -of compact=p=1:nk=0 sample.ts

For your file, this results in



Ignore the first two lines. You can see that the video start is delayed relative to the audio. FFmpeg respects this delay. Your editor likely doesn't. It will either ignore the surplus audio or desync it with respect to the video.

So, 00:00:34.600 in the editing timeline actually references absolute timestamp of 34.6 + 1.978233 = 36.578233.

So, to accurately extract the desired frame, you need to know the delay of the video stream. Now, ffmpeg, by default, removes the starting offset i.e. it subtracts the start_time of the earliest starting stream before ingesting into its processing pipeline (unless copyts is set).

So, without copyts, the video start_time will be modified to 1.978233 - 1.400000 = 0.578233 and the desired frame will be at 34.6 + 0.578233 = 35.178233.

So, run

ffmpeg -i sample.ts -ss 00:00:35.178233 -t 00:26:40.400 [commands] out.mp4

You can use

ffprobe -show_entries format=start_time:stream=start_time -select_streams v -v 0 -of compact=p=1:nk=0 sample.ts

to get



where the relative offset for the video is 1.978233 - 1.400000 = 0.578233

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.