The source is a real 2-minute segment of Big Buck Bunny ((C) 2008, Blender Foundation, www.bigbuckbunny.org, CC BY 3.0), the same source used in the animated video compression test. Instead of asking for "smaller", each run set an exact target, the same presets shown in the app.
QuickCompress landed at 22.84 MB, comfortably under the 25 MB limit, in a single encoding attempt, in 14.7s. The target-size mode deliberately budgets a little under the requested limit rather than encoding as close to it as possible: overshooting the target by even a few kilobytes would defeat the point of asking for a fit-under-a-size result in the first place.
| Target | Actual | % of budget | Attempts | Time |
|---|---|---|---|---|
| 25 MB | 22.84 MB | 91.4% | 1 | 14.7s |
| 50 MB | 45.40 MB | 90.8% | 1 | 14.8s |
| 100 MB | 89.80 MB | 89.8% | 1 | 14.9s |
| 12 MB (custom) | 11.47 MB | 95.6% | 1 | 14.7s |
Every preset landed under target in a single attempt, including the non-round 12 MB custom target: the retry loop only has to do real work when a first attempt overshoots.
Quality observation: a tighter target size means a lower video bitrate for the same resolution and duration, which can visibly reduce quality on complex, high-motion footage. QuickCompress warns in the app when a requested target implies a bitrate well below what it considers acceptable for the source's resolution, rather than silently producing a degraded result.
A second, real source: where target-size gets harder
The same four targets, run against a real 5-minute segment of Tears of Steel ((C) Blender Foundation, mango.blender.org, CC BY 3.0, see the live-action video compression test):
| Target | Actual | % of budget | Attempts | Time |
|---|---|---|---|---|
| 25 MB | 23.59 MB | 94.4% | 1 | 15.9s |
| 50 MB | 45.56 MB | 91.1% | 1 | 15.9s |
| 100 MB | 90.88 MB | 90.9% | 1 | 15.8s |
| 30 MB (custom) | 27.43 MB | 91.4% | 1 | 15.7s |
Also 25/50/100 MB and a 30 MB custom target, all achieved cleanly. But two additional, deliberately tighter custom targets against this same source, 20 MB and 12 MB, did not land under budget, even after the retry loop's full 4 attempts (20 MB landed at 20.20 MB, 101.0% of target; 12 MB landed at 19.68 MB, 164.0% of target). A 12 MB target on a 5-minute clip implies roughly a 320 kbps total bitrate budget, below what this source could be pushed to while still producing a valid encode. Target-size mode doesn't always hit an arbitrary number: very tight budgets on longer or higher-detail sources have a real floor.
- 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
- 1920x1080, 120.0 seconds (2:00), 109.2 MB
- Source codecs
- H.264 video (~6.8 Mbps), AAC audio (440 kbps)
A real 2-minute segment of an animated short film. 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:
QC_REAL_SOURCE=fixtures/real-benchmarks/real_animation_clip.mp4 \
cargo test --test real_world_benchmark measures_target_size_accuracy -- --ignored --nocaptureSource video: (C) 2008, Blender Foundation, www.bigbuckbunny.org, CC BY 3.0 (https://www.bigbuckbunny.org/)
Results 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.