The source is a real 5:40 segment of Sintel ((C) Blender Foundation, durian.blender.org, CC BY 3.0), at its native DCI 4K resolution (4096x1744 (native 4K)) and a high bitrate (~45.4 Mbps), 1.96 GB, in the range of a real full-length 4K recording rather than a short excerpt. 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 129.6s, faster than the clip's own 5:40 runtime, on a file nearly 2 GB in size. Nothing left the Mac at any point: the file was read from disk, encoded locally, and written back to disk.
Same timestamp, both frames, extracted directly from the source and output files.
Target-size accuracy on a large 4K file
The same source, asked to fit 100 MB and a custom 150 MB target:
| Target | Actual | % of budget | Attempts | Time |
|---|---|---|---|---|
| 100 MB | 92.14 MB | 92.1% | 1 | 129.4s |
| 150 MB (custom) | 135.74 MB | 90.5% | 1 | 129.4s |
Both landed under budget cleanly. But 25 MB and 50 MB, the smaller presets, did not:
| Target | Actual | % of budget | Attempts | Time |
|---|---|---|---|---|
| 25 MB | 76.94 MB | 307.8% | 4 | 517.7s |
| 50 MB | 76.96 MB | 153.9% | 4 | 517.8s |
A 25 MB target on a 5:40, native-4K clip implies well under 1 Mbps for 4096x1744 video, far below what's realistic at that resolution: both attempts plateaued around 77 MB after the retry loop's full 4 attempts rather than reaching an unrealistic budget. This is the same real limitation documented on the target-size accuracy test, more pronounced here because this source is both longer and much higher-resolution. The lesson holds: target-size mode doesn't force a result that would require destroying the video, it reports what it actually achieved.
Quality observation: at native 4K, the gap between a realistic and an unrealistic target is larger than it is at 1080p or 720p, simply because 4K needs more bits to look right in the first place. The 100 MB and 150 MB results above hold up visually; a hypothetical 25 MB result at this resolution and length would not, which is exactly why QuickCompress didn't silently produce one.
- 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
- 4096x1744 (native 4K), 340.2 seconds (5:40), 1961.6 MB (1.96 GB)
- Source codecs
- H.264 video (~45.4 Mbps), AC3 audio (640 kbps)
A real 5:40 segment of a native-4K 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_large_clip.mp4 \
cargo test --test real_world_benchmark measures_the_smaller_strategy -- --ignored --nocaptureSource video: (C) Blender Foundation, durian.blender.org, CC BY 3.0 (https://durian.blender.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.
See the same test on more typical file sizes: a live-action clip and an animated clip.