Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: CompressX, my FFmpeg wrapper for macOS (compressx.app)
170 points by hieu_dinh 9 months ago | hide | past | favorite | 166 comments
Hey HN, just wanted to share my success story with CompressX, my FFmpeg wrapper for macOS.

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.




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")


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


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


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


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.


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.


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.


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


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.


I swear the best looking software like this is all built for MacOS. Maybe there's a lot of it on Windows as well, but I don't see a ton of it on HN (maybe just the demo?).

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.


It's because the user interface is actually consistent and normalised across the whole platform and the paradigms are well documented and understood by the developers producing software.

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.


This is a brilliant summary. I mean… less of the goat bashing… but otherwise you summed it up pretty nicely.


but anyone can create an electron app these days with total control over the UI polish with way less effort.

in fact electron seems like the perfect use case here for a ffmpeg UI wrapper. surprised no one has done it.


> UI polish with way less effort.

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.


The least effort would be to use Qt. It's way easier to use than the native toolkit(s), and already looks native on every platform.


In my experience, producing a polished Electron/web app takes substantially more effort than it does to produce an AppKit/UIKit equivalent. Those don’t get you multiplatform, but that’s why a lot of devs who care about these things only publish for macOS and iOS.


Going the Electron route is the first and strongest signal that the developer doesn't care about the tid bits that makes a great app. Have never saw a good designed Electron app.


Not that it really matters I guess, but electron apps are chunky. Huge bin size and large memory usage.


were talking about a tiny desktop app that wraps ffmpeg CLI. this is the perfect use case for it, over, say, VISUAL STUDIO CODE.


I actually think VSCode is one of the best use cases for Electron. It enables a robust and well-documented set of APIs for extension and theme developers, which IMO is why it has one of the most thriving extension ecosystems out there.

Disclaimer: I work at Microsoft, but not in Developer Division.


> It enables a robust and well-documented set of APIs for extension and theme developers

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.


The Emacs APIs aren't exactly robust in the modern sense. They don't have the security and privilege isolation that VS Code's TypeScript APIs have.


The perfect use case for a massive incredibly complex browser runtime is...a tiny desktop app? What?


Do you as a user seriously want a 400MB binary that takes up 1 GB of memory at least just to have a sluggish interface to run a command line program for you when it could be an instant GUI that takes up 1 MB of memory ?

Why would anyone want something taking up literally 1000x the resources it needs to?


People rage about Electron being insecure and bloated, but by Jove it’s a godsend for consistency and portability.


Electron and consistency?? I get Electron being easier to develop for, but it achieves portability by ignoring platform native UI guidelines. There is no consistency at all between electron apps.


Hey, maybe I want to learn two dozen different slightly incompatible UI paradigms! If I don't have constant impedance mismatches I might get lazy and be able to operate my computer with continuous partial attention and actually focus on the task at hand! Shit, just imagine the horror if two different applications could grab keyboard focus correctly without clicking some input field. My fingers might never leave the keyboard!


I grew up with this mindset on macOS/iOS, and went with it for many years.

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)


Consistency >for portability


> There is no consistency at all between electron apps.

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.


The reality is that for most people, they use an app on a sibgle platform (typical end users don’t constantly switch between Windows, Linux, and macOS) so that consistency does not primarily benefit the end-user.


Exactly. The consistency being extolled here is not from the perspective of the users but of the marketing department that wants to warp basic UI conventions in service of making their branding a more pervasive part of the user experience. Users basically never want you to give them an app where even the buttons and scroll bars are changed to comply with your corporate style guide.


I remember raging with our designers over this, when building a mobile app. They were insisting on controls that look and feel exactly the same on iOS and Android because of some vague need to have consistent marketing/branding. Which ultimately meant custom controls (sometimes 10x development effort) that were not familiar to users on either platform. No user wants this. It's desired entirely by companies whose design department is too focused on their own designs.

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.


On the other hand, if Google Docs had system-native controls for every useragent that could connect to it, nobody would have any clue how to do anything and search for a new online document editor. It's not the overwhelming love for Material design that makes Google Docs look non-native, it's the experiential consistency for enterprise customers and less computer-obsessed end-users. If that amounts to sacrificing usability for branding, then Apple is just as guilty. Design is just part of building a product, and prioritizing your specific OS is not a realistic expectation from cross-platform products.

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.


People are more than happy to use Microsoft Office…?


I couldn't think of a more branding-heavy native app. It's got the ribbon interface of Windows ported to MacOS, the rowed toolbox with different button sizes, the status-bar on the bottom, it's still basically a Windows app with MacOS widgets.

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.


What is Google if not a Microsoft-scale company


What is Google Docs if not a perfectly acceptable Microsoft Word replacement?


The acceptable replacements would be Libre/Open Office, then Pages. The latter has more feature than Google Docs. Where Google Docs shines is when you need collaboration and basic Word processing features.


I see people say this sometimes but I never see anyone who has used a regular GUI library like FLTK or Qt say this.

Most of the time it's people who only know javascript and have never even heard of GUI libraries that say this.


There is LosslessCut[1], though it's only designed to handle trimming and not general re-encoding.

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


if you re-encoded then it wouldn't be lossless anymore?


Electron serves the developer not the user.

It also looks shit on every platform then.

And eats all your RAM


The complaint that Chrome eats all your RAM is because it starts a new process for each tab, with all the overhead that entails. You’re not using multiple tabs in an Electron app.


No instead I run 50 standalone browsers with one tab each on my machine ...


The overheard prevents any one tab from taking out the entire browser though.


Chrome has good reason to use multiple processes, but criticism of Chrome doesn’t necessarily apply to Electron apps.


That’s not the complaint lol


A lot of it is the frameworks available in Apple platforms. AppKit and UIKit are both wide and deep, providing just about everything needed to build polished apps while also providing well-supported “happy paths” for most tasks.

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.


Also, a beautiful, polished UI is "table stakes" for Apple users. They'll walk away if the application does not look and feel polished. Windows, Linux, Android, and so on users aren't as picky and tolerate less finished/consistent designs.


The two kind of feed into each other. The UI framework is conducive to polished UI, which results in more polished apps, which raises the bar of expectations for users. This then pressures developers to deliver more polished apps.

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.


My gut here is folks who buy apple products are far more likely to be willing to spend money on an app, and tend to care about design / polish.


I have spent a lot more money on shitty ugly software on Windows than I have on macOS.

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.


What did you buy for windows? If you’re using the Mac full time, sounds like you don’t need this software on it?


Minitab was the worst. I learned R because I hated paying for it, using it and using Windows.

$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.


In terms of UI/UX, I believe Apple provides the best development toolkit and guidelines for developers. I'm not using any custom UI component for CompressX, it's just a few buttons, toggles and a video player, but the overall UI looks good enough and consistent with other applications in the macOS


It is a single screen with about 5 input boxes and a drag and drop interface.

Probably a bit of hyperbole to put this into a category of "best looking software"


Yeah but if you look at a lot of single-screen apps with about 5 input boxes developed for Windows/Linux, they've got a face only a FOSS fanatic could love.


Apple users are probably the only crowd that would pay money for a simplistic ffmpeg frontend.


Maybe? But I'll pick paid with a nice UI over ugly/cli-only almost every time if it's something I'll use regularly. I'm not the target market for this specific tool but I pay for a number of tools that I can technically do on my own because I like looking at nice things. Sue me. I get joy from well designed and clean UIs. I can always use more joy in my life.

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


Yeah. From the first glance I see a lot of missing details being glossed over. Like what encoder is being used? Output format "mp4" is a container format, so is webm. Knowing the codec is important to decide whether the file is appropriate for where I want to play it. What if my TV doesn't have HEVC support and you are using it inadvertently? Also, what does each quality setting mean? Or the tradeoff between CPU usage and efficiency? Asking ChatGPT to come up with an ffmpeg command has none of these problems as all the details are exposed to you.


These questions make sense to someone technically inclined, but something like the linked app which makes reasonable assumptions (e.g. assuming the user wants the format that is most widely hardware accelerated) is probably a better fit for your average user.


What does it matter? He made $9,000 off of free labor and you didn't.


Another notion among developers as well is macOS users more likely to pay for software.

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?


I would guess that most people who care about aesthetics don't use Windows. So the only alternative is Mac, and it's the people that care about aesthetics who are the ones that are going to create & buy good looking software.


I think it’s partly down to the Mac’s long history of being favoured by creative types… especially designers.

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.


Linux apps following Gnome HIG look awesome as well.


How does your site know that “22 files compressed in the past hour”? Does the app collect this type of metrics from Desktop users, or is there some web-based function that’s being observed?


The app connects to telemetrydeck.com. Sadly, couldn't find any opt-out setting.


I'd really urge the author to rethink doing something like this at all. The app looks great but those stats on the front page were an immediate turn-off for me (not to mention how it pops up in what looks like an annoying cookie banner). You can talk about user activity on a web service where it makes sense to be hitting a server, but for a local app that should really just be a nice GUI for ffmpeg, I don't want my computer updating you whenever I use it with data about how I used it.

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.


Below changes will be implemented this week:

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


I highly disagree. I think the majority of people who would pay money for a barebones ffmpeg wrapper don't care about telemetry.


Privacy should be the default, not something that is done only when users care enough to fight back.


I agree with you to a point. The problem is that if most people turn it off, then developing the telemetry system was a huge waste of time and resources for not much gain. Valuable data that could have been used to improve the program without any extra work from others may be lost.

Similar to Windows forcing users to update because most of them keep putting it off forever, hurting their own security.


Which users asked for devs to focus on developing a telemetry system (vs developing the app they bought)?


I wouldn't worry about it if I was the developer. Many people on HN might care but most people on average (even semi-technical folks using a tool like this) probably don't care. Most products have some sort of telemetry capabilities built-in (and any smart developer should try and understand their audience and app usage) and the people who care probably tend to on average be more wary about downloading closed-source non-App Store apps anyway etc.


It's not mentioned in the terms of service either.

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".


Thanks for the feedback. I will update it this week.


Block this domain with a firewall or DNS filter like NextDNS?


That’s at best a weak band-aid. Who knows if blocking that one domain stops everything? We shouldn’t have to resort to firewalls or DNS filters to stop local apps from collecting our information.


Thought of this too, how do they know how many GB are being reduced? Hope the analytics can be opted out.


I will implement the option to opt-out anonymous telemetry this week. Thanks for the feedback


I wouldn't even bother. The vocal minority in here complaining about it aren't the people who would even use the software in the first place.


You're being modest in describing it as an FFmpeg "wrapper". Although technically true, I can see a lot of thought and effort went into the UX, and I think that's where the value lies. Good job!


Thanks, I just want to make it clear upfront to avoid any confusion


Yes that's exactly right, the extremely complex and clever code in ffmpeg that's understood by about 12 people in the world and is the basis for the entire media consumption in the world isn't where the value is, some gui frontend is.

Do you work for microsoft?


I agree with the GP here. Yes, you can do all this with just FFMPEG, but now you have to wade through all the docs, flags, values to craft your CLI args with a bit of trial and error. The value add here is a coherent front-end that abstracts away all the complexity and lets you cut right to what you want. Further, if it's something you do infrequently, or your workflow changes, you have to rerun the gaunlet of figuring out what flags/values you need. FFMPEG can do a ton, but most people just need to crunch the file size, transcode, and occasionally convert a snippet into a gif


> …you can do all this with just FFMPEG, but now you have to wade through all the docs, flags, values to craft your CLI args with a bit of trial and error. The value add here is a coherent front-end that abstracts away all the complexity and lets you cut right to what you want.

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.


I had to transcode some files recently. I’m extremely proficient with the ClI, but I would have loved to have a GUI version.


Handbrake...


Right, the value add should obviously remain locked in the hands of a few elite professionals and the rest of the world should have to beg and grovel at their feet to get anything done. Any attempts to simplify workflows should be looked at with scorn and an aura of arrogance.

Do you work at Oracle?


You can craft script for ffmpeg using any of the AI chat providers, even a badger can do it. UI is nice, but we have handbrake already.

Do you work for local government?


There are things that are simple to use and user-friendly, but Handbrake is not one of those. Personally I use the command line, but different people have different needs, and it looks like there is a market for some video conversion software that does not scare a normal person.


> that's where the value lies

If you're not trying to pick a fight, the more sensical reading of this is "where the value [of this tool] lies".


I don't think ffmpeg is actually _extremely_ complex. A lot of the complexity (all the flags) you feel belonging to ffmpeg actually belongs to encoders (libx264, libx265, aomenc, libvpx, all the hardware encoders from each vendor). They each have various options meaning different things. ffmpeg is just an interface for them.


And it's a genuinely complex problem space. ffmpeg supports some pretty wild audio/video transformations, especially once you start getting into filter graphs (e.g. combining multiple audio/video streams into a single output); its command-line interface reflects that complexity.


That's fair, although the stuff I can do with ffmpeg filters amazes me, and I barely scratch the surface

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.


I wonder how much money you donate to ffmpeg itself. also people are paying for this just for Ui/Ux?


I sort of hit a wall with ffmpeg where no matter what settings I used, I'd get slightly better output with Handbrake so now I just handbrake everything.


Just interested, how do you manage licensing tarpits around certain video codecs supported by ffmpeg?


FFmpeg is not bundled with the app. User will have to install it separately and link it with CompressX. Hope this explains


Indeed - he has detailed instructions: https://hieudinh.notion.site/How-to-setup-CompressX-93a89b07...


Yup, all clear, thanks!


"licensing tarpits" patent trolls?


Various codecs ffmpeg supports have legitimate patent licenses. I can't think of any of the patent pools with NPEs, actual patent trolls.


GPL2

Since FFmpeg is GPL2, doesn’t that require CompressX to disclose its source code?

IANAL, apologies if I miss understand license requirements.

https://github.com/FFmpeg/FFmpeg?tab=License-1-ov-file


Doesn't this license file say that most of ffmpeg is LGPL2? IANAL either, but my understanding is they are fine to distribute their application however they want assuming they did not use any of the opt-in GPL2-licensed functions, and they link to ffmpeg as a shared library.

EDIT: seems like the user has to install ffmpeg separately, so seems like they are in the clear anyway? https://hieudinh.notion.site/How-to-setup-CompressX-93a89b07...


Congrats. But what's your Weissman score?


Doesn't that only apply to lossless compression? I haven't seen the show in quite awhile.


haha, thanks


Great looking product,

if anyone wants to do the same stuff for free on windows (except image resizing)

I use FFMPEGBatchAVConverter

https://ffmpeg-batch.sourceforge.io/

Batch FFMPEG conversion (I usually go from h264 to HEVC with my NVIDIA GPU 3060Ti)

> ffmpeg -i file.mp4 -c:v hevc_nvenc -rc vbr -cq 24 -qmin 24 -qmax 24 -profile:v main10 -pix_fmt p010le -b:v 0K -c:a aac -map 0

and LosslessCut

https://github.com/mifi/lossless-cut for ffmpeg cutting and splicing p0rn scenes.


This is very, very cool. FFmpeg is an amazing tool but you can't leverage it as a casual user. This makes a lot of sense.

Great looking app too.


Thanks


Can you describe what you did on your twitter and marketing efforts?


I share my journey, the development progress, the SEO learnings, the lessons in public


I liked your privacy policy and terms of service. Simple and straightforward.


Thanks


Can you share how you did the marketing? Was it just twitter? I'm getting ready to launch an app right now and have no idea where to start with marketing.


I have an audience on Twitter, so when I launch my app on Product Hunt, my audience helped to spread awareness of the launch. If you don't have an audience, I recommend building one. I also launch my app on other SaaS directories to get some traffic from them.


I admire you for calling something this effortful as a wrapper.

A lot of people would just go “look at this app I made by myself, it compresses files”


Nice work! Out of curiosity, is it calling the FFmpeg CLI or linking directly against FFmpeg libav?


It’s calling the FFmpeg CLI


This is actually neat. I know my way around the command line FFmpeg, but this is something I could pretty easily get my dad to use. He does a lot with video but he isn't great with the command line.


Amazing! Congratulations and so happy for you.

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.


You can start with getting your idea validated first by making a small demo or MVP and share it somewhere. For me, I use Twitter as the main channel to build an audience and share everything I do publicly there


How large you think should the twitter audience be to get initial traction for an MVP?


What’s the command line?


What tools did you use to make your snazzy screencasts??? I'm currently looking to make a video just like that for our product.


https://www.screen.studio/


Thank you!


What does ffmpeg do that AVFoundation does not?


Supports hundreds of file formats both new and ancient, ability to control every aspect of encoding, uses libx264/x265 which are much better than the libraries available in AVFoundation etc..

What does AVFoundation do that ffmpeg cannot? Probably streaming libraries, Dolby Vision support, hardware accelerated encoding.

AVFoundation is great for what it is, an OS embedded library.


> …uses libx264/x265 which are much better than the libraries available in AVFoundation etc.

Citations? As a counter-example, AVFoundation's AAC encoder trounces anything in ffmpeg, which ffmpeg thankfully exposes suffixed "_at".

  ffmpeg -i input.wav -c:a aac_at -profile:a aac_he -b:a 64k output.m4a
https://wiki.hydrogenaud.io/index.php?title=Apple_AAC


Oh I thought we were talking about AVFoundation which is more for video than audio.

It's well known[1] that x264 is the best h.264 encoding library and produces the highest quality at the lowest bitrate (obviously at the expense of encoding speed). Software encoders for any codec are generally going to get better quality results at lower bitrates because of their ability to use more complex features.

OS library encoders are generally more focused on streaming and bitrate stability than quality. And to be honest, QAAC (Apple Core Media's AAC encoder) is kind of an anomaly that I'd chalk up to the absolute amazing amount of engineering that went into the ipod/iphone era.

[1] https://www.compression.ru/video/codec_comparison/h264_2012/


ffmpeg supports hardware acceleration too via VideoToolbox.


More formats, presumably?


Since ffmpeg has a wasm build, couldn't this be done client side?


Wasm is rarely a solution and still has yet to be of much use. FFmpegs codecs are mostly hand written optimized assembly using advanced instruction sets not known to wasm. I crafted my own years ago but you're fighting a runtime that can never specifically leverage critical things like CPU cache.


I'm going to miss adapter by macroplant the day it stops working


I like the automation features! Good job; it is well-polished Hieu!


Thanks! Feel free to let me know if you need anything


One of my good software purchases this year. Good work, Hieu.


Thanks! Feel free to let me know if you have any feedback


Is it just me or is it deceptive to say that a person saves 50% when buying the "standard" license? Both Claude and Gemini seem to come up with a savings of almost 24%. The only way I can reach the 50% mark is by phrasing it as "buy 1 license and get a second license 50% off."

Also "testimonial" should be plural, and "spams" should be singular.


Thanks for the feedback, this is updated to "Save $9" now. Also update "Testimonial" and "No spam"


Congrats, Hieu!


Thanks!


While it's true that ffmpeg's license doesn't require you to release the source code of your application, ffmpeg is GPL, and so it's in good form to also make your application open source.

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.


Looks like FFMPEG is mostly LGPL, but there are some GPL parts. You can compile without the GPL parts.

Certainly would be prudent to check out https://ffmpeg.org/legal.html


FFmpeg is not bundled with the app. User will have to install it separately and link it with CompressX. Hope this explains


He's commenting on the spirit of software released under permissive licenses like GPL.

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


10% of last month revenue was donated to FFmpeg. Thanks for clarifying


Looks like a good tool for dealing with ffmpeg's infamous variety of command line options. Just curious, how much are you contributing upstream?


Why would you expect a GUI frontend to contribute upstream?


> Just curious, how much are you contributing upstream?

Additionally, in terms of code and financial support?


10% of last month revenue was donated to FFmpeg


Now that's responsible Open Source behaviour :) Glad to see people being decent


can you explain why would i pay and use this over Handbrake on a Mac?


You wouldn't, as you know about handbrake. Not trying to be a jerk- but serious.

I saw this go viral on Twitter and commenters had no clue ffmpeg was a thing and thought he built this from scratch.


<whoops, meant to write to OP but messed it up and wrote it here>


the person you're responding to is not the OP


If you're a Handbrake user, you most likely won't need this app. The main feature that I think Handbrake users want to have is the automatic compress new files in a folder, and maybe integration with Raycast extension.


Handbrakes UI is a mess.


how so? you literally select a file, and choose a preset and export. Not happy with one of the presets? Cool, adjust some quality sliders and hit export.


Handbrake settings can be overwhelming for beginners once they escape the playpen of presets, while CompressX provides just a handful of controls, with no bitrates or codec names in sight.


[flagged]


Thanks




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: