Free browser-based media tool

Why a Trimmed Video Comes Out Slightly Longer Than You Set

Fast trimming skips re-encoding, so it finishes almost quickly and leaves the picture untouched. It also runs a few frames past the mark you chose. We measured where those extra milliseconds come from and when they actually matter.

Why a Trimmed Video Comes Out Slightly Longer Than You Set

The short answer

The trimmer has two paths. Fast trim copies the original video and audio streams without re-encoding, which is why it finishes in a fraction of a second and leaves every pixel as it was — but the file it hands back runs a couple of frames past the point you picked. Select a 2.000 second range and you get 2.133 seconds. Re-encode the same range and you get 2.000000 seconds, to the frame.

The overshoot is two to four frames — 0.07 to 0.13 seconds on a 30fps clip. It is not caused by keyframe spacing, and it does not get worse as the video gets longer. Cutting a talking-head clip for a social post, you will never notice it. Cutting to a music beat or lining up subtitle cues, you will.

What we measured

We pushed the same range through both paths on identical 640x360 30fps source clips, then read the results back with ffprobe.

2.000 s range (1.5 s to 3.5 s): fast trim returned 2.133 s over 62 frames. Re-encode returned 2.000000 s over 60 frames.
10.000 s range (5.0 s to 15.0 s): fast trim returned 10.133 s over 302 frames. Re-encode returned exactly 10.000000 s over 300 frames.
A range starting exactly on a keyframe (2.0 s to 4.0 s): fast trim still returned 2.067 s. Lining the cut up with a keyframe does not remove the drift.
Four source clips with keyframes every 1, 2, 5 and 10 seconds: fast trim returned 2.133 s on all four. Keyframe spacing changed nothing.

It is the start that stays exact, not the end

The usual explanation for trimming inaccuracy is keyframe alignment — the claim that a copy-mode cut snaps back to the nearest keyframe. Our own test says otherwise. We compared the decoded pixels of the output's first frame against every frame of the source: the first frame of a 1.5 s to 3.5 s fast trim is pixel-identical to the source frame sitting at exactly 1.500 s.

The drift is at the tail. Dump the output's frame timestamps and the last two frames stop being evenly spaced: they land around 2.033 s and 2.100 s, where a steady 30fps cadence would put them at 2.000 s and 2.033 s. Nothing is duplicated or dropped from the picture itself; the packets at the end of your range simply do not fall on clean frame boundaries, and a stream copy is not allowed to rewrite them.

Which path to pick

Speed, or the exact length does not matter: fast trim. On a 30-second test clip, cutting a 10-second range took 0.03 s against 0.26 s for re-encoding, and the encoded picture was never touched.
Cutting to a beat, a subtitle cue or a fixed time slot: re-encode. It costs a little time and one generation of quality, and it lands on the frame you asked for.
Trimming clips that will then be merged: re-encode. Each clip carries its own tail drift, and joining several fast-trimmed segments adds them up.
Output size is not a reliable reason to pick either one. In our test the 10-second fast trim came out at 1.34 MB and the re-encode at 0.83 MB, because CRF 23 re-compresses from scratch. Smaller is not the same as better here.