Resolution vs Bitrate: Which One Is Making Your Video Look Bad

Two files, both eight megabytes, both thirty seconds long. One is 4K. One is 720p. The 720p one looks better, and everyone who watches them disagrees about why.

The 4K file is not lying about being 4K. It really does contain 3840 by 2160 pixels in every frame. What it does not contain is enough information to make those pixels mean anything.

The two numbers describe different things

Resolution is how many pixels the encoder has to account for. A 4K frame has 8.3 million of them, a 1080p frame has 2.1 million, and a 720p frame has 0.9 million. Going from 1080p to 4K quadruples the encoder’s workload before a single decision about quality has been made.

Bitrate is how much information per second the file is allowed to spend describing them. It is a budget, in bits, and it is fixed regardless of how many pixels are asking for a share.

Divide one by the other and you get the thing that actually determines how a video looks: bits per pixel. The same budget spread over four times the pixels gives each one a quarter of the description. This is why upscaling a video and re-encoding it at the same size makes it look worse, not better. You added pixels and gave the encoder nothing extra to describe them with.

8 MB / 30s  ->  about 2100 kbps total
  at 1280x720 / 30fps   ->  roughly 0.076 bits per pixel
  at 3840x2160 / 30fps  ->  roughly 0.008 bits per pixel

At the lower figure a modern codec is no longer preserving detail. It is inventing a plausible smear where the detail was.

What the encoder is actually buying with those bits

It helps to know where the bits go, because it explains the failure mode people find most confusing: a video that looks fine for twenty seconds and falls apart for three.

A codec does not store each frame as a picture. It stores a few reference frames in full and describes the rest as changes from their neighbours: this block moved four pixels left, this region is unchanged, this area is new and here it is. A locked-off shot of someone talking changes very little between frames, so most of the description is “unchanged” and costs almost nothing. A camera pan changes every pixel simultaneously, and there is no cheap way to say that.

So the bitrate is not spread evenly across the clip in any meaningful sense. Difficult seconds want far more bits than easy ones. When a fixed budget cannot supply them, the encoder degrades everything in frame at once, which is exactly the “it goes to mush when anything moves” effect.

This is also why the same settings produce wildly different results on different footage. A bitrate that flatters an interview will destroy a football match.

Constant quality is the answer most of the time

There are two ways to tell an encoder what you want, and they fail in opposite directions.

Target a quality level. You specify how much loss you will tolerate, and the encoder spends whatever bits that takes, more on hard scenes and fewer on easy ones. The output size is unpredictable, but the look is consistent from start to finish. In x264 this is the CRF scale, where a higher number means a smaller file and more loss. Our own Compress Video presets sit between CRF 26 for general use and CRF 32 for the tightest sharing target, pairing each with a resolution cap, because a quality figure alone cannot promise a file will land under a platform’s limit.

Target a file size. You specify the bytes and the encoder derives a bitrate from your clip’s duration. This is the right tool when something genuinely enforces a cap, and the wrong one otherwise, because it hands easy scenes more bits than they need and starves the hard ones.

The size-targeting arithmetic is worth seeing once, because it makes the constraint obvious:

video bitrate = (target size in bits / duration in seconds) - audio bitrate

Audio is a fixed reservation taken off the top. Compress Video to Size reserves 96 kbps for it, and that subtraction is the whole reason long clips at small targets are impossible rather than merely bad: a ten-minute video targeted at 8 MB has less than nothing left for pictures once audio is paid for. The tool refuses and says so, rather than producing a technically-valid file that is unwatchable. It also holds a floor at 125 kbps of video, below which the result stops being worth encoding, and a ceiling at 20000 kbps, above which more bits buy nothing you can see.

If the sum comes out infeasible, the honest fixes are to shorten the clip or accept a larger file. There is no encoder setting that recovers it.

When resolution really is the problem

Everything above argues for suspecting the bitrate first. There are two cases where the resolution is genuinely the thing to change.

The pixels are wasted on the destination. A 4K clip that will only ever be watched in a small embedded player is spending its entire budget describing detail nobody will see. Dropping it to 1080p with Resize Image and video tools frees the whole budget for the pixels that remain, and the result at the same file size looks sharper, because each surviving pixel is better described.

The bitrate cannot be raised. When a hard cap is in play, lowering the resolution is the most effective way to raise bits per pixel, since it reduces the denominator instead of trying to increase a numerator you do not control. This is why our compression presets pair a quality target with a resolution cap rather than offering either alone: at the tightest setting, a smaller frame that is well described beats a larger frame that is not.

Note what this is not. It is not “4K is bad”. It is that resolution is a claim about detail, and a claim you cannot fund is worse than a more modest one you can.

Frame rate is the third number, and it is not a compression knob

Frame rate is often lumped in as a way to shrink a file. It does reduce size, but less than the arithmetic implies: halving 60 fps to 30 does not halve the bytes, because the frames that remain are further apart in time, differ more from each other, and therefore cost more each.

More importantly it is a visible creative change. 24, 30 and 60 fps do not look like the same footage at different sizes. They look like different footage. And the conversion itself is not free: a straight frame-rate change duplicates or drops whole frames, which is why 60 to 30 is clean and something like 30 to 24 introduces uneven motion, since the frames do not divide evenly. Convert Video FPS does exactly that honest duplicate-and-drop and deliberately does not offer motion interpolation, because inventing in-between frames that were never filmed is a different operation wearing the same name.

Change frame rate when you want the motion to look different. Do not reach for it to save bytes.

Diagnose before you re-encode

Every re-encode costs quality, because you are compressing an already-compressed image. So the one genuinely free step is to look at what you have before changing anything.

Open the file with Video Info Viewer and read four numbers: resolution, duration, overall bitrate, and frame rate. Then divide.

• High resolution, low bitrate. The classic case. The file is promising detail it cannot deliver. Either lower the resolution or raise the bitrate, and if a cap forbids the second, the first is your only move.
• Low resolution, high bitrate. Rare, and comfortable: there is room to compress with almost no visible loss.
• Both reasonable, still looks bad. Suspect the source. A re-encode of a re-encode inherits every artifact of the original, and no setting recovers detail that was discarded two generations ago.

That last case is the one worth internalising. Bitrate and resolution decide how well a file preserves what it was given. Neither can put back what was already thrown away.