Not sure what you mean by container repacking, but if you mean "Converting to supported codec", you can try instead from the File menu to convert using the "Fast: Full quality remux (no audio), likely to fail"-method. that is much faster and if it works it allows native scrubbing. Also I'm planning on improving the "Unsupported videos" experience in the future by using something like the MediaStream API
Which exact experience with using an electron app are you talking about that some people don't like? The size or memory usage? I get that some people like to run multiple apps at the same time and are running out of memory, but I think many other apps use more memory than Electron based apps. Of course trying to reduce the memory footprint of an app is always a good thing, so that's indeed a trade-off.
> I get this perspective from the developer point of view
I'd argue also for most end users' point of view as they will most likely get a more stable app when the average developer doesn't have to write C/C++.
> The thing is, I have dozens or hundreds of tiny little utilities like this installed that make one-off tasks that I do once a month or so much easier. I can't afford for them to be Electron based on my 128 GB SSD.
That's a fair point. I also feel the pain of installing large apps on my MacBook with 256GB SSD. But I think I would still take a large app with all the other benefits than an app that might SEGFAULT all the time, but is small because it's written in C/C++ (like what has been my experience with avidemux for example).
> On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages
I get this point, and I used to be an avid Gentoo user myself so I compiled everything from scratch and liked the small size and efficiency of a dynamically linked system. I think the biggest drawback with this approach is that sometimes sharing libraries with "compatible" versions will cause bugs because those versions actually have certain tiny differences that cause bugs to appear, whereas with a static build you lock down the whole dependency tree (except the OS level libs), so you know almost for sure that the app is going to work exactly the same regardless of the system you run it on.
Actually because the bundled JS itself is quite small for LosslessCut (32MB), it would be theoretically possible to bring-your-own electron (even from source), e.g. use a single system-installed electron that can be shared by many different electron apps, as well as use the system installed ffmpeg. Then you could run `electron Resources/app.asar`. It might be possible to setup such a minimal build.
I just discovered this post, and I'm really happy to see a lot of satisfied long time users as well as excited new users who recently discovered this.
I think the most common criticism is that the app is large and uses a lot of memory (compared to Notepad?:P) due to it being Electron based. Somewhat unpopular opinion, but here goes: Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides. It lets you easily build a cross-OS app on a super optimised, stable and secure platform that's being battle tested by billions of people around the world every day (Chromium). It gives you all the features of the web, and it "just works" on almost any popular OS. The web has all the big tech pushing new features and improvements all the time and it maintains really good backwards compatibility. I don't think I ever had the LosslessCut app actually crash on me. CI, automatic building and releasing to all different kinds of channels is a breeze due to tools like `electron-builder`.
I think if you compare it to most other lossy video editors, you'll find that the CPU usage is much lower (especially per minute of produced video!), and the memory footprint is probably lower than many other popular video editors. Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time and doesn't really benefit 99% of users. Counter arguments are welcome :)
If you mean a video where the camera was rotated while recording, I believe no, that's not possible to do losslessly. I believe the orientation flag stored in the metadata cannot change over time. Correct me if I'm wrong.
- author
HEVC is supported in the latest beta version, if your computer has a hardware HEVC decoder. It's a WIP as HEVC support was just recently introduced into Chromium (source: author)
You should try to learn JS - it's really awesome. Asynchronous, incredibly stable, battle tested by billions of users every day, it has one of the best open source module ecosystems in the world, and it runs everywhere.
I might add the ffmpeg-static npm package, then no need for system ffmpeg. But that package does not work on raspberry pi, so yeah.. Downloading and installing static ffmpeg builds from ffmpeg.org is pretty easy these days
If by mute you mean cut away, then that's not implemented yet. You can achieve an inverse cutting by adding the same clip twice though, with cutFrom and cutTo.
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.
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.
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.
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 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.
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.
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.
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 :)