How to Find a Frozen Frame Without Watching the Whole Video

The worst kind of video fault is the one that lasts a second. A freeze in the middle of a two-minute clip is invisible in a thumbnail, invisible in the duration, invisible in every property the file reports — and obvious to the one person you did not want to notice it.

Watching the whole thing back is the usual answer. For a handful of files it is fine. For a folder of exports, a nightly render or a batch of screen recordings, it is not.

There is a much cheaper way in, and it works because of something most people never think about: the encoder already looked at every frame, and it wrote down what it found.

A repeated frame is almost free to store

Video compression stores most frames as differences from the frame before. If the picture changes, the difference is large and the frame costs a lot of data. If the picture does not change at all, the difference is nothing, and the encoder stores a few bytes that mean “same as last time”.

That gap is enormous. Measured on ordinary 720p footage: a normal frame took around 300,000 bytes, and a frozen one 36 bytes.

So a freeze has a shape in the file that needs no decoding to see: a run of almost-empty frames between normal ones. The file’s index — which every player reads instantly to build its seek bar — already lists the size of each frame.

Reading that index for a 10-second clip takes about a quarter of a second. Decoding every frame of the same clip to compare them takes about 40 seconds on a modest server. Same finding, a hundred times cheaper.

Why “small frames” is not enough on its own

If you stopped there, you would flag a lot of perfectly good video. Three cases look identical by size alone:

A title card. Two seconds of a static graphic is a run of near-empty frames. It is meant to be still.

A slideshow, or animation on twos. Traditional animation holds each drawing for two or three frames, and a slide deck recording holds each slide for seconds. Both are runs of repeats, both are correct.

A screen recording. Nothing moves except a cursor. Most of the file is repeats by design.

What separates a genuine freeze from all of these is not the stillness — it is what surrounds the stillness. A freeze interrupts motion: things were moving, they stop dead, they move again. A title card arrives after a cut and leaves on another cut. A screen recording is mostly still throughout.

So the useful test is three-part: a run of repeated frames, real motion on both sides of it, and no scene change at either edge. A cut is visible in the file too — the frame that starts a new shot is unusually large, because nothing in it can be predicted from what came before.

The one case the file cannot settle

Occasionally the encoder places a full keyframe exactly where the freeze begins. A keyframe is large whether the picture changed or not, so at that one boundary “large frame” no longer distinguishes a cut from a freeze.

There the only honest move is to look: decode the four frames around that boundary and ask whether the picture actually changed. Measured, the two cases are not close — the jump across a real cut was 114 grey levels, and across the start of a freeze in grainy footage 3.3. It costs one decode, at one point in the file, and only when the cheap test cannot answer.

That is the general pattern worth stealing: use the cheap signal for everything it can settle, and spend the expensive one only where it genuinely cannot.

Frames that never arrived are a different fault

A freeze means the same picture was stored twice. A gap means a picture was never stored at all — the recorder stalled, the capture dropped, the source was already missing frames when it was handed over.

That one is even cheaper to find, because it is visible in the timestamps rather than the sizes. Frames should arrive at an even spacing; a long jump between two of them is time with nothing in it. On a recording that stalled for a second, the timeline says so exactly: normal spacing, one interval of 1.07 seconds, normal spacing again.

With one caveat that matters, and that catches naive tools: a variable frame rate file does this legitimately. Phone cameras and screen recorders write a frame only when something changes, so long gaps are the format working as designed, not frames going missing. The difference is whether the spacing is otherwise steady. If a file’s intervals wobble everywhere, it is variable-rate; if they are rock-steady except for one jump, something went wrong at that jump.

What this gets you in practice

• Freezes, with the time and how long each lasted.
• Missing frames, with the time and how much time is unaccounted for.
• A variable frame rate, which is the thing that makes editors resample your footage and some players stutter.
• Audio that starts off the picture — also free, because the audio timestamps are in the same index.

None of it requires watching the file, and none of it requires a model that guesses. The file was described by the program that wrote it; reading that description back is just faster than re-deriving it.

Check one video free: DiffALL’s video quality checker reports bitrate, focus, noise, compression and whether the frame rate is genuine — and lists freezes, missing frames and timing faults with timestamps, read straight out of the file. No sign-up.

Got the master as well? Compare the two videos for per-second SSIM, a difference heatmap and the exact moment they diverge.