Cryptograss:Video quality and storage
Video quality and storage records a measurement taken in September 2026, and a decision not to act on it.
Every release is published as four renditions, and hunter's disk reached 89% full. The obvious lever is the encoder's quality setting. This page measures what that lever is worth, so the answer is on record rather than re-argued from intuition later.
The short version: leave it alone. All published video comes to about 2 GB. The backup mirror on hunter is 53 GB. Degrading the masters to save a few hundred megabytes would be the wrong trade.
What was measured
The 1080p rendition — the largest of the four, and the one worth arguing about — encoded at CRF 32 (what ships today) through 40, on two real releases at opposite extremes:
- Busy: Red Haired Boy — Görlitzer Park, 28s, a park full of grass and leaves.
- Quiet: Victory Theme at a Nashville Airbnb, 29s, a still room.
| Setting | Busy clip | Quiet clip | XPSNR (busy) | Looks like |
|---|---|---|---|---|
| CRF 32 (current) | 42.4 MB | 3.5 MB | 38.65 | reference |
| CRF 34 | 37.3 MB (−12%) | 2.9 MB (−17%) | 38.01 | no visible difference |
| CRF 36 | 32.4 MB (−24%) | 2.3 MB (−34%) | 37.33 | no visible difference |
| CRF 38 | 27.9 MB (−34%) | 1.8 MB (−49%) | 36.71 | grass begins to soften |
| CRF 40 | 24.0 MB (−43%) | 1.5 MB (−58%) | 36.12 | visible smearing on foliage |
Quiet footage compresses far better than busy footage at the same setting — 58% saved against 43% at CRF 40 — because there is less real detail to keep. Encode time barely moves with CRF; that is the preset, not the quality target.
Why the answer is still "leave it"
| What | Size |
|---|---|
| Every published video, all renditions | ~2 GB |
| Backup mirror on hunter | 53 GB |
| Docker build cache (reclaimed by hand, September) | 14 GB |
| Unused Docker images | 25 GB |
A 24% saving on 2 GB is 500 MB. Retention on the backup mirror returns about 46 GB — ninety times as much, at no cost to anything anyone will ever watch.
The archive exists to be the durable copy. Spending picture quality to save half a gigabyte, while ten times that sits in build caches, would be solving the wrong problem with the only irreversible tool available.
When to revisit
- The published archive reaches tens of gigabytes — likely once several hour-long sets go up. At that point CRF 36 looks close to free.
- Someone reports buffering on the 1080p rendition. The fix there is bitrate, and this table says what it costs.
- A source turns out to be badly served by CRF 32 — very dark footage, heavy grain — in which case the setting should vary by content rather than globally.
One number worth keeping: 23 GB of source video has been uploaded to produce those ~2 GB of published renditions. The sources are deleted after publishing. If storage pressure ever does come from video, that ratio is the more interesting end of it.
Caveat on the method
delivery-kid deletes the camera original once a release is pinned, so these encodes were made from the published 1080p renditions rather than from phone files. Absolute sizes therefore run lower than a fresh upload would produce, and the quality scores compare against the published copy rather than the camera's.
The shape of the curve — what each step of CRF saves — is unaffected by that, and it is the part the decision rests on. Anyone wanting absolute numbers should re-run it against a camera original, kept aside before publishing.
See also
- Cryptograss:Video encoding pipeline — the four renditions and why AV1
- maybelle-config#131 — the disk that prompted the question
