Why Your Video Cut Lands Two Seconds Early

Most frames are differences, not pictures

Video compression works because consecutive frames are nearly identical. Storing each one in full would waste almost everything, so a codec stores one complete frame and then describes the next few dozen as changes from it: this block moved here, this area got brighter, the rest is the same. The complete frame is the keyframe, and the run that depends on it is a group of pictures. Playback from the start is unaffected — the decoder builds each frame from the last — but jumping into the middle is not, because a difference has nothing to be a difference from.

The distance between keyframes is set by whatever recorded it

There is no standard value, and that is why the same request behaves differently on two files. A phone camera keeps keyframes close together, roughly every two seconds, because it expects the footage to be scrubbed and edited. An export from editing software often stretches them much further to save space, because it expects the file to be watched from the beginning; ten seconds between keyframes is unremarkable in a delivered film. Screen recorders sit in between. Streaming re-encodes tend to align keyframes to segment boundaries, which puts them at tidy intervals of a few seconds.

The practical rule follows: the worst case for your cut is one keyframe interval, and you can estimate that from what produced the file rather than from anything you can see in it. A two-second drift on a phone clip is normal and usually invisible. A ten-second drift on an exported film is normal too, and very visible, which is why the same tool feels precise on one file and broken on another.

What you buy by accepting the drift

Speed and quality, both completely. A stream copy reads bytes and writes them out again: it never decodes a frame, never runs the encoder, and finishes in about the time it takes to read the file from disk. Trimming a two-gigabyte recording takes seconds rather than the several minutes an encode would need on the same machine, and the result is bit-for-bit the same video, just shorter. Re-encoding to hit an exact frame throws that away twice over — the time, and a generation of compression that no setting fully avoids.

When the drift actually matters

Rarely, and it is worth being specific about when. A clip sent in a message, a section of a recorded talk, an excerpt for a slide: a second or two of extra lead-in is at worst untidy and at best useful context. Where it does matter is when the cut is a boundary rather than a beginning — removing a name or a face from the start of a clip, splitting a recording into parts that must join back seamlessly, or cutting to a beat. In those cases the drift is not cosmetic: it can leave in exactly the thing you were removing.

The check is the same one every article in this batch ends on: look at the result before you send it. Play the first two seconds. If what you meant to cut is still there, you have learned the keyframe interval on this file, and you now know that an exact cut needs a re-encode rather than another attempt at the same operation.

Frequently asked questions

Can I force an exact cut?

Only by re-encoding, which decodes every frame from the last keyframe onwards and writes new ones, so the cut can start wherever you ask. It costs time proportional to the length of the clip and one generation of compression. That is the whole menu: there is no third option where an exact cut is also free, because the frame you want to start on does not exist as a complete picture until something builds it.

Why is the end of my clip exact but the start is not?

Because the two ends are not symmetrical. The start has to be a point a decoder can begin from, which means a keyframe. The end is just where the copying stops, and it can stop after any frame, so it lands where you asked. That asymmetry is a good diagnostic: if your cut is right at the end and early at the start, the tool is copying streams and behaving exactly as designed.

The first second of my trimmed clip is frozen or black. Why?

That is the same problem wearing a different hat: the copy started at a frame that was not a keyframe, so the decoder had nothing to build the first images from and showed whatever it could until the next keyframe arrived. Some tools avoid it by snapping backwards, which produces the early cut described here; others do not, which produces this. Either way the fix is the same — accept the earlier keyframe, or re-encode.

Does trimming reduce the file size proportionally?

Roughly, and not exactly, because bitrate is not constant across a video. A minute of a static talking head weighs far less than a minute of movement, so cutting the quiet half of a recording removes less than half the bytes. If you are trimming in order to meet a size limit rather than to choose a section, expect to have to compress as well, and do the trim first so the compression has less to work on.

Is audio cut at the same place as video?

Close, but not necessarily to the frame. Audio is stored in packets that are much shorter than a group of pictures, so the audio cut can land nearer your requested time than the video cut does. In practice that means a copied trim can begin with a fraction of a second of sound before the picture settles. It is rarely noticeable on speech and can be audible on music, which is another reason to re-encode when the cut is musical.