Bitrate, and why the same number is generous and stingy

A number with no meaning on its own

Bitrate is bits per second: how many bits the encoder is allowed to spend describing each second of video. Ten megabits per second is 1.25 megabytes per second, which is 75 MB per minute, which is 4.5 GB per hour. That arithmetic is worth doing in your head, because it converts an abstract slider into a file you have to move.

What bitrate is not is a quality setting you can quote on its own. "Twenty megabits" means something very different at 1080p25 than at 2160p50, and something different again for a static interview than for a football match.

Bits per pixel: the only fair comparison

Divide the bitrate by the number of pixels per second and you get a figure you can compare across formats.

At 1080p25: 1920 × 1080 × 25 = 51.8 million pixels per second. Ten megabits across that is about 0.19 bits per pixel. That is comfortable for H.264 on ordinary material.

At 2160p25 the pixel count is four times higher — 207 million per second. To hold the same 0.19 bits per pixel you need roughly 40 Mbit/s. This is why exporting 4K at the bitrate that looked fine for 1080p produces a mush of smeared detail, and why people conclude their 4K camera is disappointing.

H.265 and AV1 reach similar quality at roughly half the bitrate of H.264 — the usual claim is 40 to 50% savings, and on real footage it lands somewhere in that range rather than reliably at the top of it. Newer codecs buy their efficiency with computation: an AV1 encode can be many times slower than H.264 on the same machine.

Content changes everything

Compression works by not describing what it can predict. A locked-off interview against a plain wall is almost entirely predictable: the encoder describes the face, copies the wall, and spends very little.

Three things destroy that prediction, and it is worth knowing which, because you can sometimes act on them.

Motion, especially whole-frame motion. A handheld whip pan changes every pixel at once. Confetti, rain, water, leaves in wind and crowd shots are all worst cases.

Fine detail, such as foliage, gravel, fabric weave and sequins.

Grain and noise, which are the cruellest, because noise is random. Random means unpredictable, and unpredictable means the encoder must spend real bits on it or throw it away. This is why a beautifully grainy grade looks like porridge after upload, and why denoising slightly before export can make an image look better after compression even though it looks softer before it.

A talking head at 8 Mbit/s can look flawless. The same 8 Mbit/s on a snowstorm falls apart into blocks. Both are 8 Mbit/s.

CBR, VBR and CRF

Three ways to tell an encoder how much to spend.

CBR — constant bitrate — spends the same amount every second regardless of need. It wastes bits on easy passages and starves hard ones. Its one real use is streaming over a fixed-capacity link, and broadcast delivery specs that demand it.

VBR — variable bitrate — is given a target average and allowed to move bits from easy scenes to hard ones. Two-pass VBR analyses the whole file first, then encodes knowing where the difficulty is. Use two-pass when you must hit a file size, and expect it to take roughly twice as long.

CRF — constant rate factor — is the one to reach for when file size is not fixed. You give it a quality number and it spends whatever that quality costs. For x264, CRF 18 is visually near-transparent, CRF 23 is the default and fine for most web work, CRF 28 is visibly soft. Lower is better and each step of about 6 roughly halves or doubles the file.

ffmpeg -i master.mov -c:v libx264 -crf 20 -preset slow -pix_fmt yuv420p \
  -c:a aac -b:a 192k delivery.mp4

-preset slow tells the encoder to work harder for the same quality target, producing a smaller file at the same CRF. Presets cost time, not quality: veryslow might take three times as long as medium for perhaps 10% smaller output.

Most editing applications hide CRF behind a "quality" slider, and Resolve's Automatic quality setting on H.264 is doing approximately this. If you want the number itself, export a master and re-encode with ffmpeg.

The rule that saves the most grief

Encode generously into the platform, because the platform will encode again. Every re-encode is a fresh loss, and losses compound — this is generation loss, and it is why a file that has been through WhatsApp twice looks like a photocopy of a photocopy.

Practically: if you are uploading, do not pre-compress to save upload time. Give YouTube a 1080p file at 16 Mbit/s or a 4K one at 45 Mbit/s and let its encoder work from something clean. The 400 MB you saved by exporting at 4 Mbit/s buys you visible blocking in every viewer's browser, permanently.

Honest limits

Bitrate ladders on platforms change without announcement, and any specific figure in this lesson is a reasonable default rather than a law. The durable part is the reasoning: bits per pixel, content difficulty, and never handing a compressor something already compressed.

Today

Export the same 30-second clip twice — once at CRF 20, once at CRF 30 — and compare file sizes and the look of the most detailed shot. Then do it again with a clip containing motion and grain. The gap between the two pairs is the lesson.