Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: CompressX, my FFmpeg wrapper for macOS

compressx.app

Post reply on HN
Print view View original

81–90 of 173 posts

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#81

Post by jwells89 »

Solvency wrote: post #65
cjk2 wrote: post #31

Earlier quoted context omitted.

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 thre…

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.

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.

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#82

Post by cglong »

Solvency wrote: post #70
ericlewis wrote: post #68

Earlier quoted context omitted.

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.

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#83

Post by ubercow13 »

Solvency wrote: post #70
ericlewis wrote: post #68

Earlier quoted context omitted.

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.

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

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#84

Post by kergonath »

Solvency wrote: post #65
cjk2 wrote: post #31

Earlier quoted context omitted.

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 thre…

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.

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#85

Post by jwells89 »

alwayslikethis wrote: post #79
encom wrote: post #73

Earlier quoted context omitted.

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

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 usag…

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.

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#86

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

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#87

Post by giantrobot »

alwayslikethis wrote: post #72
greggsy wrote: post #69

Earlier quoted context omitted.

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!

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#88

Post by joshstrange »

alwayslikethis wrote: post #72
greggsy wrote: post #69

Earlier quoted context omitted.

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.

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

Re: Show HN: CompressX, my FFmpeg wrapper for macOS

#90

Post by refulgentis »

alwayslikethis wrote: post #72
greggsy wrote: post #69

Earlier quoted context omitted.

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.

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)

Post reply on HN