Your Compressed Video Looks Fine Until Something Moves

You compress a clip, scrub through it, pause on a few frames, and it looks good. You upload it. Then you watch it play and the moment the camera pans, the picture dissolves into shifting squares, the background turns to soup, and everything snaps back to normal the instant things settle down.

You did not miss anything. Paused frames are close to the worst way to judge a compressed video, because the thing that broke only exists while the picture is changing.

Video compression is mostly about what did not change

A still image codec has to describe every pixel. A video codec does not, because consecutive frames are overwhelmingly similar, and describing the difference is far cheaper than describing the picture.

So an encoder stores a full frame occasionally and then, for most frames, stores instructions: this block of pixels moved eleven pixels left, this block is unchanged, this block is slightly brighter. A locked-off shot of someone talking against a plain wall compresses astonishingly well, because almost nothing in the frame is new from one moment to the next.

Now pan the camera. Every block in the frame has moved, new scenery is entering at one edge, motion blur has smeared the detail that the predictor would otherwise have matched, and the encoder suddenly needs many times more data to describe the same second of video. If it is not allowed to spend that data, something has to give, and what gives is detail.

That is the whole phenomenon. Static shots are cheap, motion is expensive, and a quality setting that is generous for the cheap parts is not necessarily generous for the expensive ones.

What the quality settings actually control

The Video Compressor's four options set a constant quality target rather than a target file size. That distinction explains a lot of otherwise confusing behaviour.

A constant quality encode means the encoder is told how good the picture should look and spends whatever data that requires, moment to moment. Busy sections get more data, calm sections get less, and the output size falls out at the end rather than being decided at the start.

The practical consequences:

The same setting gives very different file sizes on different clips. A tripod interview and a handheld walk-and-talk at the same setting will not land anywhere near each other. Nothing is wrong. They are different amounts of picture.

You cannot predict the output size in advance, which is why the tool tells you the result afterwards rather than promising it beforehand. Roughly, the top setting tends to take 20 to 40 percent off with very little visible loss and the middle one 40 to 60 percent, but that is a tendency and not a guarantee.

Turning the quality down affects the hard parts first. This is why the failure appears in motion. The calm sections had plenty of margin, so they still look fine. The pans and the handheld sections were already at the edge, so they are where the degradation shows.

How to read what you are seeing

Different failures point at different fixes.

Blocking in motion, where the picture breaks into visible squares during movement and recovers when it stops, is the encoder running out of budget on the expensive frames. Raise the quality setting, or reduce how expensive the frames are.

Detail that pumps, getting sharper and softer in a rhythm, is you noticing the periodic full frames. It is normal and more visible at lower quality settings.

Grain and texture turning into a smeared wash is compression discarding noise, which it treats as expensive and unpredictable, because it is. Film grain, sensor noise from a low-light shot, and foliage all behave this way.

Banding in a sky or a gradient is a different problem with a different fix, and it will not be solved by anything in this article.

The fix nobody tries first: use fewer pixels

When a file is too big, the instinct is to lower the quality. Very often the better move is to keep the quality and lower the resolution.

A 1080p clip at a poor quality setting and a 720p clip at a good one can land at a similar size, and on a phone screen the second one usually looks better. The encoder has fewer pixels to describe, so each of them gets more attention, and there is no resolution at which blocking looks acceptable.

Scale first with the Video Resizer, then compress. This is particularly true for anything destined for a social feed, where the platform is going to re-encode your upload anyway and is going to display it small.

Stabilise before you compress

This one is not obvious and it makes a real difference.

Handheld footage has global motion in every frame: the whole picture shifts slightly, constantly, even when nothing in the scene is moving. From the encoder's point of view there is no static background anywhere in the clip, so the cheapest thing a codec can do is never available to it.

Running shaky footage through the Video Stabilizer before compressing gives the encoder back its static background, and the same quality setting produces a smaller file, or the same file size produces a visibly better picture. You are not tricking the compressor. You are removing work it could not avoid doing.

Trimming helps for the same unglamorous reason: the cheapest second of video is the one you do not include.

Do not compress something that is already compressed

Every lossy encode makes judgements about what to discard. Running a compressed file through again means the second encoder is making those judgements about a picture that already has the first encoder's artefacts in it, and it will faithfully spend data preserving them.

If you have the original, go back to it. Compress once, from the best source you have, with any trimming and resizing done first.

The same logic applies to format conversion: converting a compressed MP4 to WebM is a second lossy pass, not a repackaging. If you need both formats, make both from the same source rather than making one from the other.

Judge it the way it will be watched

Play the whole thing at full size and watch the moving parts. Pick the busiest few seconds you have, the pan, the crowd, the handheld walk, and look at those rather than at the interview segment.

If it holds up there, it holds up. If it does not, you have three levers and they are worth trying in this order: fewer pixels, less motion, then a higher quality setting. The last one is the one everybody reaches for first and it is the one that costs the most file size for the least benefit.

And it happens on your machine

The encode runs inside the browser tab. A clip you are compressing for a client, an internal review, or anything you would rather not hand to a free online converter never leaves the device, and the output appears when the encode finishes rather than when an upload and a download have both completed.