If two files are the same size, which one looks better?

Usually the lower-resolution one. The same data spread across four times as many pixels leaves less to describe each pixel, so a 1080p encode at a given size typically holds more real detail than a 4K encode squeezed into the same budget.

Can I compare bitrate numbers between different codecs?

No. Newer codecs such as H.265 and AV1 reach comparable quality at lower bitrates than H.264, so a bitrate figure only means something alongside the codec name. Many listings state one without the other.

Why do dark scenes look blocky when bright ones look fine?

Compression allocates data where the encoder predicts you will notice it most. Smooth dark gradients and film grain are expensive to encode, so they are usually the first thing sacrificed when the bitrate budget runs short.

Why Bitrate Matters More Than Resolution

Bitrate is the amount of data used to describe each second of video, and it decides how much of the detail a resolution promised actually survives compression. Given the same file size, a higher-bitrate 1080p encode will usually look better than a bitrate-starved 4K one.

Bitrate decides how much of a picture survives. Resolution tells you how many pixels a file is allowed to have; bitrate tells you how much information is spent describing them each second. Offered a higher-resolution file and a higher-bitrate one at the same size, take the higher bitrate.

The reason is arithmetic. Moving from 1080p to 4K multiplies the pixel count by four. If the data budget does not also grow, each pixel gets roughly a quarter as much information to describe it. The file gains a bigger grid and loses the detail that would have made the grid worth having.

What is bitrate actually measuring?

Bitrate measures how many bits per second the encoder spends storing the video — the running cost of describing motion and texture over time.

A codec does not store every pixel of every frame. It stores a starting frame, then predicts what changes next and records the difference, discarding whatever it judges you are least likely to notice. Bitrate is the allowance for that process. A generous allowance means the encoder can afford to keep subtle texture; a tight one forces it to throw away more, and the discarding is irreversible.

This is why the same source can produce wildly different-looking files at the same resolution. The resolution was identical. The budget was not.

What is the difference between constant and variable bitrate?

Constant bitrate (CBR) spends the same data on every second regardless of what is happening; variable bitrate (VBR) spends more on hard sections and less on easy ones.

VBR is almost always the better choice for stored video, because video content is wildly uneven in difficulty. A static shot of a bedroom needs very little data. A handheld shot with fast movement, grain and shifting light needs a great deal. CBR either wastes budget on the easy parts or starves the hard ones, and usually does both. Streaming delivery leans toward more constrained bitrates for predictability, which is one reason a stream and a download of the same title can look different.

Which kinds of scenes are the most expensive to encode?

Anything with a lot of unpredictable change: fast motion, handheld camera movement, film grain, sensor noise, and smooth gradients in low light.

That list describes an uncomfortable amount of this material. Dim lighting produces sensor noise, which looks random to the encoder and therefore cannot be predicted or compressed efficiently. Handheld work means the whole frame shifts between frames rather than a small part of it. Skin under low light is mostly gentle gradient, which is exactly what banding attacks.

The practical consequence is that a bitrate which looks perfectly adequate on a brightly lit, tripod-mounted studio scene can fall apart on a dim handheld one in the same file.

What do compression artefacts tell you?

Each artefact has a specific cause, so what you see identifies what went wrong.

What you see	What it tells you
Blocky squares in dark areas	Bitrate exhausted; the encoder ran out of budget for shadow detail
Banding — visible steps across a smooth gradient	Too few levels retained, often compounded by 8-bit colour depth
Smearing or ghosting during fast motion	Motion prediction failing under a tight budget
Skin looking waxy, pores and fine hair gone	High-frequency texture discarded first, a classic starvation symptom
Mosquito noise shimmering around edges and text	Ringing from aggressive quantisation near sharp boundaries
Detail that is soft even when paused	Either an upscale or a heavy re-encode; more pixels, less information

Notice that none of these are fixed by raising the resolution. Every one of them is a symptom of insufficient data per pixel, and adding pixels makes the data-per-pixel problem worse.

Why does re-encoding make things worse each time?

Because lossy compression is not reversible, and every pass discards information that the next pass then treats as if it were real detail.

When a file is re-encoded, the encoder sees the previous encode's artefacts — its blocking, its banding, its ringing — and dutifully spends bitrate preserving them. Generational loss accumulates. A file that has been through several rounds can look markedly worse than the original at the same nominal resolution and a similar size, and there is no way to recover what was dropped along the way.

This matters when the same title circulates in several versions. The label may be identical across all of them; the encoding history is not, and it is usually undocumented.

Can you compare bitrate numbers directly between files?

Only within the same codec. A bitrate figure is meaningless without knowing which codec produced it.

Newer codec generations are more efficient: H.265/HEVC reaches comparable quality to H.264/AVC at a lower bitrate, and AV1 improves on H.265 again. So a file encoded with a newer codec at a lower stated bitrate may look better than an older-codec file at a higher one. Comparing the two numbers without the codec names attached produces exactly the wrong conclusion.

The headline percentages are worth knowing and worth distrusting in equal measure. ITU announced HEVC as needing half the bitrate of H.264, and later announced H.266/VVC as needing half the bitrate of HEVC for the same quality at high resolutions. AOMedia's launch claim for AV1 was around 30% better compression than "competing codecs" for 4K, based on tests run by its own member companies rather than by a standards body.

Note where those numbers live: in press releases, not in the standards. The codec specifications themselves state no percentage at all. The figures describe what a generation's toolset can achieve under favourable conditions, and real output varies with encoder implementation, preset, content and rate control — which is why we compare files rather than codec generations further down.

Sources: ITU press releases on H.265 (2013) and H.266/VVC (2020); AOMedia AV1 release announcement (2018); checked 2026-08-03.

There is a trade-off attached. Newer codecs demand more decoding work, and hardware decode support varies by device and player. An efficient file that your device has to decode in software can stutter where a less efficient one plays smoothly.

No authoritative table maps hardware decode to device generation, and the two platform vendors deliberately avoid publishing one. Android's compatibility requirements have made AV1 decode mandatory on handsets since Android 14, but that mandates the capability, which a software decoder satisfies; hardware AV1 decode is only required through an opt-in performance-class tier. Apple's recommended method is a runtime query rather than a lookup, and its own spec pages distinguish a Mac "media engine" hardware claim from an iPhone "supported format" claim. The practical answer is to test your own file on your own device.

Sources: Android Compatibility Definition Document, §2.2.2 and §5.3; Android Media Performance Class requirements; Apple VideoToolbox documentation (VTIsHardwareDecodeSupported); checked 2026-08-03.

So which version should you actually choose?

Use the file's size relative to its runtime and resolution as your proxy for bitrate, since a stated bitrate figure is often unavailable.

Situation	Choose	Why
Two versions, same resolution, one much larger	The larger one	More data per pixel, fewer artefacts
4K and 1080p at a similar file size	The 1080p	The 4K is spreading the same budget over four times the pixels
4K that is roughly four times larger than the 1080p	The 4K	The budget scaled with the pixel count, so the detail is likely real
Newer codec at lower bitrate vs older at higher	Newer, if your device decodes it in hardware	Better efficiency, provided playback is smooth
Mostly dark, handheld or grainy content	The highest bitrate available	These are the scenes that break first under compression
Watching on a phone	Bitrate over resolution, every time	The screen cannot show the extra pixels anyway

The general rule that falls out of all of this: when you have to trade, trade resolution away and keep bitrate. A clean 1080p file is a better watch than a 4K file that has been squeezed to the same size, and it costs less to store, stream and decode.