The source is the same 151.2 MB, 3840x2160 (4K), 15-second test clip used in the video compression benchmark. This time, instead of asking for "smaller", the target was an exact 25 MB, the same preset shown in the app.
QuickCompress landed at 22.7 MB, comfortably under the 25 MB limit, in a single encoding attempt, in 8.4 seconds. 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.
When a first attempt does land over the target, QuickCompress automatically retries with a corrected, lower bitrate rather than handing back an oversized file. On the same source, a deliberately tight, non-preset 12 MB target took 4 attempts and 33.6 seconds to land at 11.99 MB (99.9% of target), the retry loop converging on the tightest budget it was asked for. Two other common presets on the same source: a 50 MB target landed at 45.45 MB in one attempt (8.4s), and a 100 MB target landed at 90.81 MB in one attempt (8.5s).
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.
- 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 target_size_accuracy -- --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.