Show HN: LosslessCut – Cross-platform GUI tool for fast, lossless video cutting | Hacker News Reader

Show HN: LosslessCut – Cross-platform GUI tool for fast, lossless video cutting

github.com

98 pointsmifino33 comments

I guessed from the title it was going to be using ffmpeg, because I myself have used ffmpeg's `-ss`, `-t`/`-to`, and `-codec copy` numerous times for this exact purpose.

Then I saw that this bundles its own piece of Chromium and ffmpeg and is ~70 MB in size. Something is seriously wrong with today's app development ecosystem if it takes 70 MB, even when I already have both Chromium and ffmpeg on my system.

EDIT: On the other end is QtAV, a cross-platform multimedia player and SDK which took me only 1 MB of network download. It uses Qt and ffmpeg, both of which I already have on my system, so it doesn't have to redundantly bundle anything.

On OSes without Qt and ffmpeg in their package repos (OS X and Windows), the players are ~ 20 MBs in size. So even if one argues "cost of cross-platform compatibility", it still doesn't make sense to bundle the entirety of a web browser for something as simple as this.

You are correct, it's a GUI for ffmpeg's -ss -t commands. It's always a tradeoff between ease of installation and development for multiple platforms vs reusing already installed components. I know ffmpeg has historically been changing their API alot between their versions. I wanted to make something that just works, built on battle tested technologies. Space is cheap too, and the size of the app is tiny compared to the videos you are processing. The windows binary of QtAV is btw 35MB (i assume compressed), so quite big too. Fun fact though: ffmpeg is actually bundled twice in LosslessCut. once in Electron(Chromium) and once as a CLI :)

> The windows binary of QtAV is btw 35MB (i assume compressed)

Perhaps you're looking at player+SDK. The player alone[0] is 21MB

> ffmpeg is actually bundled twice in LosslessCut. once in Electron(Chromium) and once as a CLI

If you use a custom build of Electron, you can at least cut down ffmpeg to just one version. Like the way my distro does it with Chromium and ffmpeg.

----

0: https://www.microsoft.com/en-us/store/p/qtav-video-player/9n...

Yes, I could call ffmpeg from native code. But it's a bit more of a hassle to do from javascript than to just start the ffmpeg exe. And if the included ffmpeg lib was to crash, I can imagine that the whole application would crash too. But I'm open to suggestions.

I'm surprised there isn't a Node binding for libav/ffmpeg yet.

I have the same problem with lots of other open source video tools. I wish it was easier to use ffmpeg via library and then more people might do it.

Yes I had trouble finding it too. I guess it's because the ffmpeg API is so enormous and evolving all the time, that if there was to be node bindings for it, it would have to be maintained by the ffmpeg team. I think the CLI is the most stable API contract to the outside world, and everyone in the node world uses the CLI. I had an idea to use node-ffi, though. Which doesn't require linking or bindings or anything. Just call the native ffmpeg code directly from nodejs.

That is not what I meant.

I meant using the same version of ffmpeg as the shared lib linked with Electron and linked with the binary.

So, your bundle would have libavutil.so somewhere in a `lib/` folder, and in the `bin/` folder you'd have `ffmpeg` and `electron` (or equivalent) both dynamically linked against the `lib/libavutil.so`.

I see. That should be possible, yes. If the ffmpeg from electron is built with the necessary features for the CLI and cutting to work. It would however require some quite complicated build scripts, I can imagine.

Bandwidth and storage space are cheap; hassle is expensive.

I can't tell you the number of times I've ended up cursing the IT gods while sorting out some hellish dependency / shared-libary-versioning fiasco (and apps that use ffmpeg and other media libraries are especially prone to this), and wished I could have just gotten a statically-compiled binary off of the developer's CI server instead.

Most of the arguments for shared libraries seem like a misplaced optimization on modern systems (e.g. saves disk space, saves distribution bandwidth), or don't really shake out in reality (e.g. "only have one copy of a crypto library so it's easy to update!") and just lead to a proliferation of library versions on the same system.

I spent most of last week using 2-8 megabit LTE as my only network connection. Bandwidth is not always cheap.

True, but time is more valuable.

The most I get here is 1.5 megabits. Yes, Australia. Yes, a terrible data cap: 100GB.

Electron apps don't get downloaded. One app is one less Netflix video I can watch.

musl lets you have statically linked C nice and easy. (glibc can't really be made static). It produces executables that can fit on a floppy disc even for large stuff. Alpine has a statically linked ffmpeg, though it can be difficult to compile occasionally.

Bandwidth can be cheap, depending on where you are, but giant applications just sort of smell of "get it working now" instead of "make sure it will give the user a good experience".

I'm legitimately pissed off by this. Electron apps are always annoying to see but this one is genuinely offensive. I hate the culture and ecosystem Electron has allowed to flourish. This project is an insult to computer science.

Embrace the future :) If you really want a small footprint app, you could build your own electron linked to your locally installed libchromium and locally installed node.js, then you can run the app against your local ffmpeg (from PATH, which is the default behaviour if the bundled ffmpeg is missing). Now it's only a few MB in size.

70MB is less then U$0.01

And for that, you get one hell of a text/layout engine, hardware accelerated 2D/3D graphics, integrated IDE, one the fastest interpreted runtimes around, which happens to be the most popular programing language…

All Open Source, cross platform.

Yeah, insulting indeed. Who needs those damn Electron apps.

> one the fastest interpreted runtimes around

Maybe tangential but I think V8's speed has become somewhat mythologized. In AWFY [0] benchmarks I've seen JSC routinely come in 30-50% faster.

[0] https://arewefastyet.com/

>you get one hell of a text/layout engine, hardware accelerated 2D/3D graphics, integrated IDE, one the fastest interpreted runtimes around, which happens to be the most popular programing language…

All so you can provide a graphical interface for two ffmpeg flags.

> All so you can provide a graphical interface for two ffmpeg flags.

"everything old becomes new again"

reminds me also of the hot new trend of chat based interfaces. (hmmm, pretty sure that was our default computer interface back in 60's/70's/80's)

I'm legitimately offended by your comment.

I find most Electron apps to be well designed, run quickly, can be optimized for efficient power use, and are hassle-free to download and install. They also do not require a lot of the developers time to make something that looks good and builds for my operating system, so they can spend that time on more important things.

I love the culture and ecosystem Electron has allowed to flourish. Anybody with some basic knowledge of installing software packages and some HTML and JavaScript can make an Electron program and share it with their friends. I think that's really cool. It reminds me of my beginning days as a programmer, when I could write a few lines of code (I only knew how to write a few!) and make something interesting that I could show other people. Today I have a career out of that.

Finally, I really do think that your comment is an insult to computer science. Our ability to leverage abstraction so that programming useful things is accessible to a huge number of people is very cool to me. If Electron was wiped off of the face of the earth and never existed, I'd be rather sad at the loss. There are kids out there learning to program using Electron. There are people like me who just kinda prefer a GUI interface to a command line one depending on what they're working with. There is so much good introduced into the world by this thing, and not really any evil.

Your comment, in contrast, seems intended to piss all over a great many peoples hard work. If I was an Electron developer or a Chromium developer, I'd be pretty hurt by this. If I was that person, I'd be thinking every day about how code I wrote was being used to deliver cool applications to folks who might not otherwise have it.

You've not even found exactly one thing to criticize. I don't know what about it pissed you off, because you didn't tell me. I don't know exactly why Electron apps annoy you—they don't annoy me (after all, I can just choose not to use them if I desire). You've expressed hate for a culture and ecosystem that seems to be not your own, but you've given not a hint of an argument as to why that's such a bad thing. Finally, you presume to speak for all of computer scientists and feel INSULTED when the developer did nothing to you to harm you or offend you.

I'm shocked and chilled to the core that a comment of such pure hatred is allowed to just sit here. It must have taken you all of 3 minutes to write that comment and ruin my morning, not to speak of some others who might read this.

> I find most Electron apps to be well designed, run quickly, can be optimized for efficient power use

As long as we're doing personal experiences, I find most Electron apps to be:

1. Poorly designed. Flow of keyboard control is usually all over the place, as if the developer completely skipped the idea of making the app keyboard accessible. This is the case with even big-name Electron apps with a lot of development effort behind them, like Atom. Sure, it has keyboard shortcuts, for some actions, but that's it. Half the time focus ends up someplace I didn't expect it to, and I have to use a mouse-click to focus. Half of that time, it's the Ctrl-Shift-P popup that misses the keyboard focus.

2. Run slowly. Slack, Spotify, Atom. All run slowly on my system. Not slowly in the sense they grind to a halt and become unusable (well, Atom does), but slowly compared to native apps. It's noticeable, it's annoying; and in the case of Atom, it's frustrating.

3. Suck battery OS X's stats are enough to back this up. Chrome is a power hog, and every Electron app is running its own copy of Chromium. Most apps don't bother to do anything towards respecting power efficiency, since it's so easy to just cobble up and app and throw it up. Slack and Atom again, are the examples I chose for this.

VS Code is the only browser-embedded app I know that manages to not be too slow and somewhat respect power consumption. I reckon similar feats cannot be pulled off by a developer spending little time on the code, the kind of developers you talk about.

> Anybody with some basic knowledge of installing software packages and some HTML and JavaScript can make an Electron program and share it with their friends.

That is exactly the kind of thing the web evolved to support. Unfortunately, Electron takes that idea and turns it on its head. While the web didn't require someone to download an entire browser for every individual site, Electron does for every app. That, is my problem with this model (I don't know about your parent commenter).

I agree that Electron apps can be slow. I think that has to do with the single thread event loop, which it is very easy to block when doing some heavy processing, if you don't think about it all the time. On the other hand Electron apps are very stable and I don't think I've ever had one segfault on me, like happens with a lot of native applications. It's still quite early in the world of Electron, so I can imagine speed will increase as people develop new techniques for writing better code for complex apps. Like VS Code probably did something right there.

> Something is seriously wrong with today's app development ecosystem if it takes 70 MB, even when I already have both Chromium and ffmpeg on my system.

I used to think this way about Electron as well, but then I tried bundling up a ~30 lines long Python/NumPy+SciPy script for standalone use on Windows. pyinstaller produced a 300mb blob; the smallest I could get the whole thing was around 100mb.

> for standalone use on Windows

There's the difference. In your case, you were bundling for a system that didn't already have Python+NumPy+SciPy. In my case, I already have Chromium/Chrome and ffmpeg on my system.

Check out AviDemux, http://fixounet.free.fr/avidemux/ it offers a simple UI and also lossless cutting.

Amusingly, AviDemux, which has a LOT more ability than just cutting... is about 71 meg.

So you're playing with version X of ffmpeg and cutting with version Y. It seems that X+Y equals disaster.

I think including everything is super cool because I had the app installed and running in under 10 seconds. What wasn't cool was that I asked to cut a short 15 s video to the first second, and there was no feedback but the spinning gear for 5 minutes.

That's a bug then: https://github.com/mifi/lossless-cut/issues Edit: could you check if ffmpeg was still running while it was spinning? Maybe we need to kill it if it takes too long.

How do you deal with the fact that some video tracks do not provide the needed cross-frame data or the times you're cutting are at unfortunate points which would require a re-encoding because a quick byte copy of the existing stream doesn't work or at the very least will complain later about missing things like color info (although it's played back correctly by mpv)?

I don't know what you mean by cross-frame data. The program is using ffmpeg's -ss, -t, and vcodec copy functionality, and I'm not sure how it handles these issues. I know that if you cut between keyframes (which is very likely to happen), then the data before the next keyframe will be lost, so it is not an exact cutting mechanism.

That's another issue, but it can also lose other data which will cause warnings but play most likely with correct color reproduction.

I don't have such a source file handy to reproduce, but if you try enough ISO MP4 containers with H246, you will hit one where this is the case.

Is `-t` different from `-to` which I've been using?

libavcodec tries to recover from missing frames (you need this for TV broadcasts) but it's actually not very good at it for H.264. You'd almost always see major artifacts.

Any idea what the exact warning text is?

Reply on news.ycombinator.com