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