Video Encoding Parameter Optimizer
Pick a resolution, framerate, content type, and CRF value. The engine estimates per-codec file size, bitrate, and encoding time — plus the compatibility matrix. The CRF reverse calculator tells you what CRF to use to hit a target file size. No other tool does this.
🎬 Encoding Parameters
Set resolution, framerate, CRF value, and content type. The engine models per-codec output across H.264, H.265, AV1, and VP9 using empirically-derived compression ratio curves. Tweak the CRF slider to see how quality trades against file size.
Content type determines spatial complexity and motion vectors — the two drivers of compression efficiency. Animation compresses 2–3× more than gaming footage at the same CRF.
CRF Explained: The One Parameter That Controls Everything
CRF (Constant Rate Factor) is the primary quality control in modern video encoders. It tells the encoder: "maintain this perceptual quality level, and spend as many or as few bits as each frame needs." Lower CRF = higher quality + larger file. Higher CRF = lower quality + smaller file. The default (23 for x264/x265) is the sweet spot — visually indistinguishable from the source for most viewers on most screens.
The key insight: CRF is not a bitrate target. A CRF 23 encode of a talking-head video might produce 2 Mbps. The same CRF 23 on a confetti-filled concert with strobe lights might produce 25 Mbps. That's the point — the encoder adapts. And because different codecs have different compression efficiency, the same CRF produces different file sizes across H.264, H.265, AV1, and VP9. This tool models those differences so you don't have to run four encode jobs to find out.
Codec Compression Efficiency: The Generation Gap
Each codec generation improves compression by roughly 30-50% at the same perceptual quality:
| Codec | Year | Relative Efficiency | Best For |
|---|---|---|---|
| H.264 (AVC) | 2003 | 1.0× (baseline) | Maximum compatibility. Every device made since 2008 plays this. Use when reach matters more than bandwidth. |
| VP9 | 2013 | ~1.3× better than H.264 | YouTube's default. Royalty-free. Good browser support. Weaker on Apple devices. |
| H.265 (HEVC) | 2013 | ~1.5× better than H.264 | The pragmatic upgrade. 50% smaller files than H.264 at same quality. Broad hardware decode support. Patent licensing is a mess — but for most teams, that's legal's problem. |
| AV1 | 2018 | ~1.8× better than H.264 | The future. Royalty-free. 30% better than HEVC. Encoding is 5-10× slower than H.264 — but for VOD content encoded once and watched millions of times, the bandwidth savings dominate. Netflix and YouTube are all-in. |
Efficiency ratios are approximate and content-dependent. Animation and low-motion content benefit more from modern codecs than high-motion, high-noise content. Our calculator models this through the content-type preset selector.
Content Type: Why Animation Compresses Better Than Gaming
Video compression works by predicting motion between frames and encoding only the difference. Flat-color animation with clean lines has minimal per-pixel variation — the encoder can describe an entire frame in very few bits. Gaming footage has film grain, particle effects, UI overlays, and rapid camera movement — the encoder works much harder. At the same CRF value, a 10-minute animation encode can be 2–3× smaller than a 10-minute gaming encode at the same resolution. This is not a codec bug. It's the fundamental information content of the signal. Our content-type presets model this difference so your bitrate estimate matches what you'll actually see in the encoder output.
When to Use Which Codec: The Decision Framework
The answer depends on two things: who your viewers are and whether the encode cost is paid once (VOD) or per-stream (live).
🎯 VOD, wide audience → H.264 + H.265 dual encode. H.264 covers 99.9% of devices. H.265 saves 50% bandwidth for capable clients. Storage cost of keeping two encodes is trivial compared to CDN egress savings at scale.
🎯 VOD, tech-forward audience → AV1 + H.264 fallback. AV1 hardware decode is now on 85%+ of devices. Encode once in AV1, keep an H.264 backup for Safari/Firefox on older hardware. If your CDN supports it, deliver AV1 preferentially via the <video> tag's source ordering.
🎯 Live streaming → H.264. Live encoding latency is dominated by the encoder speed. AV1 software encoding is 5-10× slower than H.264 — unacceptable for real-time. Hardware AV1 encoders exist (NVIDIA NVENC on RTX 40-series, Intel Arc) but are not yet ubiquitous in streaming infrastructure. H.264 is the safe choice for live. H.265 hardware encoders are more common and a reasonable upgrade if your ingest pipeline supports it.
🎯 Archival / master copy → AV1 or H.265 at CRF 14-18. You encode once and store forever. Use the most efficient codec you can. AV1 at CRF 14 is visually lossless and 40% smaller than H.264 at the same quality. Your S3 bill will thank you. See our cloud storage cost comparison to model the savings.
How We Model: The Math Behind the Estimates
This calculator does not run a real encoder — that would require uploading video to a server with FFmpeg and the user waiting minutes. Instead, it uses empirically-derived compression ratio models built from systematic encode benchmarks across the four codecs at multiple CRF values and content types. The model inputs:
- Base bitrate per resolution/framerate combination — the uncompressed data rate (resolution pixels × framerate × 3 bytes per pixel × 8 bits per byte)
- Codec compression ratio — a per-codec, per-CRF curve derived from encodes of standard test sequences (Big Buck Bunny, Tears of Steel, Netflix El Fuente, Twitch gaming clips)
- Content-type modifier — a multiplier on the compression ratio accounting for spatial complexity and motion. Animation: 1.6×. Live action: 1.0×. Screencast: 1.3×. Gaming: 0.7×.
- Encoding time multiplier — relative to H.264 at CRF 23 = 1.0×. H.265: ~2×. AV1: ~8× (software, libaom). VP9: ~5×. These are software encoding ratios — hardware encoders (NVENC, QSV, VideoToolbox) are much faster but produce larger files at the same CRF.
The reverse CRF calculator iterates the model: it starts at CRF 23, estimates the file size, compares to the target, and adjusts CRF up or down until it converges within 5% of the target — the same binary search a human would do manually across four encode jobs. All computation happens in-browser. No video is uploaded. No server-side encoding is performed.