LosslessCut: The Swiss army knife of lossless video/audio editing(github.com)
github.com
LosslessCut: The Swiss army knife of lossless video/audio editing
https://github.com/mifi/lossless-cut
80 comments
Yes! Software that decodes, then re-encode naively/lazily is essentially doing double lossy encoding.
Reminds me of the early MP3 days, when people would download 96kbps files, then reencode to 320mbps to 'improve the quality'.
Reminds me of the early MP3 days, when people would download 96kbps files, then reencode to 320mbps to 'improve the quality'.
Nah we would download 128kbs files, and then reencode them as 16kbps to octuple the number we could fit on our Diamond Rio.
I don't think I ever got below 64kps in my own testing before the audio quality fell apart.
I was using a Palm PDA, so I found a player that supported ogg. That allowed me to push to 48kps (or maybe even 32kps) with "acceptable" quality.
I was using a Palm PDA, so I found a player that supported ogg. That allowed me to push to 48kps (or maybe even 32kps) with "acceptable" quality.
Ah the teenage angst flareup if our device cant support variable bit rate encoding.
In a former life as a printer I did once have a customer print out a 72dpi image and scan the printout at 300dpi, to increase its resolution.
Lol I did all kinds of nonsense like that. I got Adobe Premiere in 8th grade and had no clue what I was doing.
320mbps sounds like a lot :)
Oops, obviously meant kbps there.
Though using the same logic described, just imagine the quality of 320mbps!
Though using the same logic described, just imagine the quality of 320mbps!
If we're being pedantic...
320 milli bits per second? 0.32bps. That's not that much.
320 milli bits per second? 0.32bps. That's not that much.
I also recall AviDemux being able to do lossless cuts.
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.
[deleted]
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.
https://www.avidemux.org/
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.
https://www.avidemux.org/
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.
[1] And has enormous size because of it
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.
[1] And has enormous size because of it
Maybe I can explain it differently?
---
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.)
---
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.
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
If you had a video with keyframes 'd'K and delta frames 'd' like
0 1 |<-->| 2
KdddddddddddKdddddddddddKddddddddddd
0 1 |<-->| 2
KdddddddddddKdddddddddddKddddddddddd
Kdd = keyframe "L"
Kdddddddd = keyframe "M"
KdddddddddddKdLMddKddddddddddd
0 1 |<-->| 2
KdddddddddddKdddddddddddKddddddddddd
KdddddddddddKddeeeKddddddddddd
You're speculating quite a bit about what the codecs support.
See https://news.ycombinator.com/item?id=40844633. Some container formats support metadata so you can cut without reencoding.
See https://news.ycombinator.com/item?id=40844633. Some container formats support metadata so you can cut without reencoding.
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
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.
Think of removing a commercial break from a broadcast clip or removing a "waiting for speaker" prelude from a 1 hour recorded lecture/speech.
He meant that rendering a clip with a short part of it elided takes about the same as the original encoding of the video did.
Mpegstreamclip used to do similar on macOS but is not compatible with modern Mac’s
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 .
Did not know you could do that!
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.
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.
Related:
LosslessCut: lossless video/audio editing - https://news.ycombinator.com/item?id=33969490 - Dec 2022 (153 comments)
Lossless-cut: The swiss army knife of lossless video/audio editing - https://news.ycombinator.com/item?id=24883030 - Oct 2020 (10 comments)
LosslessCut – Save space by quickly and losslessly trimming video files - https://news.ycombinator.com/item?id=22026412 - Jan 2020 (1 comment)
Show HN: LosslessCut – Cross-platform GUI tool for fast, lossless video cutting - https://news.ycombinator.com/item?id=12885585 - Nov 2016 (33 comments)
LosslessCut: lossless video/audio editing - https://news.ycombinator.com/item?id=33969490 - Dec 2022 (153 comments)
Lossless-cut: The swiss army knife of lossless video/audio editing - https://news.ycombinator.com/item?id=24883030 - Oct 2020 (10 comments)
LosslessCut – Save space by quickly and losslessly trimming video files - https://news.ycombinator.com/item?id=22026412 - Jan 2020 (1 comment)
Show HN: LosslessCut – Cross-platform GUI tool for fast, lossless video cutting - https://news.ycombinator.com/item?id=12885585 - Nov 2016 (33 comments)
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]"'Where's the -c copy or -c:v copy -c:a copy ?
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.
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.
Haven’t heard of Permute, but similarly I use LosslessCut and Davinci. Is it this one? https://software.charliemonroe.net/permute/
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.
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 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.
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 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):
ffmpeg -ss 5:40 -i $(yt-dlp -f 313 -g https://www.youtube.com/watch?v=3SykjY3GdMs) -acodec copy -vcodec copy -t 20 waterdrop_mountainlake.mkvI 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.
[deleted]
Also useful for archiving large video files to DVD-R, just cut into 4Gbyte chunks and write to a few discs.
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?
Reminds me of VirtualDub from the good old days :-)
How does it work if you want to cut at a B frame?
Generally it does not work, and snaps to the nearest I-frame. There are ugly hacks to cut on P (and maybe B) frames, but they don't work as well.
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
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.
https://courses.cs.washington.edu/courses/csep590a/07au/lect...
https://courses.cs.washington.edu/courses/csep590a/07au/lect...
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.
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.
I appreciate this review. Son #5 is always looking for video editing tools. I left a copy on the house drive for him to try.
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.
This looks really well-done!
Not sure that I have a use for it, myself (although I could have used it back in my wageslave days).
I know exactly how difficult this type of thing is, so hats off to making it easy.
Best of luck with it!
Not sure that I have a use for it, myself (although I could have used it back in my wageslave days).
I know exactly how difficult this type of thing is, so hats off to making it easy.
Best of luck with it!
That's an Electron wrapper on top off ffmpeg right?
I use and love Shutter Encoder, I wonder how it compares?
https://www.shutterencoder.com
https://www.shutterencoder.com
It claims to do a bunch of operations without conversion/re-encoding: https://www.shutterencoder.com/documentation/#Functions-With...
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
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
Looks great. what do you usually use to put some simple animations/text (not subs) into a recorded video?
Anyone have tips for removing audio noise from a VHS transfer? Linux and ideally Foss?
Not as stable as avidemux, though avidemux is already quite buggy.
[deleted]
[deleted]
I wonder how it compares to Handbrake
It does not compare, because they do not do the same thing. Handbrake is a video transcoder. LosslessCut cuts up videos specifically without transcoding.
They are both GUIs for ffmpeg, I think you're mistaken and they do a lot of similar things
They're not mistaken. They're different programs for different tasks.
Does handbrake supports slicing and moving around segments as well?
Yes, you can reorder the individual segments. If the original video has chapters, these get imported as segments or you can mark them up manually.
It has start and stop times, but that's all.
I see. Thanks.
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.
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.
I used to use Handbrake but now only use LosslessCut. I find lossless to be easier to use if I just need quick trims or edits.
(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.