Constant Bitrate Is Lying to You: Why Average Quality Is a Meaningless Number

TL;DR: A fixed bitrate gives you one comfortable "average quality" number that hides the truth: your hard scenes (motion, dark, detail) are quietly collapsing while the easy scenes waste bytes. The fix is to stop fixing size and start fixing quality (CRF) — let each scene take what it needs. I switched to HEVC with constant quality, got ~30% smaller files at higher quality, and fixed playback glitches I'd wrongly blamed on the CDN. Encoding runs slower, but the savings repeat with every view. The average isn't a measure — it's a hiding place.

Have you ever stopped to ask yourself a simple question?

How does a movie with a 25 GB source play instantly on your platform? And how does that same movie end up as a 4 GB file? How do Netflix, Disney, and the rest ship higher quality at a smaller size?

I asked myself these questions for six years and never found a real answer. For most of that time, I assumed they had some kind of magic I couldn't touch — a different class of system, out of reach. So I never looked too hard. Until one day I decided to actually understand it, and test it with my own hands.

In the end, it was worth it. I discovered a lot of mistakes, and I changed beliefs I'd held for years.

The comfortable lie

For as long as I can remember, I've wondered how you keep video quality steady across an entire movie. I'd look at an original file — sometimes 80,000 kbps — and ask: how do I get that quality at a fraction of the size, without it ever dropping?

So I did what everyone does. I searched. The common advice: for 1080p, 2500 kbps and up gives you good quality. Fair enough. But whenever I wanted things sharper, I'd nudge it higher. And higher. Until I settled at 4000 for 1080p and called it my standard. If a movie had a lot of motion, I'd bump it to 5000, even 6000 — convinced that "consistent quality" simply meant a consistent bitrate held across the whole film. As far as I was concerned, H.264 at a fixed bitrate was the correct default for everything.

Then I actually measured it

One day I decided to check for myself. Not by feel — by numbers. There's an actual scientific way to measure video quality, the same kind of thing companies like Netflix rely on. It's called VMAF: a score that compares the compressed video against the original and tells you how close it really is.

I ran it on my files. The average came back good — mostly above 90. I felt reassured. The number was telling me my work was fine.

But I went deeper. Instead of the average for the whole movie, I looked scene by scene. And that's where it hit me. The calm scenes looked great, sitting between 90 and 94. But the moment a scene had motion, or went dark at night, the quality collapsed. I found scenes at 45. Not a small dip. A collapse. The worst moment was landing at half the quality the average was showing me.

So the average was lying to me. Not by being a wrong number — by hiding. It takes the beautiful scenes and the breaking ones, blends them, and hands me a single comfortable number. And that number was covering up the fact that people were watching broken scenes while I had no idea.

That's when I decided to really understand this. I grabbed the heaviest, most motion-packed movie I'd ever come across and started measuring VMAF scene by scene. I'd been watching this film and noticing moments that felt almost sped up, like a 2x glitch — and I always thought it was the internet. So I dug in, deeper and deeper. And every time, the numbers kept surprising me: the gap between what I thought was happening and what actually was.

Why it happens

When you set a fixed bitrate, you're telling the encoder: "give every second the exact same size." No matter what's in it.

But scenes aren't the same. Two people talking in a room, camera still — that doesn't need a big size, so you waste bits it never asked for. A scene with motion, people running, explosions, or a dark night full of fine detail needs much more to stay clean. And you've locked the budget at a fixed number. So the encoder has no choice but to crush the hard scene — and that's where it breaks.

In the same movie, you're doing two wrong things at once: wasting on the easy scenes, and breaking the hard ones.

Think of it like giving yourself the exact same allowance every single day. On a day you stay home, it's more than you need. On a day something goes wrong, it's not enough and you're in trouble. The number isn't wrong — what's wrong is that it's fixed, and it can't tell one day from another.

Flipping the equation

Here's the shift that changed everything. What if, instead of fixing the size, I fix the quality?

So instead of "give every second the same size," I tell the encoder: "I want a certain quality level, and I want it to stay the same. Spend whatever each scene needs to get there." The hard scene takes more, the easy scene takes less — but the quality stays constant.

This was the exact opposite of what I'd believed. I was convinced "constant quality" meant "constant bitrate." The truth was the other way around: real constant quality needs a variable bitrate — up in the hard parts, down in the easy ones. This approach has a name: CRF, or constant quality.

But going down this road, I had another decision to make. If I was chasing higher quality at a smaller size, H.264 alone wasn't going to get me there. So I moved to HEVC (H.265) — a newer codec that delivers the same quality at a much smaller size. That decision wasn't simple, though. People watch on a huge range of devices — Android TV, Apple TV, phones, iPhones, Amlogic-based boxes, and players like VLC that can be aggressive in their own way. I had to be sure the vast majority could actually play it before I committed. So I did my homework on the devices first.

The mistakes

Here's where the real journey started.

I grabbed the heaviest action movie I had — a huge source file, packed with fire and effects from start to finish. I took a two-minute clip from one scene and tested different CRF values on it — 20, 22, 24 — comparing the average and the minimum for each.

First mistake: I calibrated on a single scene. That scene told me CRF 22 gives a quality of 95, and I assumed the whole movie would land there. I was completely wrong. When I ran the full film, it came out at 7.87 GB — bigger than my old 6.25 GB version, the one I was trying to improve on. The scene I'd picked was calmer than the movie's average, so every estimate was built on a lying number. A single sample lies the exact same way an average does — you have to sample across the whole film to know its real difficulty.

Second mistake: I aimed for far more quality than I needed. CRF 21 was giving me around 96 — but my old version was already sitting at about 90. I was asking the encoder for much higher quality than I actually needed, and that's what blew up the size. Once I set the target at a sensible level — a bit higher than the old one, not massively higher — the size dropped to 4.34 GB. About 30% smaller, at a higher quality.

The ceiling (maxrate). I had a cap on the instantaneous bitrate and was stubbornly holding it at a low number. But digging into the heavy scenes, I found a hard scene sometimes needs much more headroom to stay clean — that low ceiling was starving them. So I raised it to a sensible number: high enough that it never chokes a hard scene, but controlled enough to stop some freak scene from grabbing a crazy bitrate that breaks playback on weaker devices. Don't starve any scene, but don't give any scene more than it deserves either.

In the end, on the hardest film I have: about 30% smaller, at higher quality — and most importantly, the worst moment in the hard scenes went from 51 to 83. That number that used to break in front of the viewer was finally clean.

The cost side

Every extra gigabyte in a file isn't charged once. The movie gets encoded once, but it gets watched thousands of times — and with every view, those extra gigabytes ship from the CDN and land on your bill. A wrong encoding setting doesn't cost you once. It costs you every day.

And there are things in encoding that quietly kill both the experience and the bill, without you noticing:

Fixed bitrate wastes on the easy content — you're shipping bytes nobody asked for.
Faststart: a properly built file starts playing immediately, without waiting for it to load. This is what makes byte-range requests work right — the server sends just the part the user needs, when they need it. Get it wrong, and you get waiting and stutter at the start of every video.
Variable framerate (VFR): remember the 2x glitch I blamed on the internet? It wasn't the internet — it was my own settings. The source has a constant framerate, and my VFR setting was turning it variable, causing stutter and speed-ups on certain devices. A constant framerate (CFR) fixed it at the root.

I changed all my settings based on what I'd learned. The decision wasn't free — the one downside is that encoding got slower. But in return: smaller size, a smaller CDN bill, and smoother playback. Encoding happens once; the payoff repeats with every view.

And the takeaway: a lot of us blame stutter or slowness on the CDN. But plenty of the time, the problem isn't the CDN — it's what we're sending to it.