Compressor is the fastest video compressor for Android. Period. Full stop. End of discussion. Compared to the top Play Store result for video compressor, Compressor is 117x faster (11 seconds vs 21 minutes). It's completely native, ad-free, no paywalls, no subscriptions, just an awesome free app, written completely in Kotlin and using native Media3 transformer pipelines for compression. It's got everything you'd want from a video compressor, presets, target size, etc, without any extra bloat.
Compressor
@joshatticus Congratulations with launch on the PH!
Huge congrats on the launch! Compressor looks like a thoughtfully built, truly fast native Android video compressor with the right balance of performance, privacy and no‑BS UX—perfect fit for the PH crowd.
Compressor
@zeiki_yu Thank you so much!
Congrats on shipping
Quick question, how are you thinking about building trust and reviews for new user after today?
At scale across Android devices, the hard part is MediaCodec fragmentation: weird aspect ratios, HDR tone mapping, and thermal throttling can turn “fast” into export failures or wildly inconsistent sizes.
Best practice is Media3 Transformer with capability checks + graceful fallback (software or OpenGL tone mapping where needed), plus a foreground export pipeline so long compressions do not get killed in the background.
How are you handling per-device codec failures and HDR inputs today, and do users get a deterministic “target size” mode that converges without multiple passes?
Compressor
@ryan_thill Thanks so much! I have gotten a few bug reports so far through GitHub, mainly about Huawei devices being problematic. Compressor already handles weird aspect ratios, but HDR is not implemented. Thermal throttling is also not a concern, unlike with other apps, unless your phone overheats when recording videos of the same resolution in the camera app :)
Capability checks are there specifically for supported codecs, but there is no fallback for software, as that would cause significantly slower processing. Instead, if the hardware encoder is not functioning correctly, the user is presented with an error explaining there's an issue with their device's hardware encoder.
As for the target size, I'm actually super proud of it! It uses the length of the video, original bitrate and target bitrate to determine the final size of the video, checking the bitrate of the entire video rather than the average to determine size. Furthermore, reasonable minimums are implemented to ensure for example that users don't see a 1MB estimate on a 5 minute long 4K60 video.
@joshatticus This is a super clean approach: failing fast with a clear hardware-encoder error beats silently falling back to 20x slower software and getting blamed for “it’s slow.” Huawei-specific quirks are so real.
The target-size logic sounds thoughtfully engineered, especially checking bitrate across the full video instead of trusting averages and enforcing sane minimums for edge cases like long 4K60 clips.
Are you planning any lightweight HDR path (even SDR tone-map) for modern devices, and will you surface a per-device compatibility list or telemetry to spot problematic encoder models faster?
vibecoder.date
Joined the beta test, the other link on the github is broken.
I left my review already but it's worth saying again.
This app is great and I wish it all the users. It works well, the UX is beautifully simple, and it doesn't get in the way
Compressor
@build_with_aj Thank you so much! May I ask which link is broken? I'll go fix it right now :D
vibecoder.date
@joshatticus https://apt.izzysoft.de/fdroid/index/apk/compress.joshattic.us
Was broken but seems fixed now
117x faster is a bold claim but looking at the native Media3 implementation, that tracks. The Android app ecosystem is filled with bloatware that exists purely as an ad delivery vehicle. Nice to see someone actually solve the problem instead of monetizing the frustration. One question: does it preserve any metadata (timestamps, location) or strip everything for privacy?
Compressor
@philip_sorensen Thanks! Metadata is not preserved as of now.