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 :)
> Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides.
As someone who wrote performant Electron apps, I disagree. Electron has great documentation, but I found little else to praise.
> stable and secure platform
A major factor to me stopping to write Electron apps was the frequent updates needed due to some new flaw upstream. To make matters unbearable, every time there was an update something else had changed with the build tool or the Electron API, which I then had to relearn and painstakingly change everywhere.
I like apps to be done, I don’t want to be forced to babysit in perpetuity an otherwise working app.
> Storage is cheap
It is not. People buy computers and mostly stick to the internal disk which they can’t or don’t know how to change. No one is happy to have to buy and use an external hard drive because their apps—which are orders of magnitude larger than they could be—are eating up all available space.
I can't comment on your first two points, but in the context of video editing, yes, 500MB is cheap. Most of us photo/videographers are used to handling hundreds of GB of data.
You’re used to professional apps which do a lot. LosslessCut is a simple, limited app (I say this as a positive) which is perfectly usable by non-pros who don’t deal with that much data.
> in the context of video editing, yes, 500MB is cheap
This type of thinking is pretty common in HN, where they live in a rich country. Then the same people apply their situation to whole world. It's not same in developing world. People still have to manage their savings for storage.
> It lets you easily build a cross-OS app on a super optimised, stable and secure platform ... Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time
I get this perspective from the developer point of view, but I'm not a video editor. I'm a person who occasionally edits videos. Elsewhere in this thread I mentioned that I use vidcutter, a free and open source tool that does the same basic task. After installation it takes 14 MB on my Linux distribution (it's a 4 MB download).
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. For people who edit videos every day it's obviously not an issue, but I wouldn't be surprised if the majority of people who use tools like this don't use them every day. Maybe not even every week. All this extra space adds up.
I think, in fairness, that a lot of the anti-Electron criticism comes from Linux users like myself. Windows users expect to have everything packaged as one gigantic binary with all the dependencies. (Vidcutter is a 175 MB download on Windows.) This strikes most of us as "poorly engineered", which for some is already enough of a reason not to use something. On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages. Electron applications are rarely distributed this way, and that's the biggest part of the problem and the source of a lot of the bloat from a Linux user's perspective.
> 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 very rarely have to cut video. I used to use vidcutter, but I now use LosslessCut. My experience with LC has been far better than with vidcutter. I've never even considered going back to vidcutter. I don't entirely disagree with your criticism, however the reality of the usage can easily outweigh these points (for me, obviously). Which is just to say I would recommend trying it if you haven't.
It's quite possible that LC is far better than vidcutter, I agree. Another reply to me mentioned better keyboard shortcuts, for example. I don't think this speaks to the point of whether or not the extra storage usage is justified, though, as building the application in Electron doesn't necessarily translate to a better experience.
In fact one of the reasons people dislike Electron is that it tends to result in a non-native UI appearance, which can make an application harder to learn and use.
> On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages.
honest question from a non-linux user - how much time do you spend in dependency hell? dynamic linking all the things sounds like a recipe for constant nightmare
I've never dealt with dependency hell, even once, on my current distribution. When necessary, distributions can ship multiple versions of a library and the software that requires each version will be linked appropriately. Basically, the answer is that the distribution is supposed to solve all these problems for you - and it does in fact work out that way in practice 99% of the time.
I understand why devs choose Electron and the benefits seems worth it overall and I'm glad it exists (and as you point out, a video editor might be an especially appropriate application for electron). That being said, it has a cost, and part of that cost is that there are certain users who don't like the experience of using electron apps. You may not agree with how big a deal this is for them, but the tone of this seems to be that they are wrong for having that preference. As a dev you don't really get to decide what users do and don't like; it's of course your prerogative to make whatever tradeoffs you wish, but I'd be careful about denying people's experience of your software.
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.
Hi, actual third world person reporting from the third world.
Most of our machines have no SSD and 8GB RAM on a laptop is a luxury. You can buy brand new Celeron machines like it's 1998. Windows 10 runs like shit and Windows 11 is basically a slideshow. Electron apps are the bane of our existence.
I'm not speaking of anything specific. Clearly enough people dislike the experience enough to avoid using apps based on it altogether. That's not my view or experience of electron apps broadly, but I'm single user on a specific setup. My point is less about specific criticisms of electron and more about the fact that dismissing people's experiences with it doesn't really do anything to win those folks over.
I object to Electron apps when they use a lot of my CPU cycles AND they're for functions that I want to run all the time, like chat programs. Not a problem for a video editor.
thank you very much for it being free and open source.
can container repacking be avoided? currently hls ts container is being extracted which takes time.
seeking "unsupported videos" is much slower than supported
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
Used this for ages. People will bring up various alternatives (including just strictly using FFmpeg) and I have to wonder if the only use case they can fathom is clipping 1 segment out of a longer video. All suggested alternatives would involve such a garbage workflow and unintuitive experience for any real project. I dislike Electron as much as anyone else but it works fine here, and does the job better than anything else I've tried. I am very comfortable with FFmpeg and have used pretty much any tool you can name, I still use Losslesscut daily.
Not sure exactly what your use case is, but I use vidcutter for lossless clip extraction and it works great and does not require Electron (it's QT based I believe). https://github.com/ozmartian/vidcutter
To answer a point that's been brought up elsewhere in the thread, one nice feature of vidcutter is that you can either cut fully losslessly (on keyframes) or cut frame-perfect while only encoding the frames before and after the first and last keyframes in the cut.
The Arch Linux package for vidcutter is only 4 MB. It has dependencies, of course, but I already have all of them installed for other things. (There's nothing uncommon.) All praise to dynamic linking.
Vidcutter is good but no where near as customizable as Losslesscut (specifically in terms of keybinds) and using the timeline is nowhere near as smooth. Its being developed in a way I approve of much more but I still prefer using Losslesscut by a large margin. If it ever catches up I'll be thrilled because I do like what its about a lot more but I don't really think it currently competes in terms of user experience. Still if it works well for you then there's a lot to appreciate.
I use FFmpeg for multiple streams and mux them into another container file format. Don't see what LosslessCut does outside of FFmpeg expect for the UI. The backend is anyway FFmpeg as another comment mentions. CLI haters I can understand, not me.
I at times am chopping up 2-8 hour videos with dozens of clips that are not pre-defined for me. I can do this with FFmpeg and I love doing most things from terminal but its a pretty hard sell when what you're doing involves something inherently graphical. I use FFmpeg for all sorts of things but it just doesn't make sense for editing such large videos on the fly like this.
Been using this for years, it's a very good and simple tool. There's a surprising amount of garbage in this space. SEO spam infects any searches you do for video editing software. Many "cut" tools actually just fiddle some start media timestamp in the file so the output file isn't smaller, just a video player will start at the right timestamp. Ie: not an actual cut. This one does the job.
It's implemented in Javascript with Chromium and the HTML5 video player. Not the way I would have thought to do it but makes cross platform a lot easier. You can do the same with ffmpeg on the command line of course but having a GUI to pick the cut points makes all the difference.
LosslessCut is a lifesaver for cutting segments out of my usually-unedited podcast[1].
The workflow to do a minor edit in a full editor like Final Cut Pro looks roughly like:
- open Final Cut Pro
- create a new proj... oh shoot no, a new library? Yeah that's right.
- click import and track down the videos on my hard drive
- now create a new project and drag the videos into the timeline
- use the blade tool to cut out a segment
- export the video which is... uh... oh yes under the share menu bar and then the format needs to be... hmmm... I think export for YouTube
- wait approximately `videoLength/5` for the video to export
- oh my goodness my hard drive somehow has `videoSize*4` less space
In LosslessCut that workflow looks like:
- open LosslessCut[2]
- drag and drop your videos in
- mark the start and end times of either the segments you want to keep or the ones you want to take out
- hit export and... wow, it's already done? How is that possible?! And it's just in the same format as my source video! Perfect. Oh man and it even saved a little xml file so if I happen to open the same file again I haven't lost my human work of marking the in and out points.
The cuts are usually slightly off from where I'd ideally like them to be, I think because LosslessCut can only cut on i-frames[3], but it's a totally fair tradeoff for my use case.
I liked the minimalist editor interface so much I copied the timeline part of it for a dedicated social media video clipper I'm working on[4].
If you'd like to try it out I strongly suggest installing it from GitHub and donating the amount you would've spent in the macOS app store. The macOS app store version has fewer disk permissions and adds an extra step asking for access to each folder you want to edit in.
1. makers.dev
2. frustratingly, right clicking a video and selecting "open in LosslessCut" doesn't work
3. i-frames in most video codecs are "key frames" that repaint the entire frame. Most frames are p-frames or "predicted frames" which just store a delta from the last frame.
> The cuts are usually slightly off from where I'd ideally like them to be, I think because LosslessCut can only cut on i-frames[3], but it's a totally fair tradeoff for my use case.
There is an experimental "smart cut" mode where it re-encodes the video between your cut and the next keyframe. It will of course not be entirely lossless though
> The cuts are usually slightly off from where I'd ideally like them to be
That is (probably) because the editor uses certain marks in the video (I don't remember how they are called) that "group" the frames together, and you can't use simple editors to re encode the video.
I had this issue some time I tried to cut videos from my gf. Then I moved to ShotCut, that cuts the videos exactly where you want, although the walkthrough is a little longer.
"“lossless” in Shotcut export does not imply the image goes through the engine untouched. It simply means that the codec is lossless or in lossless mode. The engine does not support every pixel format and color space in existence – only a few. Often sources get converted going through the engine. In your case, the source is RGB, but the engine defaults to yuv422 unless it has an mlt_image_format specified in Export > Other. For your 6SrK4.mp4, you would need mlt_image_format=rgb24 Also, in order to avoid image changes, you must use a Video Mode that matches the source and must not use any effecs (multiple video tracks, transitions, filters). (A mismatching video mode can cause automatic deinterlace, colorspace conversion, scaling, and padding)."
–source: https://forum.shotcut.org/t/lossless-annoyances/18344
Right, it will (by default) align the cut to the nearest I frame, which allows the cut to be "lossless." Doing the cut anywhere else requires re-encoding part of the video.
> This app is not for exact cutting. Start cut time will be "rounded" to the nearest previous keyframe, which may be a fraction of a second before your desired cut point, or up to several seconds, depending on the encoding.
I found this problem with all ffmpeg-based editors...does anybody know of an editor capable of cutting between inter-frames? The same happens with sound files, which is inconvenient.
As has been said, this happens because of cutting on the closest keyframe, which is the only point where the cut can be done losslessly.
This is how it's been done traditionally, since basically forever as far as I can remember. To be honest, I think modern tools could do better. If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted. There are a myriad tools to do the typical lossless easy cut, but no idea of one that goes the extra mile to do this more advanced technique.
> If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted.
All the P-frames and B-frames in between two I-frames have to be recomputed. That’s by definition re-encoding and not lossless.
You could re-encode just that small segment though.
This would obviously be codec dependent, but I'm surprised it's impossible to losslessly re-encode a video given I, P, and B frames. Mentally, I think of P frames as containing "changes" in the frame. The changes would be the same regardless of whether or not the previous frame was an I or P frame.
> I'm surprised it's impossible to losslessly re-encode a video
It is possible, it will just be a ridiculously large video.
> Mentally, I think of P frames as containing "changes" in the frame. The changes would be the same regardless of whether or not the previous frame was an I or P frame.
P-frames in modern codecs use multiple previously decoded frames, not just the previous frame. And I'm not getting into the complexity of frame ordering (decoded frames and presented frames can be ordered differently).
Oh so the P frame after the one you want to cut at may be looking farther back than just one I frame. I guess you could do the lossless cut at the previous I frame as this tool does, then also set the start media timestamp to the frame that you actually wanted to cut at, as described elsetheread by NelsonMinar.
> set the start media timestamp to the frame that you actually wanted to cut at
You can do that, but it’s container format-dependent (e.g. mov edit list) and player support is uneven. If the player doesn’t support it you get extended cut and A/V desync.
It's perfectly possible, just not with the common media-mogul owned and propagated video encoding formats. There are applications where you need a compressed video stream that does not have keyframes, so that you are not blind until the next one if one happens to get scrogged in transit. (Think things like UAV pilots blowing up things halfway around the world.)
These algorithms had methods have existed for 20 years - nearly that long ago, I held in my hand a single DVD with thirty full-length movies on it - all compressed losslessly using such an codec on a laptop. I actually accepted a job with the company (they even sent tickets for the flight out to Seattle for my first day on Monday) before calling me on Friday afternoon to tell me that the company had been acquired by a government-related entity and my role (being public-facing) was not needed. (Pissing me off because I'd turned down another good offer to take theirs!) It's the only time I've ever even heard of getting laid off before you start. The company vanished from the face of the earth that week...
With that kind of tech they can displace all the “media moguls”, combined. Realistically though, they’re probably talking about average-to-low-quality 480p rips fit for 90s TVs.
> I held in my hand a single DVD with thirty full-length movies on it
But at what resolution, fps, color space ? Storing the same gray scale image over and over again, as in most old security camera footage, takes up very little space.
Decoding the “changes” can be dependent on the “changes” in a previous frame, notably that the prediction for motion vectors can come from previous frames’ motion vectors. Which I frames obviously don’t have.
Besides that the only way to losslessly re-encode frames is to use lossless encoding, which would easily be a 50-100x size bloat.
It would be lossless for the vast majority of the video, only the cut point would be lossy. I'm sure that is ideal for most people. Sounds like it's in progress.
The problem with that is that the skipped data will still be present and therefore easy to recover if you know what you're looking for. That may "leak" seconds worth of video (and audio) the user may have thought was removed. And those seconds may contain something sensitive, e.g. a pan over some confidential information on some paper or screen, or genitals, or whatever.
That's not "a problem with ffmpeg-based editors"; that's the only way to do it lossless.
Some containers such as Matroska are able to store an offset (and ffmpeg does that), so it starts playing from exact wanted position even though the actual stream contains data since the last keyframe. Some players ignore that though.
Depending on the encoder the GOP size / keyframe interval can be more or less unbounded as well. Typically you'd only have a few seconds per, but for example CCTV cameras are happy to produce minute-long GOPs. Seeking backwards in a video player tends to not work so well at that point, and most NLEs are significantly unhappy with such a file.
I wonder though if this could be solved with edit lists, supported e.g. by ISO BMFF. Not all players support them completely, though, for example I believe mpv only supports one edit, so I guess that's not useful for general purpose use..
You can't do that at all in long-GOP formats without re-encoding.
What happens is that every so often it sends a complete image - the intra frame - and then sends differences to show what changes from frame to frame. This is a complete and utter pain in the tits to edit with, so most people transcode to an intraframe codec like DNxHR or ProRes although there's absolutely nothing wrong with MJPEG or MPEG2 intra-only.
If you don't re-encode, you're limited to cutting at an intra frame because that's where it starts drawing from. If you don't you get all this weird "ghost trail" stuff happening.
If you click on the words "always be free", you will be taken to the GitHub project, from there click on the release in the right column, and then download it for your platform. The store links are for the "donation" purchase process.
LosslessCut is a magnificent tool.
I use it as the final step for my lecture recordings, which have been disassembled with ffmpeg, edited with Audacity, encoded with Handbrake, and finally reassembled using ffmpeg. LosslessCut combines the speed of ffmpeg with a quick and pleasingly minimal UI.
Sort of related - anyone know of an open source tool that can repair video streams that get broken during the download process (using youtube-dl) due to internet interruption.
Everything I've researched into this says that it cannot be done because there is final metadata that gets added at the end of the stream that is missing. This does not seem right - if you have already download frames of video there should be some way to recreate any metadata instead of being left with an unplayable broken mpg file.
The internet has many shady third party paid products that claim to do this but I don't trust them.
For AAC/M4A there's also https://github.com/nu774/m4acut, which can split MPEG-4 based AAC audio and preserves gapless playback. (While mp3DirectCut can read AAC in MPEG-4 containers, it only ever spits back out the raw AAC stream, which lacks the necessary tagging for gapless playback.)
I've found handy for splitting up the occasional concert regording off Youtube back into individual tracks, and things like that…
LosslessCut is great, but I needed something quick when I cleaned up old GoPro videos. Just open an mp4/mov in QuickTime Player, trim it and save under a new name. It will create a lossless cut. If you need several from same video, you would need to repeat the process on the original file.
(unfortunately, the trimmed video won't get the same metadata, so I also needed to use exiftool -TagsFromFile oldvid.mp4 -all:all newvid.mp4 )
I sure hope this does something Virtualdub can't / anything better than Virtualdub, my current preferred lossless video / audio editing Swiss army knife.
Can anyone confirm whether that is the case?
BTW downloads that don't require approaching Lord Appstore cap in hand can be found here:
I'm not about the 80 MB... but I'm rather concerned by the proliferation of Electron-based applications. They use way too much system resources. Like Chrome does... but for a browser (which is kind-of a "heavy" application) I still understand.
Statically linked FFMPEG executable is about 80 MB. As there is no need to ship entire FFMPEG when only lossless operations are to be used, I'm sure it can be reduced below 10 MB.
Looks like it has better meta-data support and you can mark multiple segments of a video, re-arrange and then do a stream copy to a new file. I've been using VirtualDub for decades (maybe the wrong way) but I think doing the same would have required steam-copying the segments to new files and then appending them together. Not a fan of the interface based on the screenshot but I think it's worth giving it a try.
LosslessCut looks awesome! I also created a lossless video trimming tool a couple of months ago: https://videotrim.app
LosslessCut seems to be more featureful but mine works in the browser without having to install it. It also has the same limitations since cutting times are rounded to the closest keyframes, but this way there's no need to re-encode anything.
FFmpeg also works of course (it's what LosslessCut uses internally), but in my experience I've occasionally run into files where FFMpeg doesn't properly cut on keyframes and I end up with a few seconds of no image at the start of the video. No such problems with mkvmerge, and the API is much simpler.
Never realised the site was so bad... It's a fantastic tool, but it'd be nice if the site opened with why you'd want to use it, and what it can do, rather than jumping straight into user testimonials from people who mean nothing to you, followed by a complete nonsense "them vs us" image set. In what universe does a reencode-on-save using any of the dozens of normal tools that people use turn a normal video file into a 7 bit palette gif?
LosslessCut works great if the keyframes of the video are not too far apart and if you already know where you want to cut. I posted something similar (a web app for automatic silence removal) a few months ago in Show HN: https://www.savvycut.com.
We also use keyframe based cutting for lossless cuts and a smart-cut mode that only re-encodes parts around keyframes (at least for h264 and vp8 codecs). I see that you also experiment with a similar smart-cut feature: https://github.com/mifi/lossless-cut/issues/126.
That seems to work quite well if you re-encode with the same parameters as the original but I guess there are a lot of edge cases.
It's rare that I come across software with such thoughtfully designed UI and great UX where everything just works™, including things you didn't know you needed. I felt like I immediately knew where everything was (even without toggling the simplified mode). I use LosslessCut from time to time to make small looping videos for my blog, and after my first use I immediately went to donate to the developer. I remember even writing some detailed paragraphs about why it's so good in the PayPal message, but something went wrong and PayPal lost it, so it was a silent donation in the end. Definitely in my global top 5.
HN saves the day again. This is exactly what I needed to edit some videos on a deadline today. Thanks for posting it! I usually use ffmpeg from command line to trim a video but needed to do some more complex edits that LosslessCut makes easy.
If lossless, why doesn't LosslessCut export the original media codec and wrapper? Seems to have its own unique file format.
What I want is a 64-bit version of Quicktime 7 Pro. Q7P has interface issues (handles are too small, and it is clumsy to get to specific time index), but otherwise it is a Swiss Army Knife of clipping. Apple's 64-bit Quicktime X is absolutely worthless (I don't want to re-encode, and I don't want to share anything!).
Don't do this. Place both ss and t before the input -i.
As output options, ss waits till the first KF after the given value, it's not a seek. With a t of 2, that may very well result in an empty video stream.
Of course (pretty sure LosslessCut using ffmpeg under the covers). But this is probably one of those instances where having a GUI comes in handy. You can quickly scrub the video for the exact point you want, see where the closest I frame is (read: the place where your cut is going to start), create multiple cut segments, etc.
For simple cases where you just cut a single clip out of a longer file, I find CLI to be faster. For more complex stuff like joining several clips together or manipulating multiple files, GUI is usually the better option indeed.
Been using this for a while to cut down gameplay footage I want to share with friends. It works well but I wish they implemented a simple way to combine multiple audio streams into one stream for upload to youtube/elsewhere.
From what I can tell, FFMPEG does support actions like that. Perhaps it's not "lossless enough" for the app author.
This looks nice. I've been cutting all the videos I make for my skateboarding "wordle" site by using ffmpeg and its scene detection.
Some times the scene detection isn't perfect and I have to shave off a few milliseconds to get the clip just right. Also scene detection doesn't do well with fade transitions or with night time skate clips where there's a camera with a flash.
I also learned how to put clips back together with ffmpeg too. I've definitely been doing this the hard way, but it's been fun learning ffmpeg and its crazy incantations.
For casual video audio editing, I usually use Avidemux. Its Copy mode is similar in cutting out portions of the video without the lengthy re-encoding process. LosslessCut looks nice. I’ll give it a try.
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)
LosslessCut does work with HEVC, but the GUI doesn't support playing them so it generates a low-res H.264 video to use as a stand-in for previewing and then does the actual cuts on the real file.
I mostly use it for cutting up clips from an older GoPro so I don't run in to this often but I did borrow a Hero9 recently and it worked fine, it just was a bit less streamlined.
This project has been my go-to example of the absurdity of Electron since its inception. This is a thin wrapper around ffmpeg, which does all of the real work here and is a much more powerful and versatile tool. Why does this ship an entire web browser? Why does this even exist? The world may never know.
> This is a thin wrapper around ffmpeg, which does all of the real work here and is a much more powerful and versatile tool. Why does this ship an entire web browser? Why does this even exist? The world may never know.
You answered "Why does this even exist?" yourself, it's a thin wrapper around ffmpeg. It provides a reasonably usable and friendly GUI to perform the kind of basic cuts a lot of people want to do with their video.
When I have two hours of GoPro footage I want to chop up in to a quick and dirty highlight reel, which one do you think I'm going to choose?
1. Fire up my favorite video player, scrub through every file noting the start and end times of every segment, turn each of those segment times in to a ffmpeg command line, and throw all those in a script.
2. Fire up LosslessCut, scrub through every video clicking "start segment" and "end segment" as appropriate, click "Export"
It ships a whole web browser because unfortunately that's the easiest way to make a cross platform GUI app these days, and they get video playback support "for free" (though this does result in some limitations with codecs other than H.264). Yes it's heavier than it could be, but I'm editing video here, I don't really care about megabytes of hard disk space or RAM.
There's nothing else like it as far as I'm aware. AviDemux only does one cut at a time, VirtualDub doesn't even run on non-Windows platforms.
It’s odd, because you’re framing these questions rhetorically, but you might be well served by asking them earnestly.
There are plenty of parallel comments on this page that describe why people like LosslessCut. It exists because its authors saw a niche they wanted to fill, and the userbase suggests they aren’t alone. How strange to look at that and call it “absurd”.
It's lovely you can remember or have the time to look up the right arguments in ffmpeg, others of us use GUIs for this, both ways of using the computer are valid.
I'll keep an eye on this. I have a very technically interesting project soon which will require quite a lot of cuts; my thought was just "re-encode everything as I-frames" (all of the source material consists of clips under four minutes long). This might help.
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
As long as the files are the same codec and resolution and stuff, it works just fine (I just used this earlier today to combine 20 short instagram stories into one video).
Merging works great. Drag multiple files to the main window. A dialog pops up to allow you to select the order of the files. Then merge and a new merged file is created.
Just tried this on a screen recording I made, really simple way to cut out boring bits e.g loading/waiting times, mousing etc. Great, I'll use this again!
I've a semi-related question. What's your workflow for matching torrented videos with subtitles that have been provided in the same torrent? Often the directory structure is
Some.video.mkv
Subtitles/Some.video/English.0.srt
and my players of choice (mpv and MPC) are unable to automatically make the match.
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 :)
-Mikael Author of LosslessCut