I was hired recently to author a set of DVDs (yes, I know!), discovered there's almost no commercial software still available outside of Scenarist and TMPGEnc, and tried a dozen modern projects while putting together a FOSS workflow, just in case I couldn't the conjure CDs, licenses, and keys for software I hadn't needed in a decade+.
vidcutter ultimately didn't help in this process. I built it from source and then tried the flatpak, but for all of its beauty, it hung or crashed when importing common but dated formats and containers, handling more than a few clips, and didn't allow precise jogging for splitting (when it didn't hang or crash). It's good for trimming up a smartphone video, but it's not on par with an NLE.
I ended up giving up and scripting out most of the project in ffmpeg and dvdauthor. If you know how to use core utilities, it's such an exercise in tedium struggling against underdeveloped front ends.
FWIW, LosslessCut works similarly to Vidcutter except it’s functionality is flawless (within limitations) in my experience. Def worth a look if you run into a similar need in the future.
+1
I love LosslessCut. Am using it for many months now and it has never let me down. It's a very polished piece of software which is in active developement!
I've also noticed playback of DVDs is terrible these days too. Long ago I ripped my DVD collection to iso files so I could preserve the full experience of the menus, etc. But almost nothing these days supports DVD iso playback and menus, not even VLC! The only software I can get to work to play them is Kodi. It's wild how much DVD software has disappeared, I don't remember it being this bad 20 years ago.
Same here. I've once `dd`'d a VideoCD into a `*.iso` file and there's seemingly no app that can read it now. VLC only detects the video stream and plays whatever frames it can decode, but since it's mixed with CD layout and filesystem stuff, it's rather garbled.
I can't mount the file and also can't find any software that can make sense out of the raw CD sectors. Very strange.
And it gives you nice drag/drop/seek/preview type stuff.
That said, since I've been using an AI assisted terminal (warp.dev currently) my use of GUI wrappers for different tools has faded quite a bit. I like being able to "Clip 0:10 through 0:30 of file.mp4 and turn it into a web optimized gif", and this NLP workflow works as a "wrapper" for almost any CLI. It's a nice interface without the loss of any functionality.
You said electron sucked. That might be, but vidcutter, the subject of this thread, isn't proving your point. Just goes to show that who writes the code has more impact than the tech stack when it comes to such tools.
I don't know if all the numbers are accurate but it's true that vidcutter does weird things. I think it extracts ffmpeg to the temp directory on every start for whatever reason (it's not like it's a portable executable, it requires installation so why not extract it then?).
I can't explain why it uses more memory or how they managed to make it look alien despite using QT (so much for accusing electron of not looking native).
They are a direct response to the GP post's offhand quip about Electron. GP found the difference relevant, and I believe you're GP, but I am confused now given the change in interest.
My point is that startup time may not have anything to do with the GUI. It is not a good metric. I could write both an electron and pyQT app that takes minutes to start if it has other shit it needs to be doing. I haven't used electron in years but pyQT apps start up instantly, therefore this app must be doing something else.
If the two apps were programmed identically then you might have a comparison.
It uses PyQt. I'm not sure I'd put much money on it being faster than an Electron app. The only other PyQt app I have used is Cura and that is ridiculously slow. Takes like a minute to start up and you can watch it loading the controls when there are a lot of them.
Last time I tried VidCutter it was incredibly slow. So slow that it seemed completely glitched sometimes. It was such an incredibly slow and laggy chore to do anything in the app I could not keep using it.
Perhaps I'm missing something, but I only care about the functionality and not whether the button should have round edges or the background having the right shade of grey. The consistent "feel" is nice to have (cough winform/wpf/uwp cough), but I would take "web-ish" applications over no application/crappy native application anytime (especially with Linux)
Native's not crappy, it's the best and most supported. We just happen to be in love with the web aesthetic and cross-platform. And that decisionmaking is mostly made by MBAs who see tech as a means to a financial end and not for the joy of writing good code
Web shit is fucking ugly, it eschews platform native conventions, and it just feels cheap.
But when I load up a winforms-esque app with toolbars and a statusbar and all the nice accoutrements we're accustomed too behaving in the way we are accustomed to... now I feel like I'm going to get shit done.
Literally the only electron app that feels serious is VSCode and the amount of optimizing MS has had to do has cut into seven figures
n.b. just because CPython exists doesn't mean Python is native.
n.b. native vs. web is colloquially a discussion from 00s macOS and 10s mobile about fidelity to the platform's standard UI toolkit.
n.b. when people shit on Electron its because of RAM use and lack of fidelity to the platform toolkit, and the waste of have a full JS engine compiled into an app, ideally they'd all use some base WebView from the system instead of Chromium
They are the overwhelming majority of users, whether you like it or not. This is the free market at work.
There isn't even a valid concern here to complain about. Electron apps are cross-platform out of the box. The tradeoff for open access and low-cost development is more RAM. Turns out, developers are more than happy to make that deal.
> They are the overwhelming majority of users, whether you like it or not.
Yes, and? They're not here. This is not where they hang out. The point isn't why someone who doesn't even know the difference must not run bloatware, but rather why people who do know better frown on bloatware.
> This is the free market at work.
Anything but. The bit that's missing is transparency. As in, both the buyer and the seller know everything there is to know about the product in question and other options available.
> Turns out, developers are more than happy to make that deal.
Yes, developers. Not users, who aren't actually keen on upgrading machines to achieve the same stuff, but have been mislead to think this is how it has to be -- because from personal computer and user empowerment, we got to corporate empowerment. And the same way (too many) corporations outsource costs to society and their employees, we now consider doing the same as very professional. You called it "low-cost development", as if the externalized costs simply don't exist. It's just a few seconds here, a few dollars there, multiplied over thousands or millions or actually-who-even-cares instances.
> Electron apps are cross-platform out of the box
So are apps that achieve the same or more with way, way less. When you talk about the box the users take them out of, that is. When it comes to developers who can "just use what they already know", sure, for them Electron works "out of the box", while other things "require assembly". Okay, so what? Isn't that what coding is?
Imagine architects building shittier bridges that use more resources, because that's easier and quicker. That's perfectly fine for individual architects, but as a trend it's just regression.
> The point isn't why someone who doesn't even know the difference must not run bloatware, but rather why people who do know better frown on bloatware.
Also, computing industry seems to be unique in that tools for professionals and toys for general audience are being developed to the lowest common denominator of the latter. This is what's changed in the past 1.5 decade. Can you imagine surgeons or civil engineers doing their jobs using tools designed to take advantage of Joe Always Half-Drunk and Jane the Long Retired Grandma and the likes?
(This is partially where the idea that "customer doesn't want a drill, they want a hole in a wall" leads people astray.)
> Imagine architects building shittier bridges that use more resources, because that's easier and quicker. That's perfectly fine for individual architects, but as a trend it's just regression.
That is unfortunately happening everywhere, as the "cost function" driving optimization isn't global/general efficiency, but business efficiency. Initially these two are correlated, so any new industry tends to first develop in ways that cut down waste. But then it transitions to reducing costs to company, by generating more waste, just for someone else. Externalities seem to be a general problem for our civilization today.
As to your last paragraph, what really gets me is this:
However much you might save by cutting X corners, or how much you might make by selling someone something they don't need, etc. -- there are hundreds, thousands of companies you're dealing with that do the same to you, to people you love, your co-workers, employees and customers, probably making your life much worse than your own corner cutting can recoup. It might not even make business sense in the bigger picture, because instead of a small slice of something that is at least pie you get container ships full of saw dust or something.
I can't believe you're comparing developing desktop apps to surgery and civil engineering. The stakes here are zero. This is what open source software is all about: making apps accessible to more devs, and more users.
For most, yes. But for software where stakes are non-zero, for software where errors could kill people or cause billions of dollars of damage, the tooling is... exactly the same. For example, the infamous "Industry 4.0" and "Industrial IoT" buzz-phrases are, in big part, about your usual garden quality open source software - mostly webshit - orchestrating the actual control systems in factories and manufacturing plants. I shudder to think what "Industry 5.0" will look like.
You are making weird moral judgements about desktop app frameworks. There is nothing wrong with Electron, there is no "regression". There is a reason why you're losing this battle, and it's because for many devs developing small apps, Electron is easier. That's it.
What I really can't understand is how people get so heated about tech stack choices like this. We're not talking about civil engineering, we're talking about an ffmpeg wrapper. Electron is just a means to an end. If your alternatives were better at what devs and users cared about, they'd be more popular. Clearly that isn't the case.
You should be excited that frameworks like Electron allow more devs to make powerful tools accessible to the public so quickly. This is what open source is all about!
Not according to your standards, and that's fine, for your standards.
> There is a reason why you're losing this battle, and it's because for many devs developing small apps, Electron is easier. That's it.
What "battle"? Decent software still is being made, I'm still using it. But if someone is presented to the world, saying why I would never dream of using it is fair, no?
Why should I care what's easier for some "rando dev"? I'm the person who would use their resources to run it, while not using things that are faster and don't introduce even half a second of "waiting" (who does that?) when starting them, doing the thing, quitting them; even when I already have dozens of similarly well made programs running. So while someone else might say "oh this is great, because I don't know about Avidemux (or would rather wait 5 seconds just staring at nothing than spend 2 seconds hunting for the menu option)", I don't. Either you accept both types of reaction, or none.
> We're not talking about civil engineering, we're talking about an ffmpeg wrapper.
Exactly. Why again is that over 100MB big? Even making it in Love2D or something would be a million times more sane. And again, I'm not talking about civil engineering either, the alternatives I presented were "an Avidemux tutorial" which would be like 5 sentences and 3 screenshots, or Avidemux minus all the other stuff.
> If your alternatives were better at what devs and users cared about
My opinion of something isn't about what other people care about, in their state of what I'd describe as ignorance. And you aren't even saying what you care about, you are talking about "the average user", which is a complete waste of time. Bring even just one actual non-technical person in and let each of us make our points, let us show them the process of installing and using each respective software, and you'd have the start of an argument.
It's also not that everybody and their dog drives a SUV because that is sane. I don't care about what leads people to doing these things. I see the outcome, so whatever the root cause is, I see it as something to be improved, not accepted. If everything that anyone did was perfect by default and shouldn't be criticized, because that'd be a "weird moral judgement", why talk about anything?
> You should be excited that frameworks like Electron allow more devs to make powerful tools accessible to the public so quickly.
Why? Why can't you be excited that I can don't find them powerful, because they do 1% and take longer to do it, then sit there constantly taking up more space? After saying I am making "weird moral judgements", now you tell me what I should be excited for?
Because developers need to eat, this should not be hard to understand. It is cheaper and faster to build an Electron app and have it immediately work cross platform, than to build several native apps just to please some random internet purist.
And if that eating is already covered? To say nothing of QT, Avalonia, Uno, GTK, and others. Many of those manage to figure out cross-platform with native controls.
But no, we have to use electron because she can throw cheap oversaturated webdevs at the problem and call it a day.
Because it's easier. That's it. You can argue about "equivalent alternatives" until you're blue in the face, but you're wrong. It's just easier for many devs to use Electron than whatever you just spouted, and that's why it's more popular.
You are acting like Principal Skinner going "No, it is the children who are wrong." What I can't understand is, why do you care so much?
Why do you care about why I care so much? I have my reasons. I have outlined them. They are much better than anyone else's reasons, by my standard, and I am going to stick to them.
It's even easier to make a 3 screenshot tutorial to explain how to do it in Avidemux. Slightly more work would be to fork Avidemux and rip out everything but the lossless cutting. But then you'd at least have a tool worth calling it that.
It's not a one-way street, either. Even just putting a link in front of me is asking for my attention. I then read the description, which doesn't mention that it's giant and totally pointless if you use Avidemux, and have to click to the releases page to realize yes, it's another one of these that seem to quickly become the norm, and that I know won't be maintained in 5 years. But hey, I don't have anything better to do with my time, surely!
Does this do anything clever to enable actual frame perfect cutting, or is it just splitting on keyframes like avidemux or `ffmpeg -i input.mp4 -ss "START_TIME" -to "END_TIME" -c:v copy output.mp4`?
There's nothing "clever" you can do to losslessly cut outside the keyframe boundaries. Since reencoding is required, loss of quality for at least the cut GOP is a given.
I'm not sure about that, naively you could turn the entire cut GOP into i-frames couldn't you? I'm not super familiar with the nitty gritty of h264/h265 but intuitively I think you wouldn't even need to turn everything in the GOP into i-frames. You could trace out the inter-frame topology of the GOP and then replace only the "orphan" frames with i-frames, then the remaining p and b-frames would retain the necessary reference data for decoding.
I would love it if someone who knows more about this than I do would confirm/deny since this is something I've been curious about for a long time now. (Though I would also love a tool for near-lossless cutting that just re-encodes the cut GOP, please link such a thing if it exists)
"naively you could turn the entire cut GOP into i-frames couldn't you"
Yes, but then you'd have to render the result into a truly uncompressed format and it would have to stay in that format perpetually. If you wanted to deliver in another lossy format, you'd actually lose quality across the entire file instead of just the one GOP.
What I'm curious about is whether you can cut in the middle of GOPs, recompress the afflicted ones, and then concatenate the stream back together without recompressing all GOPs. If the file specifies a 12-frame GOP, cutting any GOPs is going to break that cadence. So can you have, say, a few thousand 12-frame GOPs... then an 8-frame GOP... then go back to 12-frame GOPs?
Yeah there's no issue there, most codecs support variable bitrates and variable iframe-pacing, and ffmpeg will happily concat such files. Also, there's no need to render into an "uncompressed format" the i-frames are still compressed, and even in the naive case you'd only need small number of i-frames because you only need to replace any orphans in the cut GOP after which you can just go back to normal decoding.
Indeed, was wondering whether there is a clever tool like that, i-frames is a simple idea, and then you could potentiality did something smarter like your tracing idea
What do you mean by motion detection? Scene changes?
But whatever you mean, the answer is probably VapourSynth. In fact, you can probably do whatever you are trying to do inside VapourSynth instead of ffmpeg.
Frame-accurate cut/concat in FFMPEG appears to me to be significantly less performant than it should be. I know that we need to re-encode to get frame-accuracy, but I've tried cut/concat say 300 clips from 3 source videos concat together for a total of 30 min. runtime as an experiment take days upon days (with no estimated time of completion), and swap memory usage exceeding 200GB. For something even somewhat complex, it's significantly faster to first export the frames to .png then reform the video, but I wish I didn't have to do that.
You could cut on any frame if your container and decoder supported decoding two tracks at once, then switching the active track. You could decode two tracks in parallel, each from the last keyframe, then switch whenever your want.
Scope-creep would of course require that to expand to include dissolves, transitions, etc until you've got a whole editor/compositor engine running just to playback a single composition.
However this would be quite possible with technologies like WebCodecs+WebGPU.
Decoding a single frame can be done a completely deterministic constant-time basis using hardware acceleration, common in embedded systems.
Decoding two consecutive frames would obviously require two such cycles, which the hardware may or may not be spec’d for. With three, four or n skipped frames, you would require (at least) n frames prebuffering, rendering and graphics memory to guarantee smooth playback.
I think it makes sense to differentiate between mastering formats and consumption formats.
One does not, after all, ship studio masters of albums or songs people listen to.
You don't even need to support multi-stream decoding, just fast seeking.
Matroska supports a feature like this where it can link together multiple segments, letting you do something like having one file for a repeated opening sequence in a TV series.
E.g. MPEG4 videos are usually made of I-frames (full frames), P-frames (predictions based on older images) and B-frames (predictions based on older and future pictures), and from these Group Of Pictures are made, which always start with an I-frame.
You cannot make frame-precise cuts within this sequence unless you wish to carry on the frames that won't be visible (and I don't think anyone tries to do these cuts by keeping some invisible frames), so you only get to make such edits that always include the first I-frame of the sequence.
Therefore if you want to make completely lossless edits your editing precision is lost. For frame-precise editing one usually ends up re-encoding the stream.
Of course, you could only re-encode only the GoPs that get broken while keeping the rest intact, and I guess this would be better and a lot faster than re-encoding everything. I don't know if any application tries to do this. But that is also a bit troublesome, as you'd like to use the same encoding parameters—and maybe the same encoder—as the other frames, to not have quality differences between the edits and original.
>Of course, you could only re-encode only the GoPs that get broken while keeping the rest intact, and I guess this would be better and a lot faster than re-encoding everything. I don't know if any application tries to do this.
LosslessCut does have experimental support for this partial re-encode called "smart cut" [1]. Since it's using ffmpeg internally, the challenge become how to instruct ffmpeg to do this[2]?
> It's far too fast to be re-encoding the whole video and is too precise to be cutting at the nearest keyframe.
Correct! For example, if you trim the end of a video in the middle of a GOP, it includes the entire GOP as is, but only plays up to the point where you trimmed.
Which is a very bad solution! Imagine cutting a video to remove some very privacy sensitive material, and some of those frames still ending up in the file, just not viewed because in theory the video file politely asks the player to skip until a later timestamp.
I'd for sure rather have tools that actually do what they claim to do. Using container metadata tricks feels to me as lazy and misleading to the user.
Smart Cutter[1] does frame-accurate edits without re-encoding. I'm not sure what black magic it uses, but it seems to work really well (tested on a couple of MPEG-TS IPTV streams).
I don't know if there are many cricket fans here, but I wondered if this is why - when watching the Ashes highlights of the cricket on BBC iPlayer or YouTube - the ball seems transparent as it runs over the grass.
Non-linear (i.e. normal) video (and audio) editing is lossless until you export the result. The neat thing that tools like this one, LosslessCut, Avidemux, etc. do is that they don't re-encode the video on save/export.
There are a few caveats, though. Examples: (1) You're limited to cuts-only edits. (2) Because the base unit of video encoded for distribution is a GOP¹, edits either have to happen on GOP boundaries (i.e. at a keyframe) or the apps have to re-encode the GOP.
...or anything else in the readme describing the program in any way or form. The title of this post has more information about the program than the whole readme.
Fun fact: The history of lossless editing goes back to the dawn of digital video on personal computers. For example, QuickTime Movies¹ have always been based on an EDL² model. Only when you "export" (vs. "save") is the content re-encoded.
