A keyframe is expensive and you need them anyway

Every setting is a trade · Medium

Every frame in a compressed video file is a lie, except one. The keyframe carries the full picture; everything around it borrows from what came before.

The frame that pays for itself

Open a compressed video stream and most of what you find are not complete images. They are instructions — "this block moved here," "this region changed by this much," "copy from three frames ago." The Moving Picture Experts Group formalized this distinction early: frames that are stored as complete pictures are called I-frames or intra-frames; frames that describe only what changed relative to their neighbors are P-frames (predictive) or B-frames (bidirectional). A keyframe, in common usage, is an I-frame that also marks a clean entry point — a moment where the decoder can start from nothing and reconstruct a valid image without any prior context.

That full-picture storage costs. An I-frame carries every macroblock, applies its own discrete cosine transform, and discards only spatial redundancy within itself. A P-frame, by contrast, can reference the previous frame and encode only motion vectors and residual differences, which in a relatively static shot might consume a fraction of the bits. B-frames are even leaner, borrowing from frames on both sides. The group of pictures — the GOP — is the repeating structural unit: one I-frame followed by some arrangement of P and B frames before the next I-frame arrives. The length of that GOP is one of the most consequential decisions an encoder makes, and it never resolves cleanly.

Too few and too many

Shorten the GOP and keyframes arrive frequently. Every one is expensive, so the average bitrate climbs — or, if bitrate is fixed, every other frame is starved to compensate. A two-second GOP at 25 fps means one I-frame every fifty frames; tighten that to half a second and the file roughly quadruples the proportion of its most expensive frames. During the CD-R era, when fitting a feature film onto 700 megabytes required squeezing every bit, long GOPs were a necessity, not a preference. Encoders running the early MPEG-4 tools stretched intervals as far as practical, trusting that most playback would be linear.

But linear playback is not all that happens. Seek to a random point in a video file and the player must find the nearest preceding keyframe, decode forward to the target, and present the result. If that keyframe is thirty seconds back, the player has to process thirty seconds of P and B frames before it can show anything. On low-power hardware that delay is real. On a streaming server that has to support random access across millions of concurrent viewers, it becomes architectural. The practical result was that edit software, streaming platforms, and archival tools all pushed for shorter GOPs than pure compression efficiency would recommend. One keyframe per second became a common compromise; streaming delivery sometimes demands one every half-second or less.

Scene cuts expose the tradeoff differently. A hard cut — one scene ending, another beginning — is the worst possible moment for a P-frame. The encoder tries to find blocks in the previous frame to describe the new one, fails, and produces a bloated frame anyway, or introduces visible blocking artifacts. Good encoders insert a forced I-frame at scene boundaries, which is the right call aesthetically but penalizes the bitrate budget at exactly the moment the image changed most dramatically. Because an I-frame at a cut cannot borrow from earlier frames, it carries far more data than the P-frames around it, and the bitrate it consumes has to be recovered elsewhere.

Two-pass encoding helped. The first pass analyzes the entire source, maps where cuts occur and where motion is high, and lets the second pass allocate bits intelligently — more around I-frames and busy sequences, less during static stretches. The result is a file that spends its bitrate budget where the eye notices and thins it where the eye forgives. But two-pass encoding takes twice the time, and for real-time or near-real-time applications — broadcast encoding, live streaming — the analysis has to be compressed into lookahead buffers and heuristics. The I-frame placement problem does not disappear; it just moves into a statistical argument about what the encoder expects to happen next.

The keyframe interval is one of those parameters that looks like a technical setting and is actually a bet: a bet about how viewers will use the file, what hardware will decode it, and how much the encoder cares about any given moment looking right after a seek.