[emmanueloga_]

Looks cool but raises a bunch of questions :-). Maybe you could add these to your FAQ, I imagine picky users like me may want the answers to at least some of these:

"up to 90% file size reduction"

What's an example of an input video or image that would see its size reduced by 90% without loosing quality? Also, how do you come up with this percentage? I imagine median/average size reduction must be way lower than 90% in real life. What if anything happens if size reduction fails?

The app doesn't seem to allow selection of codec (from the video I imagine "format" refers to the container, like say, mp4). Do you always encode using the same codec? Which one? Which ffmpeg settings do you use to ensure good compression? Does the app generate a log of the ffmpeg command used?

Can you trim videos without re-encoding them? ("lossless cut")

[j1elo]

For lossless cut, there's the LosslessCut [1] app, which even has an experimental but mostly working version of a "smart cut" feature [2] (aka. only re-encode the minimal mandatory amount of frames if you trim at a point between 2 key frames)

[1]: https://github.com/mifi/lossless-cut

[2]: https://github.com/mifi/lossless-cut/issues/126

[blopker]

The macOS integration on this app is impressive, but the technical compression bits are a combination of ffmpeg and off-the-shelf image compression libraries. The 90% number is a pretty typical (with lossy) image savings when taking a totally unoptimized jpeg out of a program like Photoshop. There's just a bunch of extra data that can be stripped out (EXIF for one), that doesn't affect how the image looks. For video, I have no idea. Handbrake can usually get me around 50% savings with the same resolution and frame rate.

ImageOptim is a good example of a nice UI on top of image compression libraries. Sadly, it hasn't been kept up to date. It's slower and compresses worse than what's possible now. It also doesn't support webp. For my own work, I made an open source clone[0] with the newest stuff in it. I use libcaesium, which is a Rust wrapper around all the compression libraries. Check out the source to see how easy it is.

[0]: https://github.com/blopker/alic

[redundantly]

EXIF metadata accounts for so little of the overall file size it isn't even worth mentioning...

[blopker]

Maybe, maybe not, but there are additional reasons to strip EXIF data. For example, many phones add location data to the images they produce. Posting those images unoptimized online can be a major privacy issue.

[danudey]

This depends on the size of your file. If you have dozens or hundreds of small sprite/UI images for an app or game, image metadata can add up quite a bit overall.

[voltaireodactyl]

Dude this is perfect. I’ve been looking for a modern image optim on and off for years. Thank you for putting in this effort, this will be a huge timesaver for me.

[hieu_dinh]

I usually share example of compression result on my Twitter (as the main marketing channel for now), some of the videos was compressed more than 90% of the size, by re-encoding with h264 codec. Thanks for the feedback, I will update the website to add some example videos and images. For trimming without re-encoding, it's not possible in the current version

[orev]

I’ve seen many videos produced by phones that are at least 10x larger than they need to be. I think they’re trying for some kind of cinematic quality, or maybe expect people to recompress them after the event (or in the worst case are conveniently choosing settings that use up more local and cloud storage so people need to pay to upgrade).

Other low cost video devices (like dashcams) can use higher bitrates and lower compression modes simply because they don’t have the CPU power to use the most optimal settings while also being able to record real-time streams.

You can save a lot of space by re-encoding these types of files on a real computer.