Scene cuts and keyframes: why I-frames land on cuts

An I-frame is a decoding entry point: it references no other frame and stands alone. Every following P/B frame leans on it to save data. At a scene cut the previous scene is nearly useless as a reference — forcing prediction across the cut costs enormous residual data, while dropping an I-frame restarts the reference chain and is cheaper and more stable.

Conversely, if an I-frame lands mid-scene, the cut itself must be predicted from the old scene: residuals cannot keep up, and the cut moment shows blur, ghosting, or blocking. Good encoders align I-frames with cuts — which is why fast-cut edits are naturally larger: more cuts, more I-frames.

The encoder compares each frame against the previous one (block-wise cost difference): when the difference exceeds a threshold it declares a cut and inserts an I-frame. x264’s scenecut parameter is that threshold — lower values detect more aggressively (more I-frames, bigger files); values set too high miss cuts, and the encoder keeps referencing the old scene with visible quality loss at the transition.

Daily transcodes never need this knob: defaults perform well on almost all content. The dangerous direction is the opposite — cranking scenecut down to shrink file size. Collapsing quality at cuts costs far more than the bytes saved.

Players can only seek to keyframes: decoding must start from an I-frame. A timestamp between two keyframes requires decoding forward to the next keyframe and stepping back — that is why some videos pause briefly after a seek. Sparse keyframes (long GOPs, few cuts) seek coarsely; fast-cut content with dense I-frames seeks snappily.

That is the fundamental trade: dense I-frames favor seeking and editing (frame-accurate access), sparse I-frames favor size. Published masters should ride the default scene detection — both extremes are not worth manufacturing by hand.