Last updated: August 2026.
Every H.264 export dialog has a dropdown you’ve probably never touched. HandBrake calls it “medium,” OBS shows you a P-number, ffmpeg buries it in a flag, and nobody explains what it does. So most editors either leave it alone forever or crank it to the slowest setting on the theory that slower means better. Both moves are wrong, and the reason why will do more for your exports than any other setting on the page.
This page is the reference: the x264/x265 preset ladder, what CRF means, how the NVENC, Quick Sync, and AMF hardware presets compare, and where all of it hides in Premiere Pro, DaVinci Resolve, and HandBrake. The guides that already cover this stuff are written for streaming-infrastructure engineers. This one is written for people staring at an export dialog.
If you just want the answer: uploading to YouTube, Instagram, or TikTok, use your GPU’s hardware encoder, 1-pass, at a generous bitrate, because the platform re-encodes 100% of uploads anyway. Making an archival or client master that will be watched as-is, use software x264 or x265 on the slow preset with CRF 18 to 20. Live streaming, hardware is the only real option. The rest of this page is the why, and the exceptions.
The two dials everyone conflates
Encoding has two separate controls that get mashed together in most people’s heads:
The quality target is what you’re asking for. That’s CRF, or a bitrate, or Resolve’s quality slider. It decides how good the output looks and roughly how big the file is.
The preset is how hard the encoder works to hit that target. Slower presets turn on more analysis: the encoder tries more ways to describe each frame and keeps the cheapest one that still meets the quality you asked for. Same picture, fewer bits.
So does the slow preset look better than the fast one? At the same CRF… no. It looks the same and the file is smaller. Preset trades your time for compression efficiency, not for image quality. Once that clicks, every dropdown in every encoder on earth starts making sense.
The x264 and x265 preset ladder
x264 (software H.264) and x265 (software HEVC) share the same ten-step ladder, from ultrafast to placebo, with medium as the default in both. The spread is wide: by ffmpeg’s own normalized 1080p timings, veryslow costs about 2.8x what medium does while ultrafast saves 55%, so end to end you’re looking at roughly a 6x difference in encode time, and at a matched CRF an ultrafast file lands noticeably larger than a veryslow one for the same perceived quality.
| Preset | Speed | File size at matched CRF | When it’s the right call |
|---|---|---|---|
| ultrafast | Fastest | Much larger | Screen capture, proxies, “I need this file in 90 seconds” |
| superfast / veryfast | Very fast | Large | Live streaming on a weak CPU, rough review copies |
| faster / fast | Fast | Moderate | Quick client review exports |
| medium | Default | Baseline | The sane default; what most tools use when you pick nothing |
| slow / slower | slow ~40% slower than medium, slower ~2x | Smaller | Masters, archives, anything you’ll keep |
| veryslow | Much slower | Smallest practical | Overnight archival encodes where storage matters |
| placebo | Much slower than veryslow | ~1% smaller than veryslow | Never. The name is the documentation. |
The standard advice from the x264 world is “use the slowest preset you have patience for,” and it holds up. For most editors that patience runs out at slow or slower, which is fine, because that’s where the curve flattens: slow buys about 5 to 10% over medium, slower about another 5% on top of that, and veryslow only about 3% more. The steps below medium cost you far more in size than the steps above it save.
One x265-specific note: it also has --tune options, and --tune grain is worth knowing about if you’re archiving grainy film scans. Its job isn’t to keep the grain or to kill it, but to stop the blotchy, pulsing artifacts you get when default rate control distributes bits unevenly across a grainy frame.
CRF: the quality dial
CRF (Constant Rate Factor) is a number from 0 to 51 where lower means better quality and a bigger file. The x264 default is 23. CRF 18 is close to visually lossless for most content, and CRF 0 is mathematically lossless, which you will never need.
What makes CRF smart is that it targets perceived quality, not a bitrate. The encoder spends bits freely on the high-motion action scene and goes stingy on the locked-off interview shot, so quality stays constant while bitrate swings all over the place. The cost is that you can’t predict the file size before the encode finishes. For most work that trade is worth it.
Three numbers worth memorizing:
- ±6 CRF roughly halves or doubles the bitrate. CRF 17 produces a file about twice the size of CRF 23, which makes size math possible without test encodes.
- x265’s default is CRF 28, and it’s not a typo. HEVC compresses more efficiently, so x265 CRF 28 looks about like x264 CRF 23. Don’t carry your x264 numbers over unchanged or you’ll make files bigger than they need to be.
- HEVC’s design target is up to twice the data compression of H.264, so at matched quality x265 files land up to about 50% smaller, in exchange for a much slower encode. Real-world savings usually come in under that ceiling, but that trade is the reason HEVC exists.
CRF vs bitrate vs 2-pass
These are the three rate-control modes you’ll meet, and picking between them comes down to one question: do you care more about quality or about file size?
| Mode | What it locks | What floats | Passes | Use when |
|---|---|---|---|---|
| CRF / Constant Quality | Quality | File size | 1 | Almost everything: masters, archives, personal delivery |
| 2-pass VBR | Average bitrate / file size | Quality | 2 (~2x the time) | Hard size or bitrate ceiling: platform caps, broadcast slots, disc budgets |
| CBR | Bitrate, constantly | Quality | 1 | Live streaming, where the pipe can’t handle spikes |
“But isn’t 2-pass higher quality?” It’s the most persistent myth in encoding, so here’s the flat version: no. If you set a 2-pass encode to the average bitrate a CRF encode would have produced on the same footage, the quality converges. Two-pass isn’t a quality upgrade, it’s a size-prediction upgrade: pass one surveys the whole file, pass two distributes a fixed bit budget intelligently across it. HandBrake’s own documentation says the quiet part out loud: unless you need to hit a target file size, which they recommend against, use constant quality. You save the analysis pass and get the same picture.
If you do have a hard ceiling, 2-pass is the right tool, and predictable file sizes make storage planning easy. The video storage calculator has per-codec GB-per-hour numbers for exactly that job.
Hardware encoders: NVENC, Quick Sync, and AMF
Software encoders run on your CPU and can be tuned forever. Hardware encoders are dedicated silicon on your GPU (or iGPU) that do one thing at absurd speed. Each vendor invented its own preset naming, because of course they did.
| Encoder | Hardware | Presets (fastest → best) | Notes |
|---|---|---|---|
| NVENC | NVIDIA GPUs | P1 → P7 | Plus a separate “tuning info” mode; editors want High Quality |
| Quick Sync (QSV) | Intel iGPUs / Arc | veryfast → veryslow (named like x264) | Naming matches x264 but the internals don’t; numeric mappings vary by tool, so trust the names |
| AMF / VCE | AMD GPUs | speed, balanced, quality | AV1 adds a fourth tier, high_quality |
| VideoToolbox | Apple silicon | No exposed ladder | What every Mac NLE uses for hardware H.264/HEVC |
Two NVENC details worth knowing, because NVIDIA’s docs bury them. First, the P1 to P7 ladder is separate from the tuning-info modes (High Quality, Low Latency, Ultra-Low Latency, Lossless). Low Latency exists for game streaming and video calls; if you’re exporting a file or recording a VOD, you want High Quality tuning with a P6 or P7 preset, and OBS or your NLE usually picks sensibly for you. Second, NVENC does have 2-pass modes (a quarter-resolution fast pass or a full-resolution one), but they exist to hit bitrate targets more accurately, not to chase quality the way software 2-pass does.
For AMD, AMF’s own guidance splits by job: peak-constrained VBR for VOD and archive work, CBR for broadcast and conferencing where bitrate stability beats efficiency. Same logic as the software table above, different spelling.
So is hardware encoding worse?
Measurably, yes. Practically, almost never in a way you’ll see.
Puget Systems’ Premiere Pro hardware encoding benchmarks put both sides in hard numbers: hardware encoding averaged a 1.5 to 2x increase in export performance, up to about 5.5x in the best cases, while the quality difference was small enough that it showed up mainly as fine-detail loss on high-texture surfaces like road pavement, visible only when you go pixel-peeping in crops.
What settles it for most delivery work: YouTube, Instagram, and TikTok re-encode 100% of uploads. Your export never reaches a viewer; it’s raw material for the platform’s transcoder. Puget’s finding was that the already-small hardware quality difference becomes completely unnoticeable after that re-encode. Rendering 2x slower to protect detail the platform is about to compress away is not a quality decision, it’s a superstition.
So the split looks like this:
- Delivering to a platform that re-encodes: hardware, 1-pass, generous bitrate. Done. This is the exact recipe in our platform export settings reference.
- Masters and archives that will be watched or re-edited as-is: software x264 or x265, slow or slower preset, CRF 18 to 20 (or 2-pass if you have a size ceiling). No transcoder is coming to hide your encoder’s mistakes, so make fewer of them.
- Live streaming: hardware, close to mandatory, because the encode has to keep up with real time while your CPU does everything else. Use low-latency tuning only if the stream is truly live; a recording destined for VOD should stay on quality tuning.
One more software-wins case: if your timeline is heavy RED or other GPU-decoded footage, the GPU can end up decoding and encoding at once, and the hardware-encode speed advantage shrinks or inverts. When a hardware export is mysteriously slow, that contention is usually why.
Where these controls live in your NLE
Premiere, Resolve, and HandBrake each rename these controls, hide some of them, or drop them entirely, and the streaming-engineer guides never bother with the translation. So here it is.
Premiere Pro
Premiere exposes no CRF and no preset ladder. Its H.264/H.265 exports are bitrate-driven only: CBR, VBR 1-pass, or VBR 2-pass, with a target bitrate plus minimum and maximum limits. The encoder choice sits in the Performance dropdown in the Encoding Settings group, where Hardware Encoding means NVENC, Quick Sync, or VideoToolbox depending on your machine.
One behaviour is worth watching. Hardware Encoding is the default, but it is conditional: Adobe’s own settings reference says that if your system doesn’t support the export settings you’ve chosen, the Performance menu switches itself to Software Encoding. The dropdown does move, so the change is there to see, but nothing interrupts you to say which setting caused it. Check Performance last, right before you export, because on a long 2-pass master the gap between the two paths is measured in hours. The full walkthrough for that job is in how to correctly export a feature film from Premiere Pro.
DaVinci Resolve
On the Deliver page, Resolve gives you both philosophies under Quality. “Restrict to X Kb/s” is bitrate targeting. “Automatic” with the Least-to-Best quality options is quality targeting, Resolve’s cousin of CRF: you pick a quality level and the file size lands where it lands. When your system has a hardware encoder, an Encoder dropdown appears next to the codec so you can choose between it and the Native software path. Same rules apply as everywhere else: hardware for platform delivery, Native software for masters you care about.
HandBrake
HandBrake is the one GUI that hands you the whole toolbox with the real names on it. The Video tab has the encoder picker (x264, x265, and your hardware options), the full ultrafast-to-placebo preset slider, and a Constant Quality slider labeled RF, which for H.264/H.265 is CRF wearing a HandBrake badge. The Avg Bitrate option with its 2-pass checkbox is right below it.
HandBrake’s built-in presets translate to the ladder like so, taking the 1080p versions: Very Fast is RF 24, Fast is RF 22, HQ is RF 20, Super HQ is RF 18. Those numbers shift with resolution, and the ranges HandBrake documents are RF 18 to 22 for SD, 20 to 24 for 1080p, and 22 to 28 for 4K. If you want to learn this stuff by touching it, HandBrake is the free classroom.
The quick-reference table
| Job | Encoder | Preset | Rate control |
|---|---|---|---|
| YouTube / Reels / TikTok upload | Hardware (NVENC / QSV / AMF / VideoToolbox) | P6-P7 High Quality, or your NLE’s default | VBR 1-pass, generous bitrate |
| Client review copy | Hardware | Default | VBR 1-pass, moderate bitrate |
| Client master, watched as-is | Software x264 | slow | CRF 18-20, or 2-pass VBR to hit a spec |
| Archival copy, storage-constrained | Software x265 | slow / veryslow | CRF 20-24 (add –tune grain for film scans) |
| Broadcast / disc / hard size cap | Software x264/x265 | slow | 2-pass VBR at the mandated bitrate |
| Live stream | Hardware | Vendor quality preset your rig sustains | CBR |
| Proxies / dailies in a hurry | Either | ultrafast-veryfast | CRF 23-28 or low-bitrate VBR |
FAQ
Does the preset change quality or just speed?
At a fixed CRF: neither quality nor speed alone, it changes efficiency. Slower presets produce the same perceived quality in a smaller file, at the cost of encode time. At a fixed bitrate the story flips: slower presets do look better, because better compression buys more picture per bit. That’s why streaming guides obsess over presets (they live in fixed-bitrate world) while CRF users mostly shouldn’t.
What CRF should I use?
x264: 18 for a master you’ll keep, 20 to 23 for general delivery. x265: add about 5 to those numbers, so 23 and 26 to 28. If the result looks too soft, drop the number by 2 and re-run; each step of 6 doubles the file, so small moves are cheap.
Is hardware encoding lower quality than software?
At the same bitrate, slightly: the loss concentrates in fine texture detail you need magnified crops to spot, and in blind comparison it’s hard to call a winner without zooming well in. After a platform re-encodes your upload, the difference is gone entirely. Reserve software encoding for files that will be watched without another transcode in between.
Should I use 2-pass?
Only when something outside your control fixes the file size or bitrate: a broadcast spec, a disc, a platform cap. Otherwise use CRF; it reaches the same quality in half the encode time. In Premiere, check the Performance dropdown after you pick 2-pass: it falls back to Software Encoding on its own when your system can’t do what you asked.
Is the placebo preset ever worth it?
No. It buys at most about 1% more compression than veryslow, at a much higher encode time. The x264 developers named it placebo so nobody could say they weren’t warned.
Where to go from here
For the platform-by-platform numbers to plug into all of this, the export settings reference for YouTube, Instagram, and TikTok is the companion page. Long-form client and festival masters get the full treatment in the feature film export guide. And if your exports are slow because of the machine rather than the settings, the laptop guide covers which hardware encoders ship on which silicon.
Encoder behavior shifts with each SDK and app release, so this page gets re-checked when the tools move. If a dropdown in your NLE doesn’t match what’s described here, leave a comment and I’ll chase it down.
