Looks like an open source competitor to this absolutely magical app I used to use back in my Windows media PC days, way back when, which was called VideoReDo.
(Unfortunately, VideoReDo was proprietary, produced by an indie developer, and that indie developer recently passed away.)
For those who don't really get what "lossless" video editing is all about, consider that most video editing software always involves these stages: importing video/audio "clips", storing the video/audio timelines in some sort of "app native" format (e.g. Pitivi, Premiere, Final Cut), and then exporting the completed video in one or more output formats (e.g. MP4, MOV), re-encoding the entire thing from scratch.
This means that if your only goal is to, say, cut 30-90 seconds out of a 1-hour video, you're still going to have to re-encode the entire 1-hour video. That also means if your re-encoding system isn't a match for however the original video was encoded, you'll make some changes you didn't intend via the re-encoding (e.g. video or audio quality changes).
With this "lossless" style of editor, however, it'll figure out a way to "snip out" the 30-90 seconds (you can think about this being "at the byte level") without re-encoding the entire thing.
Avidemux is also great, but I've had some issues with running it under Wayland. LosslessCut works excellent on every platform I've tried with no issues. It also has a much better UI for cutting multiple segments, IMO.
Well yeah, LosslessCut is an Electron app, so it's actually Chrome pretending to be a video editor, and Chrome is well tested on many platforms. And the main downside of an Electron app (memory usage) is less painful as in other cases (like the Slack "standalone" client that's supposed to be permanently running in the background ), so why not...
Avidemux can indeed perform lossless cuts as long as you select "copy" as the video and audio output codecs.
White it has a few odd UI characteristice, it's free, it's actively developed, and I like it a lot. Not throwing shade at LosslessCut; it's fine. But I do prefer Avidemux.
For those wondering how it works: compressed video streams can be arbitrarily interrupted in between frames by any compatible start point from another video frame. Decoding and reencoding is only necessary to change the contents of those frames or restructure the videostream to make it compatible.
Most video formats are a stream of delta-encoded frames that must be decoded and displayed in-order. If you want to go back even a single frame, you have to restart decoding from the beginning, and if one frame is damaged, you lose picture. So encoders have to regularly restart the video stream by inserting keyframes. And it's valid to insert keyframes basically anywhere into a foreign video stream, at least for the same codec and resolution.
Proper NLEs don't do this AFAIK - most of the cuts you do with them aren't approximatable with simple GOP[0] cutting tricks, and most people aren't editing video clips that are encoded to their final delivery format. Hell, at the professional level a lot of people record in ProRes, which is deliberately not delta-encoded[1], because delta encoding is actually really bad for nonlinear video editing.
[0] Group of Pictures - a keyframe plus all the delta-encoded frames up to the next keyframe.
Basically, lossy compression codecs store groups of frames, or groups of samples. You just can't "cut" at any frame or sample that you want. If you do, you have to re-encode the whole thing.
If you want to understand why, the "delta encoded" thing means that only the difference between frames (or samples) is stored. It usually takes less bits to store the difference between frames, or samples, than it does to store each frame / sample separately.
The reason why "groups" exist is so that you can jump around in a video / audio file. The beginning of each group stores a complete frame / sample. (This also helps if the file is corrupted.)
As long as you cut a compressed audio / video file at the groups / jumps, you can cut it losslessly.
---
(Note: Techniques like companding can use less bits when each frame / sample are stored separately. Some people don't even call this lossless. The technique is basically a digital version of the old "Dolby B" button on tape decks from the 1980s and 1990s.)
Some container formats, such as ISO Base Media File Format aka "mpeg4", have features such as edit lists. With edit lists you can have original video in the bitstream, organized in GoPs as you say, but then the final video rendered in the player gets to choose which frames to play from that material.
This allows cutting at completely arbitrary places (I'm 99% sure that this can also be at a higher time resolution than the original data), with the cost that the original (unplayed) data remains in the file.
However, some players may have incomplete support for them. For example I believe FFmpeg only supports edit lists used at the beginning of the video, which is commonly used to align video and audio properly.
> As long as you cut a compressed audio / video file at the groups / jumps, you can cut it losslessly.
If you had a video with keyframes 'd'K and delta frames 'd' like
0 1 |<-->| 2
KdddddddddddKdddddddddddKddddddddddd
and you wanted to cut out the indicated frames, could you create a new keyframe from the keyframe marked '1' + the two following delta frames, and then another new keyframe from K{1}dddddddd? Something like
Or I guess if you're creating new frames that weren't in the original, could you just rewrite all the deltas in between K1 and K2 such that those 5 frames aren't there?
This means that if your only goal is to, say, cut 30-90 seconds out of a 1-hour video, you're still going to have to re-encode the entire 1-hour video
If you’re cutting 1 minute then you are encoding one minute. You might need to decode more than one minute of the source video but it’s rare that it would be the full 1 hour to decode
When I say "cut out" I mean "remove that small segment from the larger video, resulting in the large video modified such that the short section is skipped."
Think of removing a commercial break from a broadcast clip or removing a "waiting for speaker" prelude from a 1 hour recorded lecture/speech.
MPEG Streamclip is great for precise lossless cuts as well as lossless merging; still run it in a Tiger UTM VM on Apple silicon: https://tinyapps.org/docs/tiger-on-m1.html .
When I read lossless, I immediately thought about the editing of the real lossless formats like ProRes, MJPEG2000, HuffYUV, etc. But what this ultimately does it remuxes the original container in a new one without touching the elementary stream (no reencoding).
It's no wonder that it uses FFMpeg to do the heavy-lifting, but I think it's worthwhile for the community to understand how this process ultimately works.
In a nutshell, every single modern video format you know about - mp4, mov, avi, ts, etc - is ultimately the extension of the container that could contain multiple video and audio tracks. The tracks are called Elementary Streams (ES) and they are separately encoded using appropriate codecs such as H264/AVC, H265/HEVC, AAC, etc. Then during the process called "muxing" they are put together in a container and each sample/frame is timestamped, so the ESes can be in sync.
Now, since the ES is encoded, you don't get frame-level accuracy when seeking for example, because the ES is compressed and the only fully decodable frame is an I-Frame. Then every subsequent frame (P, or B) is decoded based on the information from the IFrame. This sequence of IPPBPPB... is called GOP (Group of Pictures).
The cool part is that you could glean the type of the frame, even though it's encoded by looking into NAL units (Network Abstraction Layer), which have specific headers that identify each frame type or picture slice. For example for H264 IFrame the frame-type byte is like 0x07, while the header is 0x000001.
Putting all this together, you could look into the ES bitstream and detect GOP boundaries without decoding the stream. The challenge here is of course that you can't just cut in the middle of the GOP, but the solution for that is to either be ok with some <1sec accuracy, or just decode the entire GOP which is usually 30 frames and insert an IFrame (fully decoded frame can be turned into an IFrame) in the resulting output.
That way all you do is literally super fast bit manipulation and copy from one container into another. That's why this is such an efficient process if all you care about is cutting the original video into segments.
FWIW, below is a bash script I've used for generating ffmpeg cuts, based off of a pretty useful stackoverflow suggestion. Input to the script is a file consisting of start/end times in seconds, one set per line. If the video has no sound, it looks pretty much the same, just without the atrim/outa parts.
C=0;echo -n "-filter_complex '";
while read f;do
A=($f);echo -n "[0:v]trim=start=${A[0]}:end=${A[1]},setpts=PTS-STARTPTS[${C}v];[0:a]atrim=start=${A[0]}:end=${A[1]},asetpts=PTS-STARTPTS[${C}a];";C=$((C+1));
done <$1
for i in `seq 0 $((C-1))`;do echo -n "[${i}v][${i}a]";done
echo -n "concat=n=$((C)):v=1:a=1[outv][outa]'"
echo ' -map "[outv]" -map "[outa]"'
Belated reply. You can't use copy with filter complex which does a decode, however, like the people in the stackoverflow thread I got the suggestion from, I was getting inconsistent audio/video clipping/syncing without a full decode. Personally I don't see a significant quality hit if you're careful with the encode
To preempt the complaints about this being a 100MB+ Electron app, AVIDemux is a native app which does much the same thing if that works better for you.
I just found this last week, and it was tremendously useful. I had filmed an entire dive competition with a small poolside camera, and wanted to cut it up into clips of individual dives. LosslessCut let me play it back as fast as I wanted (a little over 300% speed was the fastest I could use to listen for the gaps between divers), tap 'B' every time the scores were announced for a dive, then click export after I'd done that for all the dives. It took me less than an hour to split a 3 hour competition into nicely labeled clips I could share with each diver and their coach.
I'm a big fan of lossless cut and use it almost every day. Typical use case for me is to trim or edit screen recordings. Since it's lossless, the saving of the edited videos is almost instantaneous.
It's basically just a GUI for ffmpeg.
I then use Permute if I need to recompress, or Davinci Resolve if I need to add effects or lossy edits.
What does it give you that something like Handbrake doesn’t (or even just directly calling ffmpeg)? Seems like a paid app. I don’t mind paying for software if it’s really better than other existing free options.
I use handbreak all the time to re-encode to be smaller. A screen-capture video is usually like 1/10th the size after re-encoding so I can upload it to a bug report system.
I also find that lots of tools artists are using generate multi-gig files that compress with the default settings in handbreak to 1/10th the size, and at least personally, I can't tell the difference at a glance. I sometimes think the size is being used as a proxy for "quality" so the artist and some of their patrons think larger file size = better
I use Handbrake to encode piano practice sessions to be sent to the piano teacher. Since the teacher cares more about audio quality I configure Handbrake to use the original audio stream. I dial down the video quality from the default 24 or so to 28 for lower quality. Artifacts are somewhat visible but acceptable. The multi-gig files from the camera become small enough to be emailed directly.
However while Handbrake supports this use case perfectly I don't think there's a way to re-encode the audio but keeping the video. I guess that's when this submission comes handy.
Yep! That's the link for Permute. I have it through the SetApp bundle, but it's the same.
I use LosslessCut to trim and then Permute to speed up or crop. I almost always speed up my screen recording by 20% to make them feel higher energy and more engaging.
I wonder if its possible to losslessly download & cut video from remote server. Currently i'm using a bash script with ffmpeg i've got from stackoverflow to download a small portion of video from the likes of YouTube. But currently, it has to re-encode the video on the fly while downloading. For now, I assume it's impossible to losslessly download & cut this kind of video because we don't have the information about the video locally (keyframes, etc). But I like to be proven wrong!
I've used this before with yt-dlp to extract some video (313 is only the 4k video stream but I assume it would work with videos that have audio streams as well):
I just found out about this app recently and love it. Hard to believe I ever fired up a full blender instance and video project to cut clips, much less regularly.
Given the OS'iness I'm sure the information is available but would anyone be interested in linking the code containing the interesting ffmpeg args or does the project have documentation bridging the gap between ffmpeg and lossless cutting technique?
I wish there was a way to crop lossless and with deleting the unused data (not just metadata/bitstream filter). I feel like it must be technically possible with some kind of partial re-encode.
Codec standards are defined for decoder compatibility. So no matter what encoder produces a stream, a “standard” decoder can display it. But encoders are free to do whatever they want within those bounds. Each encoder may choose to make trade offs that are incompatible with each other. So stitching often requires using the same encoder. Getting everyone to agree on a common sequence header is just not going to happen. It would need to be built into the codec specification. And no modern codec has cross implementation stitching as a design goal. It would be possible to make an implementation that parsed an existing stream and created a stitchable output, but there is no financial incentive to create that encoder.
EDIT. Some decoders can be reinitialized by adding parameters in band. But this is technically illegal in some formats (like mp4) but it may "just work" in some playback environments
In general, this is only going to be possible if you crop a whole number of macroblocks. Worse, codecs do intra-prediction so you can't delete macroblocks which are used for other blocks you want to keep.
Used this a bit. Great free tool. Not always precise on cuts depending on the available keyframing, and takes some trial and error iteration, but definite a quick way to not have to re-encode the whole file.
You should try the "Smart cuts" feature (which is labelled experimental). On common formats/containers (like videos from YouTube) it works really well.
Basically it will attempt a precise cut and if it doesn't coincide with a keyframe it will reencode both ends on each side of the cut and the nearest keyframes.
It is generally very small segments to reencode so it is pretty quick and the quality of these is nearly lossless too so the cut feels invisible.
The only issue is if your segments are really short (under a second) it will generally fail... but chances are keyframe cuts in this case don't work well either.
For those who capture cable or antenna broadcast TV programs or use HDMI capture devices like the Hauppauge HD-PVR, MythTV has had frame-exact editing of TS recordings for many years.
I don't see anything like LosslessCut's "smart cut" feature, which re-encodes just the part between the cut point and next keyframe. Unfortunately, smart cut doesn't appear to work reliably. https://github.com/mifi/lossless-cut/issues/126
It does not compare, because they do not do the same thing. Handbrake is a video transcoder. LosslessCut cuts up videos specifically without transcoding.
So, not in reply to you, but the parent. It then seems entirely accurate to say they are not comparable.
Ffmpeg as workhorse is common. But what handbrake and losslesscut are in terms of (mostly) UI, they solve different problems, of which there isn't much to compare.
(Unfortunately, VideoReDo was proprietary, produced by an indie developer, and that indie developer recently passed away.)
For those who don't really get what "lossless" video editing is all about, consider that most video editing software always involves these stages: importing video/audio "clips", storing the video/audio timelines in some sort of "app native" format (e.g. Pitivi, Premiere, Final Cut), and then exporting the completed video in one or more output formats (e.g. MP4, MOV), re-encoding the entire thing from scratch.
This means that if your only goal is to, say, cut 30-90 seconds out of a 1-hour video, you're still going to have to re-encode the entire 1-hour video. That also means if your re-encoding system isn't a match for however the original video was encoded, you'll make some changes you didn't intend via the re-encoding (e.g. video or audio quality changes).
With this "lossless" style of editor, however, it'll figure out a way to "snip out" the 30-90 seconds (you can think about this being "at the byte level") without re-encoding the entire thing.