Short answer: run ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset medium -c:a aac output.mp4. In my tests on a 20-second 1080p clip, that one command shrank the file by 78% — from 29.6 MB to 6.6 MB — with an SSIM quality score of 0.988 out of 1.0, and extracted frames were visually identical to the original. If you need it even smaller for WhatsApp or email, add a 720p downscale and you get 94% smaller. Here's the full test, the exact commands, and the one counterintuitive thing I learned about quality settings.
The One Concept: CRF
Video encoders like H.264 don't have a simple "quality: high/medium/low" switch. They have CRF — Constant Rate Factor — a number from 0 (lossless) to 51 (worst) that targets a constant perceived quality and lets the file size fall where it may. Lower CRF = better quality, bigger file. Higher CRF = smaller file, more compression artifacts.
FFmpeg's default is CRF 23. I tested whether pushing higher actually costs anything visible — and threw in newer codecs for comparison.
How I Tested
I generated a 20-second 1080p/30fps test clip with FFmpeg's testsrc2 pattern plus brown noise — lots of motion and fine detail, deliberately hard to compress. I encoded it once at near-lossless quality (H.264 CRF 14, 29.6 MB) as my "original," then re-compressed that master six ways:
- H.264 CRF 23 — the common default
- H.264 CRF 28 — the aggressive setting
- H.264 CRF 28 at 720p — the messaging-app trick
- H.265 CRF 28 — the newer codec, same number
- VP9 CRF 32 — YouTube's codec
- AV1 CRF 32 — the newest open codec (SVT-AV1)
For each, I recorded the file size, the encode time on a 2-vCPU Linux machine, and two objective quality metrics against the master: SSIM (structural similarity, 1.0 = identical) and PSNR (higher = closer to the original). I also extracted matching frames from the master and the CRF 28 output and compared them by eye.
Test environment: FFmpeg 8.1.2 on Ubuntu 24.04, 2026-10-24. Scores are measured against my CRF-14 master, so treat them as relative comparisons between settings.
The Results
| Setting | File size | Smaller by | SSIM | PSNR | Encode time |
|---|---|---|---|---|---|
| Original (H.264 CRF 14) | 29.6 MB | — | — | — | — |
| H.264 CRF 23 | 14.1 MB | 52% | 0.9954 | 44.8 | 59 s |
| H.264 CRF 28 | 6.6 MB | 78% | 0.9880 | 40.6 | 52 s |
| H.265 CRF 28 | 11.0 MB | 63% | 0.9925 | 42.2 | 137 s |
| VP9 CRF 32 | 16.1 MB | 46% | 0.9972 | 46.9 | 537 s |
| AV1 CRF 32 | 14.9 MB | 50% | 0.9963 | 46.0 | 190 s |
| H.264 CRF 28, 720p | 1.8 MB | 94% | 0.9657* | 34.8* | 46 s |
*720p scores measured after upscaling back to 1080p, simulating fullscreen viewing.
Three things stand out:
1. H.264 CRF 28 is the sweet spot. 78% smaller than the master, SSIM 0.988, and the extracted frames were indistinguishable from the original at normal viewing. The default CRF 23 is fine, but you're paying double the file size for quality you'd need a magnifying glass to notice.
2. CRF numbers are not comparable between codecs — this surprised me. H.265 at CRF 28 produced a bigger file (11.0 MB) than H.264 at CRF 28 (6.6 MB), because x265's CRF 28 targets higher quality (SSIM 0.9925 vs 0.9880). Same story with VP9 and AV1 at CRF 32: near-perfect scores (0.9972 and 0.9963) but files larger than plain H.264 CRF 28. "Just use a newer codec" is not automatically a win — you'd need to tune each codec's CRF separately to match quality, and that's a whole separate test.
3. VP9 single-pass encoding is brutally slow on modest hardware. Nine minutes to compress 20 seconds of video on 2 CPU cores. AV1 (via SVT-AV1) was faster at ~3 minutes but still 3–4x slower than H.264. For a quick shrink before sending a video, H.264 wins on practicality alone — and it plays on every phone, TV, and browser without a second thought.
The 720p trick is the nuclear option: 94% smaller, perfectly fine on a phone screen, but measurably softer (SSIM 0.9657) if you watch it fullscreen on a monitor.
The Exact Commands
Install FFmpeg first (sudo apt install ffmpeg on Ubuntu/Debian; ffmpeg.org for other systems). Then:
The everyday shrink (my recommendation):
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset medium -c:a aac output.mp4
Maximum shrink for messaging apps:
ffmpeg -i input.mp4 -vf scale=1280:720 -c:v libx264 -crf 28 -preset medium -c:a aac output_small.mp4
Keep the audio untouched (if you don't want it re-encoded):
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset medium -c:a copy output.mp4
Two notes on the flags: -preset medium balances speed and compression — veryfast encodes quicker but makes slightly larger files, slow squeezes a bit more at the cost of time. And if CRF 28 ever looks soft on your footage (very grainy or noisy video suffers first), step down to CRF 25 or 23 rather than changing anything else. Quality problems? Lower the CRF number. File still too big? Raise it. That's the whole game — HandBrake's quality guide explains the CRF scale well if you want the deeper version.
Which Setting Should You Use?
- Sending a video on WhatsApp/Telegram/email: H.264 CRF 28 at 720p. Tiny file, looks great on a phone.
- Archiving footage you might re-edit later: H.264 CRF 23 (or even 20). Storage is cheap; re-compressing an already-compressed file degrades it, so keep archives at higher quality.
- Uploading to YouTube: H.264 CRF 20–23 at original resolution. YouTube re-compresses everything you upload, so give it the best source you reasonably can.
- Just making a big file smaller, fast: H.264 CRF 28. One command, under a minute for a short clip, no visible loss.
One rule that matters more than any setting: never compress an already-compressed file twice. Every lossy encode throws away detail permanently. Always compress from the highest-quality copy you have.
FAQ
Does compressing a video always reduce quality? Technically yes — lossy compression discards information by definition. Practically, no: at CRF 28 my test scored SSIM 0.988/1.0 and frames were visually identical to the master. "Lossless to your eyes" is the real target, and it's easy to hit.
Why not just use H.265 or AV1? They're newer. They're more efficient at matched quality, but their CRF scales don't line up with H.264's — my H.265 CRF 28 file was bigger than H.264 CRF 28. They also encode much slower on a CPU and H.265 has murkier playback support on older devices. H.264 remains the safe universal choice; reach for the newer codecs only if you've tuned them for your footage.
Will this work on phone videos? Yes. Phone recordings are H.264 (or H.265) in an MP4/MOV container — the same command works. Copy the file to a computer, or use an FFmpeg app on the phone itself.
How much smaller will my video get? It depends on the footage: static talking-head video compresses far more than shaky action. My 78% came from a deliberately hard-to-compress clip, so real footage often does better. Try CRF 28 on one file and judge for yourself.
Conclusion
For shrinking a video without visible quality loss, plain H.264 at CRF 28 is still the answer in 2026: 78% smaller in my test, SSIM 0.988, fast to encode, plays everywhere. The newer codecs scored slightly better but produced larger files and took far longer — a bigger CRF number on a newer codec is not the same thing.
How this article was made
Test clip generated 2026-10-24 with ffmpeg -f lavfi -i "testsrc2=size=1920x1080:rate=30:duration=20" plus brown-noise audio; master encoded with libx264 CRF 14, preset veryfast (29,618,966 bytes). All six test encodes ran on the same Ubuntu 24.04 machine (2 vCPUs) with FFmpeg 8.1.2: libx264 medium preset, libx265 medium preset, libvpx-vp9 single-pass (-b:v 0 -crf 32), and SVT-AV1 v1.7.0 preset 8. SSIM/PSNR computed with FFmpeg's ssim/psnr filters against the master; the 720p result was upscaled to 1080p with lanczos before scoring. Frames at t=10s were extracted as PNGs and compared visually. Both external links were checked to return HTTP 200 on 2026-10-24. This article was drafted with AI assistance; every number, timing, and command result comes from the author's own test runs on that date.