Bitrate vs resolution

Two numbers decide how a video looks, and most people only pay attention to one of them. Resolution is the pixel count: 1920x1080, 3840x2160. Bitrate is how many bits per second the file spends describing those pixels. Resolution sets the size of the canvas. Bitrate decides how much paint you get.

Starve a 4K file of bitrate and it will look worse than a well-fed 1080p one, on the same screen, every time. This is not a marginal effect. It's the single most common reason a video that should look good doesn't.

Why more pixels need more bits

A 4K frame has four times as many pixels as a 1080p frame. Hold the bitrate constant and each pixel gets a quarter of the description it had. The encoder responds the only way it can, by grouping pixels together and describing them as blocks rather than individually.

That's what compression artefacts are. Blocking in dark areas, banding across skies and gradients, smeared texture on skin and hair, and detail that dissolves whenever the camera moves. The frame is still technically 3840 pixels wide. It just doesn't contain 3840 pixels worth of information.

What the numbers actually look like

Treat those as starting points rather than rules. The honest answer is that the right bitrate depends on the content, and the way to find it is to encode a difficult thirty seconds and look at it, not to trust a table.

A rule of thumb that holds up

If you have to choose between resolution and bitrate, choose bitrate. A clean 1080p file beats a starved 4K one on any display, because a good scaler upsizing clean pixels produces a better picture than a decoder reconstructing damaged ones.

The exception is upload, where platforms tie their bitrate allocation to the resolution you give them. There, going up in resolution can buy you a bigger budget than you would otherwise qualify for, which is a quirk of how the platforms work rather than anything about the format.

We measured what a starved source costs, on our own clip

The claim above is easy to assert and awkward to demonstrate, so we measured it. Crisp 1.0.1223, 2026-09-15, on boxing-before.mp4 — our own published demo clip, native 1280x720. That native file is the ground truth, which is what makes this a measurement rather than an opinion: we can score a rebuilt frame against the frame it was rebuilt from.

We made the same clip small in two different ways, then brought both back to 720p by three routes and scored the results against the surviving original with the bundled ffmpeg's psnr filter and libvmaf, Netflix's perceptual metric, which is compiled into that same ffmpeg and needs no network call. The harness scores 60 frames per clip. The two low-resolution inputs:

• A clean 640x360, made by lanczos-downscaling the truth. Fewer pixels, no compression damage. Resolution reduced, information mostly intact.
• A bitrate-starved copy, built the way a real file gets damaged: crf 40 plus added noise. Information destroyed.

Higher is closer to the original on both scales. Two things in that table are the whole point of this page.

First, starving the source costs every route enormously. The plain resize falls 14.2 dB and 67.9 VMAF points. The compact model falls 8.5 dB and 57.7 points. The denoised model falls 11.2 dB and 69.4 points. Nothing in the second column is close to the first. The pixels were put back in all six cases; the information was not, because it was not there to put back.

Second, the ranking does not flip. Same order on both metrics in both columns: resize, then the denoised model, then the compact one. Damage narrowed the gaps — the compact route's VMAF deficit against the resize goes from 23.4 points to 13.2 — but it reordered nothing. A starved source does not turn out to be the case where a model finally wins; it is the case where everything does worse.

This is the unflattering half of our own measurement and we would rather publish it than the other half. If you came here hoping an upscaler would undo a bad export, the number to take away is 26.56 dB — what the best of the three routes managed from a file whose bits had already been thrown away.

What these numbers do and do not say

PSNR measures agreement with the original file pixel by pixel. VMAF is the perceptual one of the pair, built to predict what a viewer would report, but it is still scored against the original rather than judging the frame on its own. Neither answers "which one would you rather watch." They answer "which one landed closest to the file that used to exist," which is the question a page about lost information should be asking, and the only one we can answer without putting our own taste in the result.

That distinction matters most for the model routes. A generative upscaler does not recover the eyelash the encoder discarded; it produces an eyelash, and a convincing one can sit several decibels away from the real one. Fidelity metrics punish plausible-but-different detail, which is exactly what these models make.

Three metrics give three answers, and we will not quote one of them as though it were the verdict. Across a wider grid of nine clip-and-noise cells from the same harness, a plain lanczos resize wins all nine on VMAF, four of nine on PSNR, and three of nine on SSIM. Picking a favourite metric there would let anyone write whichever conclusion they arrived with. What survives all three is the thing this page is about: on a clean source a plain resize is closest to the original on every measure, and no route recovers discarded bits on any of them.

Two more limits, stated rather than buried. The clean 360p was made by lanczos-downscaling the truth, so a lanczos upscale partially inverts the exact operation that degraded it — structurally favourable to the resize, and not how real low-resolution footage comes into existence. The starved column exists precisely because it is not vulnerable to that, and it is where the resize's scores collapse hardest. And scale and model cannot be separated in Crisp: the model that runs is chosen by the denoise value and the scale factor together, so nothing here should be read as attributing to resolution what the model may have caused. Every row above is the same 2x geometry on the same clip.

Finally, an omission we are not going to paper over: this page publishes no timing figures. The runs were timed, but the machine they ran on was never recorded, and a seconds-per-clip number without the hardware beside it is not a fact anyone can use. It will go in when it is measured on a named machine.

What to do with a file that's already starved

You can't recover information the encoder discarded. What you can do is stop making it worse and clean up what's visible. An upscaler trained on compressed footage will reconstruct plausible texture where blocking removed it, and in Crisp the denoise value is what decides which model does that work: below 0.5 at 2x the job goes to 2x-ParimgCompact, and at 0.5 and above it goes to RealESRGAN_General_WDN_x4_v3, with a temporal-and-spatial filter pre-pass running before the model above 0.5 as well. All of it runs on your Mac. Do it before any re-encode rather than after, since a second compression pass will otherwise preserve the artefacts as if they were detail. The denoise setting page has the full routing table and the measurements behind it.

Set your expectations from the second column of that table, though. Cleaning up a starved file makes it more pleasant to look at. It does not make it the file you would have had if you had exported it properly the first time.

What Crisp itself does with bitrate

Because this is the thing the page is about, it is worth saying what our own app does with the number rather than leaving it implied.

Exports are budgeted from the output dimensions. Crisp derives the target rate from the frame size on a continuous curve — roughly 4.5 Mbps per megapixel plus 3, clamped between 8 and 100 Mbps. That lands near 8 Mbps at 720p, 12 at 1080p, 20 at 1440p and 40 at 4K, which is the same shape as the working ranges in the table above. It replaced a bucketed ladder that put quality cliffs at the 1080p and 1440p boundaries.

But the budget is capped to the source. A curve derived from dimensions alone will happily spend 8 Mbps re-wrapping a 600 kbps web clip, buying detail the source never had and handing you a bigger file for nothing. So every lane that does not add information — trim, crop, rotate, speed, fade, loop, border, stabilize, reframe, grade, caption, split-screen — is capped at 1.2x the rate the file already has. This was not a theory: before the cap existed, a 640x360 clip at 599 kbps came back at 1.5x its original size, and longer fixtures at 4 to 7x.

And the compress tool targets a fraction of your file's own rate, not a resolution ideal: roughly 30% of it for the smallest level, 50% for the middle one and 70% for the lightest, with a floor that scales with the frame size rather than a flat number. If it cannot save you at least about a tenth of the file it refuses in plain words — "this clip is already small — there's little left to compress" — instead of handing back a "compressed" file that is bigger than the one you started with. That behaviour is the same idea as this whole page: bits, not pixels, are the thing being spent. There is a walkthrough at how to compress a video on a Mac.

Bitrate questions

Is a bigger file always better?

Up to a point, and then it stops mattering. Past the bitrate a scene actually needs, extra bits describe information the encoder has already captured perfectly well, and you're only making the file harder to store and slower to upload. The point of diminishing returns depends entirely on how difficult the footage is.

Should I export at a higher resolution than I shot?

For upload, often yes, because platforms allocate bitrate by resolution. For archival or local playback, no. You aren't adding real information, and you're making every future operation on the file slower.

What is variable bitrate, and should I use it?

Variable bitrate lets the encoder spend more on difficult scenes and less on easy ones, which is almost always what you want for delivery. Constant bitrate is mainly useful when something downstream needs a predictable data rate.

Why does my footage look worse after editing even though I didn't change anything?

Because exporting re-encodes it. Unless you're stream-copying, the export is a fresh compression pass, and any clip that passes through it loses a little. Keeping an intermediate or high-bitrate master limits how much that accumulates over successive edits.

Will upscaling a low-bitrate video to 4K fix it?

No, and we measured how far off it is. Rebuilding our own 720p demo clip from a bitrate-starved copy (crf 40 plus noise), the best of three routes reached 26.56 dB PSNR and 31.13 VMAF against the surviving original, where the same routes from a clean 360p copy of the same clip reached 40.77 and 98.99. All three routes lost heavily and the ranking between them did not change. Upscaling adds pixels; the information the encoder discarded is not in any of them.

What bitrate does Crisp export at?

It is derived from the output frame size — roughly 4.5 Mbps per megapixel plus 3, clamped between 8 and 100 Mbps, which lands near 8 Mbps at 720p, 12 at 1080p, 20 at 1440p and 40 at 4K. Every lane that does not add information is then capped at 1.2x whatever rate your source already had, so a small web clip is not re-encoded far above its own rate. The compress tool works the other way round, targeting roughly 30, 50 or 70 percent of your file's own bitrate depending on the level you pick.

Related

• Film grain and digital noise are not the same thing
• What is a keyframe?
• What is a video codec?
• When AI upscaling beats a plain resize
• The Video Upscaler Index

Download Crisp for Mac Free to try, one-time $129 to remove the watermark. Runs entirely on your Mac.