Show HN: CompressX, my FFmpeg wrapper for macOS (compressx.app)
For those who may not be familiar, FFmpeg is a powerful tool for converting, streaming, and recording audio and video content.
I started CompressX as a weekend project to serve my 9-5 jobs, primarily to compress demo videos for uploading to GitLab and sharing with my colleagues. It took me 2 weeks to make the first working version. I shared the demo on Twitter and the reaction was extraordinary. People loved it, they said that I was bringing the Pied Piper to life.
Four months later, I hit the $9,000 mark in revenue. I never expected to make a dime from this project, let alone eight thousand dollars. It's been a surreal experience, but it's also been incredibly rewarding.
I put a lot of time and effort into developing this tool, and it's amazing to see it paying off. It's been a great journey so far and I'm excited to see where it takes me next.
172 comments
[ 2.8 ms ] story [ 210 ms ] threadAdditionally, in terms of code and financial support?
I saw this go viral on Twitter and commenters had no clue ffmpeg was a thing and thought he built this from scratch.
You can still charge for it just as you do now, but it will also give your users the essential freedoms they deserve.
You wouldn't be able to build this tool so easily without the commons of the open source projects you're building upon, and so it seems fair for you to also contribute back to the same commons.
Certainly would be prudent to check out https://ffmpeg.org/legal.html
By selling software built on the backs of free developers, you're effectively profiting off of a significant amount of their work.
I hope you donate a nice chunk of money to ffmpeg. https://ffmpeg.org/donations.html
Is the ecosystem part of this? Is it that the application demographic leans towards MacOS? Is the dev and monetization experience better? I'm really curious if anyone know why I see so much good native indie software for MacOS specifically.
In fact as an almost 100% full time Mac user the only things I've actually bought that run on the Mac are PixelMator and Goodnotes and I paid virtually nothing for either of those.
$1600 a year for dialog boxes where edit keys don't work in the text boxes properly.
A long time ago, CAD software fit the same hole of dire eye poking life sucking hell machine.
On Windows and Linux one minute you're constantly poked in the eye by fucked up scaling issues, different toolkit weirdness and quirks, various layers of abandoned shit going back 25 years and people with the design ability of a three legged goat with cataracts. It is fatiguing.
in fact electron seems like the perfect use case here for a ffmpeg UI wrapper. surprised no one has done it.
It also looks shit on every platform then.
And eats all your RAM
Disclaimer: I work at Microsoft, but not in Developer Division.
Didn't VIM and Emacs have that for ages? Look at https://vimawesome.com/. I think the remote development extension is nice, but most people would just SSH and run their editor on the server or sync their project's files.
Why would anyone want something taking up literally 1000x the resources it needs to?
No, there is not but there is consistency between platforms of the same electron app. Something that's much harder to do if you write a native app.
And for professionals, I don't even wager this consideration takes place at all. I don't see anyone protesting Ableton Live or Pro Tools because their developers didn't use the native MacOS button widget.
And generally speaking, yeah, people are happy to use Microsoft Office. The Mac version is nearly identical to the other versions. The "branding" is ignored or even applauded, because it enhances the overall consistency of the app. You might even be able to argue that Office on Mac only feels native because it goes out of it's way to not look Mac-native.
Regardless though, for non-Microsoft-sized companies it's not really realistic to ship, test and maintain multiple versions of the same app. It's much easier to pick one cross-platform framework and commit to it whole-heartedly, which is why we really only see native apps for single-platform or Microsoft-scale apps.
The same is true for desktop applications. No macOS user wants their application to look like a Windows application and no Windows user wants Mac controls.
Apple itself isn't consistent enough anymore for it to matter / there to be one true way. Pick a design system and roll with it, definitely - but slavishly trying to figure out the One True Way on a particular platform A) isn't likely to work out, even just focusing on design B) is a long-term handicap. Most people have a mix of devices in their life.
A soothing thought if that's hard to process: Jony Ive always had something to say about how the hardware becomes the app, especially post-iPhone. People expect the app to be familiar across platforms. (of course, there's all sorts of nerd-sniping caveats from there. Of _course_ you should use the platform's print dialog, etc. But don't get hung up on ex. what the Apple Reminders app looks like this year on iOS and OS X)
Most of the time it's people who only know javascript and have never even heard of GUI libraries that say this.
Clearly not. The least effort is to use the platform’s native widgets, or at least a decent toolkit. Those shiny web-based interfaces suck because the developer never put the effort to make the widgets behave as they should, and that’s because it’s actually very hard and expensive to build a UI framework from the ground up. Have a look at UITextField or NSTextField and what they do out of the box for free, for every single application. Nobody is going to implement half of that in their fancy text boxes. The only reason it takes less effort is that everybody half-arses it.
The consequence is that most Electron apps are a dog’s breakfast and the polar opposite of consistent and well made.
[1]: https://github.com/mifi/lossless-cut
I can whip up a decent looking AppKit UI for a moderately complex desktop app that can handle the rigors of accessibility settings and internationalization in an afternoon without importing a single third party dependency. That’s hard to beat for indie dev projects.
This is why I think that anybody looking to create a new platform with a similar culture of quality indie apps should put building an capable, pleasant native UI toolkit at the top of their list of priorities. UI toolkits are the lifeblood of platforms.
Polish and ease of use are important to me when using software. Don't get me wrong, I spent a ton of time in the terminal and using less than pretty tools but when possible I like nice tools that do a task well.
Then again if all you see is a "simplistic ffmpeg frontend" then I don't know if I can make you understand the value in accepting less overall functionality in favor of a tool optimized for your specific workflow. And some people, not saying you, take a pride in using the lowest-level, most featureful, more obscure tool. They wear it as a badge of pride and chide anything else as a "toy" or "simplistic". I find this mindset absurd. I all for going to the lower level when needed but people that have this attitude best be writing assembly by hand or they are just cosplaying being "smarter". There is always a lower level, just because someone goes to an arbitrarily lower level doesn't make them "better" but that's the feeling I often get from people like this. Reminds of the "Four Yorkshiremen" sketch: https://www.youtube.com/watch?v=ue7wM0QC5LE
I myself have this conflict to built something cross platform but then you don’t get well polished out of the box.
What do you folks think about this?
Any success with non macOS non tech savvy users buying your software as much as macOS users?
Probably a bit of hyperbole to put this into a category of "best looking software"
And some developers are either pretty good UI designers too (it happens) or at the very least they have good taste for design. If you’re one of those people, it’s hard not to gravitate towards the Mac.
That and Apple care a lot about design too so as others have said, the platform is kind of setup for guiding you (mostly) towards making good decisions in that area.
Great looking app too.
Could you please share the marketing side? I'd love to start a side project as well but I have exactly zero ideas on how to get initial traction.
Do you work for microsoft?
Do you work at Oracle?
Do you work for local government?
Very true, but just want to note that ChatGPT is also great at creating CLI input for ffmpeg, yt-dlp, etc. And of course, Handbrake remains the O.G. for open source, cross-platform video encoding.
If you're not trying to pick a fight, the more sensical reading of this is "where the value [of this tool] lies".
I tend to include the codec developers in the "ffmpeg developers" for simplicity as there are many that work in both areas.
The complexity in using those codecs isn't the ffmpeg command line, it's knowing which options to use.
"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")
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
[1]: https://github.com/mifi/lossless-cut
[2]: https://github.com/mifi/lossless-cut/issues/126
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.
And the types of users who are going to be using something like an ffmpeg wrapper are the types who are gonna care about something like that.
It's not SaaS anyway, so why would I care about your current to-the-hour success metrics? Might as well just slap your amount of sales up there, it's less intrusive at least. Put some user testimonials, anything other than telemetry data.
The website: Remove the pop-up & Update privacy & ToS to mention exact what data is tracked and how to opt-in/out from anonymous telemetry
The app: Add the option to opt-in/out anonymous telemetry
Thanks for the feedback
Similar to Windows forcing users to update because most of them keep putting it off forever, hurting their own security.
I would recommend removing this because it's against the GDPR... and even foreign companies have to comply (for the protection of European citizens, wherever they are) if they offer goods and/ or services to citizens in the EU in some way (European region of an app store, ad campaigns in Europe, etc.) I also think that the GDPR is pretty correct in requiring opt-in consent before tracking, so it's "the decent thing".