How it works
What PostCrisp does to your video, and why.
Short-form apps re-encode every upload at a tight bitrate. You can't skip that encode, but you control what goes into it. PostCrisp runs one FFmpeg pass that removes what the app's encoder handles badly (noise, odd sizes, variable frame rate, HDR) and strengthens what it tends to lose (edges).
Step 01
Constant frame rate
fps=<nearest standard rate>, max 60
Phones record variable frame rate. Apps re-time VFR on ingest, which shows up as micro-stutter. Conforming to the nearest broadcast rate (29.97, 30, 59.94, 60...) keeps motion as recorded; 120 and 240 fps captures are brought down to 60.
Step 02
Resize to 1080×1920 ourselves
scale, Lanczos, fit inside, pad to 9:16
Anything that isn't 1080×1920 gets rescaled by the app with a fast, soft filter. Doing it here with Lanczos keeps edges, and a 1080p upload is eligible for the apps' 1080p playback tier. Non-vertical sources are letterboxed rather than cropped, so nothing is cut off.
Step 03
Predictable colour
BT.709, limited range; HDR tone-mapped with Hable
iPhone HDR (HLG/Dolby Vision) and HDR10 uploads are displayed inconsistently and often come out washed out. A controlled tone map to standard dynamic range looks the same everywhere. Untagged HD sources are read as BT.709, the way players read them, so colours don't shift.
Step 04
Light denoise
hqdn3d 1.5 / 1.5 / 3 / 3
Sensor noise is random detail an encoder must spend bits on. At the bitrates short-form apps use, it turns into crawling blocks. A light temporal denoise removes it before the app sees it. Stronger settings scored worse in our tests, because they start removing texture too.
Step 05
Small-radius sharpen
unsharp 3×3, luma 0.5, no chroma
The app's encode softens fine edges. A small luma-only unsharp mask pre-compensates. A 3×3 kernel at 0.5 beat the wider 5×5 at 0.6 in our tests: less halo, a smaller file, and a better VMAF NEG score after re-encoding.
Step 06
Capped H.264 High
libx264 slow, CRF 21, VBV max 6 Mbps (9 at 60 fps), 2 s GOP
All three apps accept H.264 High universally. CRF 21 keeps quality constant; the VBV cap stops noisy scenes from ballooning the file, because bits above what the app keeps are thrown away on ingest. For sources already below the cap, the ceiling follows the source (85% of its bitrate, with HEVC credited 1.4× for its efficiency), with a floor of 2 Mbps. Two-second keyframes match how short-form players seek and start.
Step 07
Clean container
AAC 192 kbps 48 kHz stereo, faststart, metadata stripped
48 kHz AAC is what the apps output, so there's no resample on their side. The MP4 index goes to the front so previews start instantly, and location and device tags are removed.
The benchmark
We score files the way the apps treat them: each candidate goes through a modelled platform re-encode (1080×1920, x264, CRF 23 capped at 2 Mbps), then gets compared with SSIM, PSNR and VMAF NEG, the version of VMAF that doesn't reward sharpening for its own sake.
- A 16 Mbps phone-style test clip came out 61% smaller (65% smaller than a naive CRF 18 re-encode).
- A 60 fps 10-bit HLG HEVC clip came out 78% smaller and tone-mapped to SDR.
- On real phone footage, the shipped settings scored 87.5 VMAF NEG after the modelled re-encode, against 86.6 for the same encode without cleanup and 86.5 for our first, stronger sharpen.
- An already-compressed 2 Mbps 720p clip came out 8.5% larger, because it is rebuilt at full 1080×1920. The result screen always shows the real change.
Sharpening costs a little on pixel-exact metrics (SSIM and PSNR measure closeness to the source, and a sharpened frame is by design not identical). We ship it because it wins on the perceptual score that matters after the app's compression, and we keep it mild for that reason.