Lossless Video Trimming: How Keyframes Work
By Mark Fulton · 2026-08-09 · 2 min read
Trim a video "losslessly" and the cut lands a moment before the second you asked for. Trim it "precisely" and you wait ten times longer for the file. Both behaviors come from one fact about how video is stored — and once you know it, choosing the right mode takes zero thought.
Frames aren't all equal
A compressed video is not a stack of pictures. Most frames are stored as differences: "like the previous frame, but these blocks moved and these pixels changed." Only occasionally does the encoder write a complete, self-contained picture — a keyframe (I-frame). Everything between two keyframes can only be decoded by starting from the keyframe and applying the chain of differences.
Keyframe spacing is an encoder choice. Screen recordings and streaming files often carry one every 2–10 seconds; camera footage usually more often.
Why lossless cuts snap
A lossless trim (stream copy) doesn't decode anything — it copies compressed data into a new container. The copy has to begin at a keyframe, because starting mid-chain would produce frames with no anchor to decode from. So the tool starts your clip at the nearest keyframe at or before your requested time; per the FFmpeg seeking documentation, that's the fundamental trade of stream-copy cutting. Your 12.0s request may open at 10.5s — not a bug, the format.
What you get in exchange is a serious pair of advantages:
| Stream copy (fast) | Re-encode (precise) | |
|---|---|---|
| Speed | Near-instant, any file size | Real encoding time |
| Quality | Bit-identical to source | One generational loss (tiny at CRF 21) |
| Cut accuracy | Snaps to keyframes | Exact frame |
| Watermark on VidClip free | Never (nothing re-encodes) | Standard corner mark |
Choosing in practice
Use fast mode when trimming the dead air off a recording, splitting a long file, or when "roughly there" is fine — which is most trims. Use frame-precise when the exact first frame matters: a beat drop, a punchline, a UI interaction you're demonstrating. VidClip's trimmer is fast mode by default with precise as a checkbox, which matches how often each is actually the right call.
One workflow tip: for a clip that must start exactly on a moment and stay lossless, cut generously with fast mode first, then do the fine cut on the small file with precise mode — the re-encode then only touches seconds of footage instead of the whole recording.
Sources
- FFmpeg project, Seeking — cutting with stream copy
- FFmpeg project, H.264 encoding guide