Video Compression, by the Numbers
By Mark Fulton · 2026-08-09 · 2 min read
Every question about video file size has the same one-line answer: size = bitrate × duration. Everything a compressor does is an attempt to lower the bitrate without you noticing. Once you hold that equation, all the settings stop being mysterious.
The arithmetic
Bitrate is measured in megabits per second; 8 megabits = 1 megabyte. So:
| Source | Typical bitrate | One minute weighs |
|---|---|---|
| Phone 4K/60 recording | ~50–100 Mbps | 375–750 MB |
| Phone 1080p recording | ~15–25 Mbps | ~110–190 MB |
| YouTube-recommended 1080p upload | ~8 Mbps | ~60 MB |
| Decent 1080p H.264 encode | 3–5 Mbps | ~22–38 MB |
| Watchable 720p H.264 | 1.5–3 Mbps | ~11–22 MB |
(The upload figure is from YouTube's own recommended settings.) Notice the 10–20× gap between what a phone records and what looks fine on a screen: cameras spend bits generously because re-encoding later can only remove information, never add it. That gap is why compressing phone footage often shrinks it 50–80% with no visible change.
What CRF means
Modern encoders like x264 offer Constant Rate Factor (CRF) mode: instead of targeting a bitrate, you target a quality level, and the encoder spends whatever bits each scene needs. Per the FFmpeg H.264 encoding guide, CRF runs 0–51, lower is better quality, and a change of ±6 roughly halves or doubles file size. The useful range:
- CRF 18–23 — visually transparent to near-transparent. Archival and "this video matters."
- CRF 26–28 — small, still good. The sweet spot for sharing.
- CRF 30+ — visibly compressed, smallest files. Fine for screen recordings and drafts.
VidClip's compressor maps its three targets onto exactly this scale (23 / 28 / 32), which is why the output sizes vary by content: CRF spends bits on motion and detail, so a talking head shrinks far more than gameplay.
Two levers people forget
Resolution is quadratic. Halving both dimensions quarters the pixels — resizing 4K to 1080p typically cuts size ~60–75% before quality settings even apply. If the destination is a phone screen, downscale first, then compress.
Duration is linear and free. Trimming dead seconds off the start and end is compression with zero quality cost. Trim, then compress, in that order.
Sources
- FFmpeg project, H.264 encoding guide (CRF)
- YouTube Help, Recommended upload encoding settings