This is the same result shown on the QuickCompress homepage, with the full test context. The source is 15 seconds of 3840x2160 (4K) H.264 footage at roughly 80 Mbps, a bitrate comparable to real 4K30 camera footage. QuickCompress's Smaller mode compressed it locally on a MacBook Pro (Apple M1 Pro), using Apple's VideoToolbox hardware encoder.
The whole run, probing the source, planning a bitrate, and encoding, took 8.5 seconds. Nothing left the Mac at any point: the file was read from disk, encoded locally, and written back to disk.
Quality observation: Smaller mode targets a bitrate derived from the source's own resolution and frame rate, not a fixed compression ratio, so it aims to keep quality close to the original rather than always hitting the same percentage. A source already encoded efficiently for its resolution may see little size reduction: QuickCompress will tell you that upfront rather than compress it anyway.
- Environment
- MacBook Pro (Apple M1 Pro), macOS 26.5.2
- QuickCompress
- Pre-release build (v1.0.0, unreleased)
- Encoder
- Apple's VideoToolbox hardware encoder
- Source
- 3840x2160 (4K), 15.0 seconds, 151.2 MB
- Source codecs
- H.264 video (~80.5 Mbps), AAC audio (~129 kbps)
Synthetic 4K test clip with real motion complexity, not a customer video. It runs the real production probing and planning code, then the exact bundled FFmpeg sidecar QuickCompress ships, so the result reflects the app itself, not a simulation of it. Every number on this page comes from a test you can run yourself:
cargo test --test benchmark -- --ignored --nocaptureResults vary by source video: motion, resolution, starting bitrate, and Mac model all affect how much a specific file shrinks and how long it takes. Treat this as one measured data point, not a universal claim.
Curious what happens when you need an exact file size instead of just "smaller"? See the 25 MB target size test.