If you have ever trimmed a video and noticed the cut did not land exactly where you expected, the explanation lies in how video compression structures its data. Understanding keyframes helps you predict when trim points will be exact and when they will shift.
How video compression stores frames
Modern video codecs (H.264, H.265, VP9, AV1) do not store every frame as a complete image. That would make files enormous. Instead, they use a system of frame types within a Group of Pictures (GOP):
- I-frames (Intra-frames / Keyframes): A complete, self-contained image. The decoder can display this frame without any information from other frames. I-frames are large because they contain all the pixel data for the entire frame.
- P-frames (Predicted frames): Store only the differences from the previous frame. If the background did not change, a P-frame only records the pixels that moved. P-frames are much smaller than I-frames.
- B-frames (Bi-directional frames): Store differences from both the previous and next frames. B-frames are the smallest because they can reference data in both directions.
A typical GOP structure might be: I B B P B B P B B P B B I. The I-frames appear every 30 to 250 frames depending on the codec settings. For H.264 at 30fps with a GOP size of 60, a keyframe appears every 2 seconds.
Why keyframes matter for trimming
When you trim without re-encoding (stream copy mode), the decoder can only start playback from an I-frame because I-frames are the only frames that contain complete image data. If you request a cut at frame 45 but the nearest I-frame is at frame 30, the tool has two choices:
1. Start at frame 30 (the nearest keyframe before your cut point). This includes a few extra frames you wanted to trim, but the video plays correctly from the start.
2. Start at frame 45 but include frames 30-44 as hidden pre-roll data. The file starts decoding from the keyframe at 30, but the player skips forward to frame 45 before showing anything. This works in some players but can cause the first fraction of a second to glitch in others.
Both approaches produce a cut that does not land exactly at your chosen point. The inaccuracy can be anywhere from a fraction of a second to several seconds, depending on the GOP size.
Re-encoding eliminates keyframe constraints
When you trim with re-encoding, the tool decodes the entire video stream, finds the exact frames at your specified cut points, and creates a new compressed file starting precisely at your chosen frame. The new file has its own keyframe structure that starts at your cut point.
The trade-off is that re-encoding takes longer (the entire trimmed segment must be decoded and then encoded again) and introduces one generation of compression. With a quality setting of CRF 18-20 for H.264, this compression is visually lossless for all practical purposes. But it does mean the output file is not a bit-perfect copy of the original.
When keyframe trimming is fine
For most casual trimming (cutting dead air from the start and end of a clip), keyframe inaccuracy of 1-2 seconds is perfectly acceptable. If you are removing the first 5 seconds of camera setup, it does not matter much whether the cut lands at 4.8 or 5.2 seconds.
Stream copy trimming is also much faster because it does not need to decode and re-encode the video. For large files (multi-gigabyte footage), the speed difference can be significant.
When you need frame-accurate trimming
Frame-accurate cuts matter when:
- You are cutting to music and the visual needs to sync with a specific beat
- You are extracting a precise moment (a reaction, a catch, a specific frame)
- You are preparing clips for professional editing where frame accuracy affects the narrative
- You are removing specific content that must not appear at all (even a single visible frame)
For these cases, use a tool that re-encodes. The MediaBrew trim tool always re-encodes, which means your cuts are frame-accurate every time. The processing takes longer than stream copy, but the precision is guaranteed. All processing runs locally via FFmpeg WebAssembly.