Why Some Frames Depend On Others
Consecutive frames of video usually resemble each other closely, and compression exploits that resemblance aggressively. The result is a file in which most frames cannot be shown without their neighbors.
Repetition between frames is the biggest saving available
In a typical shot, the background holds still while a subject moves across it. Storing the unchanged background again for every frame would waste the bulk of the file.
Instead the encoder stores one complete picture and then describes later frames as changes to it. The description of a small movement is dramatically shorter than a fresh picture.
This inter-frame saving is larger than anything achievable within a single frame. It is the main reason a video file is not simply a folder of compressed photographs.
Three kinds of frame do different work
A complete, self-contained frame is decodable on its own and is by far the largest. It acts as an anchor and appears at intervals through the file.
Predicted frames refer backward to an earlier frame, storing only what changed. Bidirectional frames refer both backward and forward, which lets them borrow detail that has not been shown yet.
Because bidirectional frames depend on a later frame, the file stores frames out of display order. The decoder reorders them, which is one reason playback starts a fraction of a second after you press play.
Motion is described as displacement
Rather than saying what changed pixel by pixel, the encoder says where a block of the previous frame has moved to. A short vector replaces a large quantity of picture data.
Finding those vectors is the expensive part of encoding. The encoder searches nearby regions for the best match, and better searching produces smaller files at equal quality.
When nothing matches well, the encoder falls back to describing new picture content. Scene changes, heavy rain and confetti all defeat matching and consume data quickly.
Seeking is constrained by the anchors
Jumping to an arbitrary moment requires a complete frame to start from. Players seek to the nearest preceding anchor and decode forward silently until they reach the requested point.
If anchors are far apart, that hidden decoding takes time and scrubbing feels sluggish. Placing them closer together makes navigation crisp but inflates the file.
Editing has the same constraint. Cutting cleanly at a point mid-chain means re-encoding the surrounding frames, which is why some trims are instant and others are not.
Damage propagates until the next anchor
Losing part of an anchor frame corrupts everything that refers to it. The familiar smeared, drifting mess of a broken stream is later frames faithfully applying changes to a wrong picture.
The picture snaps back to normal at the next complete frame, which is why glitches end abruptly rather than fading. The stream has simply restarted from a fresh anchor.
Streaming formats therefore insert anchors on a regular schedule rather than only at scene changes. Predictable recovery matters more than optimal efficiency when delivery is unreliable.
