[HN Gopher] Show HN: CompressX, my FFmpeg wrapper for macOS
___________________________________________________________________
Show HN: CompressX, my FFmpeg wrapper for macOS
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.
Author : hieu_dinh
Score : 142 points
Date : 2024-04-10 06:32 UTC (16 hours ago)
(HTM) web link (compressx.app)
(TXT) w3m dump (compressx.app)
| throwaway598 wrote:
| I liked your privacy policy and terms of service. Simple and
| straightforward.
| hieu_dinh wrote:
| Thanks
| matthewfelgate wrote:
| Congrats. But what's your Weissman score?
| hieu_dinh wrote:
| haha, thanks
| tombert wrote:
| Doesn't that only apply to lossless compression? I haven't seen
| the show in quite awhile.
| dinhquochan wrote:
| Congrats, Hieu!
| hieu_dinh wrote:
| Thanks!
| lostsoul999 wrote:
| One of my good software purchases this year. Good work, Hieu.
| hieu_dinh wrote:
| Thanks! Feel free to let me know if you have any feedback
| nen-nomad wrote:
| I like the automation features! Good job; it is well-polished
| Hieu!
| hieu_dinh wrote:
| Thanks! Feel free to let me know if you need anything
| fancythat wrote:
| Just interested, how do you manage licensing tarpits around
| certain video codecs supported by ffmpeg?
| zoobab wrote:
| "licensing tarpits" patent trolls?
| giantrobot wrote:
| Various codecs ffmpeg supports have legitimate patent
| licenses. I can't think of any of the patent pools with NPEs,
| actual patent trolls.
| hieu_dinh wrote:
| FFmpeg is not bundled with the app. User will have to install
| it separately and link it with CompressX. Hope this explains
| EricE wrote:
| Indeed - he has detailed instructions:
| https://hieudinh.notion.site/How-to-setup-
| CompressX-93a89b07...
| ranger207 wrote:
| Looks like a good tool for dealing with ffmpeg's infamous variety
| of command line options. Just curious, how much are you
| contributing upstream?
| zamalek wrote:
| > Just curious, how much are you contributing upstream?
|
| Additionally, in terms of code and financial support?
| hieu_dinh wrote:
| 10% of last month revenue was donated to FFmpeg
| ghusto wrote:
| Now that's responsible Open Source behaviour :) Glad to see
| people being decent
| azinman2 wrote:
| Why would you expect a GUI frontend to contribute upstream?
| edyc5 wrote:
| Can you describe what you did on your twitter and marketing
| efforts?
| hieu_dinh wrote:
| I share my journey, the development progress, the SEO
| learnings, the lessons in public
| Solvency wrote:
| can you explain why would i pay and use this over Handbrake on a
| Mac?
| jasonjmcghee wrote:
| 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.
| moralestapia wrote:
| <whoops, meant to write to OP but messed it up and wrote it
| here>
| claytonjy wrote:
| the person you're responding to is not the OP
| wpm wrote:
| Handbrakes UI is a mess.
| Solvency wrote:
| 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.
| CharlesW wrote:
| 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.
| hieu_dinh wrote:
| 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.
| TheDong wrote:
| 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.
| MattPalmer1086 wrote:
| 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
| hieu_dinh wrote:
| FFmpeg is not bundled with the app. User will have to install
| it separately and link it with CompressX. Hope this explains
| Topgamer7 wrote:
| 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
| hieu_dinh wrote:
| 10% of last month revenue was donated to FFmpeg. Thanks for
| clarifying
| jjice wrote:
| 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.
| jasonjmcghee wrote:
| 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.
| cjk2 wrote:
| 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.
| azinman2 wrote:
| What did you buy for windows? If you're using the Mac full
| time, sounds like you don't need this software on it?
| cjk2 wrote:
| 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.
| cjk2 wrote:
| 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.
| Solvency wrote:
| 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.
| cjk2 wrote:
| Electron serves the developer not the user.
|
| It also looks shit on every platform then.
|
| And eats all your RAM
| dotinvoke wrote:
| 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.
| cjk2 wrote:
| No instead I run 50 standalone browsers with one tab each
| on my machine ...
| saagarjha wrote:
| That's not the complaint lol
| ericlewis wrote:
| Not that it really matters I guess, but electron apps are
| chunky. Huge bin size and large memory usage.
| Solvency wrote:
| were talking about a tiny desktop app that wraps ffmpeg
| CLI. this is the perfect use case for it, over, say,
| VISUAL STUDIO CODE.
| cglong wrote:
| 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.
| ubercow13 wrote:
| The perfect use case for a massive incredibly complex
| browser runtime is...a tiny desktop app? What?
| greggsy wrote:
| People rage about Electron being insecure and bloated, but
| by Jove it's a godsend for consistency and portability.
| alwayslikethis wrote:
| 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.
| giantrobot wrote:
| 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!
| joshstrange wrote:
| > 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.
| andsoitis wrote:
| 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.
| wtallis wrote:
| 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.
| talldayo wrote:
| 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.
| saagarjha wrote:
| People are more than happy to use Microsoft Office...?
| talldayo wrote:
| 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.
| saagarjha wrote:
| What is Google if not a Microsoft-scale company
| talldayo wrote:
| What is Google Docs if not a perfectly acceptable
| Microsoft Word replacement?
| ryandrake wrote:
| 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.
| refulgentis wrote:
| 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)
| greggsy wrote:
| Consistency >for portability
| jwells89 wrote:
| 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.
| kergonath wrote:
| > 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.
| datagram wrote:
| There is LosslessCut[1], though it's only designed to
| handle trimming and not general re-encoding.
|
| [1]: https://github.com/mifi/lossless-cut
| booi wrote:
| if you re-encoded then it wouldn't be lossless anymore?
| rpgbr wrote:
| 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.
| knubie wrote:
| 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.
| hieu_dinh wrote:
| 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
| jwells89 wrote:
| 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.
| ryandrake wrote:
| 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.
| jwells89 wrote:
| 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.
| encom wrote:
| Apple users are probably the only crowd that would pay money
| for a simplistic ffmpeg frontend.
| alwayslikethis wrote:
| 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.
| jwells89 wrote:
| 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.
| joshstrange wrote:
| 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
| hvaoc wrote:
| 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?
| altcognito wrote:
| 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"
| hbn wrote:
| 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.
| racl101 wrote:
| 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.
| hieu_dinh wrote:
| Thanks
| brigadier132 wrote:
| 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.
| hieu_dinh wrote:
| 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.
| egorfine wrote:
| 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.
| hieu_dinh wrote:
| 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
| egorfine wrote:
| How large you think should the twitter audience be to get
| initial traction for an MVP?
| ghusto wrote:
| 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!
| hieu_dinh wrote:
| Thanks, I just want to make it clear upfront to avoid any
| confusion
| ta1243 wrote:
| 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?
| nexuist wrote:
| 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?
| Citizen_Lame wrote:
| 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?
| kergonath wrote:
| 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.
| DistractionRect wrote:
| 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
| greggsy wrote:
| I had to transcode some files recently. I'm extremely
| proficient with the ClI, but I would have loved to have a
| GUI version.
| CharlesW wrote:
| > _...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.
| parhamn wrote:
| > 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".
| alwayslikethis wrote:
| 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.
| duskwuff wrote:
| 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.
| Cyph0n wrote:
| Nice work! Out of curiosity, is it calling the FFmpeg CLI or
| linking directly against FFmpeg libav?
| hieu_dinh wrote:
| It's calling the FFmpeg CLI
| tombert wrote:
| 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.
| sam0x17 wrote:
| 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.
| m3kw9 wrote:
| What's the command line?
| worg wrote:
| I'm going to miss adapter by macroplant the day it stops working
| emmanueloga_ wrote:
| 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")
| blopker wrote:
| 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 wrote:
| EXIF metadata accounts for so little of the overall file size
| it isn't even worth mentioning...
| threecheese wrote:
| 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?
| kinduff wrote:
| Thought of this too, how do they know how many GB are being
| reduced? Hope the analytics can be opted out.
| ubanholzer wrote:
| The app connects to telemetrydeck.com. Sadly, couldn't find any
| opt-out setting.
| hbn wrote:
| 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.
| rpgbr wrote:
| Block this domain with a firewall or DNS filter like NextDNS?
| latexr wrote:
| 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.
| daniel_iversen wrote:
| 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.
| elondaits wrote:
| 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".
| atonse wrote:
| What tools did you use to make your snazzy screencasts??? I'm
| currently looking to make a video just like that for our product.
| mgrey wrote:
| https://www.screen.studio/
| atonse wrote:
| Thank you!
| PsyNyde wrote:
| I wonder how much money you donate to ffmpeg itself. also people
| are paying for this just for Ui/Ux?
| akaru wrote:
| What does ffmpeg do that AVFoundation does not?
| booi wrote:
| 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.
| saagarjha wrote:
| ffmpeg supports hardware acceleration too via VideoToolbox.
| CharlesW wrote:
| > _...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
| saagarjha wrote:
| More formats, presumably?
| alberth wrote:
| 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
| pelletier wrote:
| 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...
| minicoz wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-10 23:01 UTC)