Logo
Back to Blog
Media August 12, 2026 8 min read

CRF vs Bitrate: Video Compression Settings Explained Properly

O

OmniWebKit Team

Media Tooling

Share:
Article Cover Image

You open a compression tool and it asks for CRF or bitrate as though you already know which one you want. Pick wrong and you either get a file that is enormous or a video that falls apart the moment anything moves. The difference is genuinely simple, and it decides everything else.

CRF vs Bitrate in Video Compression: The Actual Difference

CRF targets a quality level and lets the file size land where it lands. Bitrate targets a file size and lets the quality land where it lands.

That is the whole distinction. Everything else follows from it.

With CRF, the encoder spends whatever it needs on each scene to hold a consistent look. A still shot costs almost nothing, a chaotic one costs a lot, and you cannot know the total until it finishes.

With bitrate, you hand the encoder a budget per second and it must fit inside it whatever happens. Calm scenes get more bits than they need. Busy scenes get fewer than they need, and that is exactly where the picture breaks.

What Is CRF in Video Encoding, in Plain Terms

CRF stands for constant rate factor. It is a dial for how much detail the encoder is allowed to throw away.

Lower numbers keep more and produce bigger files. Higher numbers discard more and produce smaller ones. The scale runs from mathematically lossless to visibly destroyed, and the useful range sits well inside those extremes.

A rough rule that holds well enough in practice: each step of about six roughly halves or doubles the file size. That is more useful than memorising values, because it tells you how far to move when a result is not quite right.

Worth being honest about: CRF is perceptual, not a measurement. The same value looks different across codecs and across footage. Anyone quoting a single correct number has not tested it on much material.

Choosing the Best CRF Value for H.264 Without Guessing

Start in the middle and move once. Two attempts usually settle it.

If the result is too big, raise the number and re-encode from the original. If it looks soft, lower it. What you should not do is chain attempts on top of each other, because each pass compounds the damage of the last.

Match the value to where the video is going. Something being watched once on a phone tolerates far more compression than footage someone will edit or project. There is no universal right answer, only a right answer for a destination.

Our presets in the apply these settings tool state their CRF openly rather than hiding it behind words like "medium", so you can reason about the trade instead of guessing.

Why Video Bitrate Explained as a Single Number Misleads People

A bitrate figure means nothing without the resolution and frame rate beside it.

Five megabits per second is generous at 720p and thin at 4K. The same number describes a comfortable encode and a broken one depending entirely on how many pixels it has to cover.

Frame rate multiplies it again. Doubling from 30 to 60 frames a second halves the bits available per frame at the same bitrate, which is why high frame rate footage needs far more than people expect.

This is why "what bitrate should I use" has no answer, and why tools that ask only for a bitrate leave you worse informed than ones that ask for a quality target.

Where the Bits Actually Go

Motion, almost entirely. Video codecs store differences between frames rather than whole pictures.

A locked-off shot of someone talking is nearly free, because most of each frame is identical to the last. Handheld footage, rain, confetti or a crowd changes every pixel every frame, leaving nothing to reuse.

Two clips at the same resolution, length and settings can differ in size by a factor of five for this reason alone. It is also why file size predicts encoding time poorly — the work follows movement, not megabytes.

The practical takeaway: stabilise the shot if you can. A steadier source compresses better than any setting change will achieve.

Why Trimming Beats Every Setting Here

Everything above is a trade. Removing footage is not.

Cutting ten seconds you did not want removes that data completely while leaving every remaining frame untouched. No CRF value, preset or bitrate gives you that, because they all work by degrading what you keep.

So the order that makes sense is: trim first, downscale second, adjust quality last. Most clips have several seconds of slack at either end, and cut the clip down first without re-encoding anything.

Once there is nothing left to cut, then start trading. And if the destination is a messaging app, what double compression costs you explains why getting it right in one pass matters more than the settings themselves.

The Short Version

Understanding CRF vs bitrate in video compression comes down to which one you are willing to let vary. Quality or size — you get to fix one.

Use CRF unless something downstream demands an exact file size. Always re-encode from the original rather than from a previous attempt. Change the codec settings before you change the container.

Need a different format rather than a smaller file? Change the container instead, and the same trade-offs apply with different labels. The image side of this works identically — lossless versus lossy, in general covers the same ideas with stills.

Frequently Asked Questions

If CRF gives better quality, why does anything still use bitrate?

+
Because some destinations need a predictable file size or a guaranteed data rate. Streaming platforms and hardware players often require it. CRF cannot promise a size in advance, which makes it unsuitable when the ceiling is contractual.

Why does the same CRF produce wildly different file sizes?

+
Because CRF targets quality, not size. A static shot at CRF 23 might be a tenth the size of a handheld shot at the same value. That variability is the feature, not a fault.

Does a slower preset actually improve quality?

+
It improves efficiency rather than quality. A slower preset finds a smaller file at the same visual quality by searching harder. The picture at a given CRF stays roughly constant; what changes is how many megabytes it takes.

Is two-pass encoding worth the extra time?

+
Only when you are targeting a specific file size. The first pass measures the video so the second can allocate bits sensibly. If you are using CRF, a second pass adds nothing because there is no size budget to allocate.

Why does my compressed video look fine until something moves?

+
Encoders spend their budget where the picture changes. A static frame holds up because there is little to encode. Fast motion exhausts the budget within a few frames, which is where blocking appears first.

Does raising the bitrate fix a bad-looking encode?

+
Up to a point, then it stops helping. Past the level the source can support you are spending bits describing noise and compression artefacts rather than detail. The fix is usually a better source, not a bigger number.

What does the CRF scale actually measure?

+
Roughly how much quantisation the encoder may apply, which is how much detail it discards. It is perceptual rather than mathematical, and the scale is not linear, which is why advice comes as ranges rather than exact values.

Do CRF values mean the same thing in H.264 and H.265?

+
No, and assuming they do is a common mistake. The same number produces different quality and different sizes between codecs. Values learned on one do not transfer to the other.

Does audio bitrate deserve any attention?

+
Less than people give it. Audio is a small share of a typical video file, so halving it saves little. The exception is a long clip that is mostly a static image, where the soundtrack becomes most of the file.

Why does re-encoding an already-compressed file look so bad?

+
The encoder cannot tell artefacts from detail. It spends bits preserving the blocking left by the previous pass while discarding real texture. Always go back to the original source rather than compressing the compressed copy.

Tags

#Video#Compression#FFmpeg#Encoding