Why Trimming a Video Re-Encodes the Whole Thing

Cutting thirty seconds out of the middle of a video should be a trivial operation — delete some bytes, keep the rest. Instead your editor spends several minutes on it and the output is visibly softer than the input. Meanwhile the same editor sometimes trims a clip instantly with no quality loss at all. The difference comes down to where the cut lands relative to the video's keyframes.

Frames aren't stored as frames

Storing every frame as a complete image would be enormously wasteful, because consecutive frames of real footage are nearly identical. A talking-head shot at 30 fps changes very little between one frame and the next, so codecs store the differences instead.

Three frame types do the work:

• I-frames (intra-coded), also called keyframes, are complete images. They're compressed like a JPEG — self-contained, decodable on their own, and by far the largest.
• P-frames (predicted) store only what changed since a previous frame, usually as motion vectors ("this 16×16 block moved 3 pixels left") plus a small residual for whatever the motion vectors couldn't account for.
• B-frames (bidirectional) reference both earlier and later frames. A ball crossing the screen can be described from where it was and where it's about to be, which is more efficient than either alone.

A GOP (group of pictures) is one I-frame plus the dependent frames that follow it. A typical encoder places a keyframe every 2 to 10 seconds, plus one at every scene change, where prediction from the previous frame stops being useful anyway.

The size difference is dramatic. In ordinary footage an I-frame might be ten to fifty times larger than a P-frame. That ratio is the compression — it's why an hour of video isn't 100 GB.

What that means for cutting

Now the consequence. If you cut at a P-frame, everything from there to the next keyframe is expressed as differences from frames you just deleted. The decoder has nothing to apply those differences to. You get the frozen frame, gray mush, or heavy blocking that resolves only when the next keyframe arrives — the same visual signature as a corrupted stream, for the same underlying reason.

So editors have two options.

Stream copy, sometimes called lossless or smart cut. Snap the cut points to the nearest keyframes and copy the compressed bytes through untouched. It's essentially instantaneous — the limit is disk speed — and quality is bit-identical because nothing is decoded or re-encoded. The cost is that your cut lands wherever the nearest keyframe happens to be, which could be seconds away from where you wanted it.

Re-encode. Decode every frame back to pixels, discard the ones you don't want, and encode a fresh stream with new keyframes at the right places. You get frame-accurate cuts anywhere. The cost is time and a generation of quality loss, because the codec is lossy and you've just run the footage through it a second time.

Some editors do both: stream-copy the long middle section and re-encode only the short segments at each end where frame accuracy matters. That's the "smart rendering" feature, and it's why trimming is sometimes fast and sometimes not, in the same application, on the same file.

If you're doing this deliberately, a video editor that shows keyframe positions on the timeline lets you snap cuts to them and stay in copy mode.

Containers and codecs are different things

A related confusion: .mp4 is not a codec. It's a container — a file format specifying how streams, timestamps, and metadata are laid out. The codec is how the pixels themselves are compressed. An .mp4 usually holds H.264 video and AAC audio, but it can hold H.265 or AV1 just as legitimately.

This distinction has a practical payoff. Changing container while keeping the codecs — .mkv to .mp4, say — is a remux: the compressed streams are copied into a new wrapper. It takes seconds and is perfectly lossless. Changing codec is a transcode, and that's the expensive, lossy operation. When a video converter finishes suspiciously fast, it remuxed; when it takes a while, it transcoded.

Choosing a codec

• H.264 (AVC) is the compatibility floor. Every browser, phone, and TV made in the last fifteen years decodes it in hardware. Use it when the file has to just work.
• H.265 (HEVC) delivers roughly the same quality at 25–50% less data, but its licensing situation kept it out of some browsers, so support is uneven on the web.
• VP9 is royalty-free with quality comparable to HEVC, and is what YouTube serves to browsers that support it.
• AV1 is royalty-free and better again — commonly 30% below VP9 for equivalent quality — but encoding is computationally brutal, often an order of magnitude slower than H.264. Hardware decoding is now widespread; hardware encoding is still catching up.

For encoding settings, prefer constant quality (CRF in x264/x265, roughly 18–23 for H.264, where lower is better) over a fixed bitrate. CRF spends bits where the footage needs them — a fast pan gets more, a static shot gets fewer — and holds quality steady. Fixed bitrate does the opposite: it holds file size steady and lets quality collapse whenever the scene gets complicated.

The practical rules

• Trim on keyframes when you can. It's instant and lossless. Frame-accurate cuts cost a re-encode; decide whether you need them.
• Never re-encode repeatedly. Each pass compounds loss the same way re-saving a JPEG does. Keep the original and export from it every time.
• Remux instead of transcode when only the container is wrong.
• Encode with a shorter keyframe interval if the file will be edited later. More keyframes means slightly larger files and much finer cut granularity.
• Reduce resolution before reducing bitrate. Fewer pixels means fewer to describe. 1080p at 2 Mbps generally looks worse than 720p at 2 Mbps, because the codec is being asked to spread the same budget over twice the area.

The reason video editing feels so much heavier than image editing isn't that video files are bigger. It's that a video frame usually isn't a picture — it's a set of instructions for modifying a picture you have to already have.