[HN Gopher] LosslessCut: The Swiss army knife of lossless video/...
___________________________________________________________________
LosslessCut: The Swiss army knife of lossless video/audio editing
Author : ingve
Score : 153 points
Date : 2024-06-29 11:18 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| heartag wrote:
| 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.
| dang wrote:
| 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)
| jsheard wrote:
| 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.
| slimscsi wrote:
| GPL-2.0 license in GitHub. MIT license on snap store. $19 in Mac
| OS APP store.
| frizlab wrote:
| Can be downloaded for free for all platforms too.
| IshKebab wrote:
| How does it work if you want to cut at a B frame?
| kmeisthax wrote:
| Presumably it re-encodes a single GOP and inserts it into the
| video stream.
| adzm wrote:
| Yes this is the smart cut feature
| LeoPanthera wrote:
| 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.
| pixelmonkey wrote:
| 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.
| teddyh wrote:
| I also recall AviDemux being able to do lossless cuts.
| skelpmargyar wrote:
| 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.
| kmeisthax wrote:
| 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
| deeth_starr_v wrote:
| Mpegstreamclip used to do similar on macOS but is not
| compatible with modern Mac's
| miles wrote:
| 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 .
| silisili wrote:
| 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'.
| jpnguyen wrote:
| 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.
| WarOnPrivacy wrote:
| 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.
| throw101010 wrote:
| 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 is really short (under a
| second) it will generally fail... but chances are keyframe cuts
| in this case don't work well either.
| Scotrix wrote:
| Looks great. what do you usually use to put some simple
| animations/text (not subs) into a recorded video?
| simple10 wrote:
| 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.
| radicality wrote:
| 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.
| nox101 wrote:
| 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
| MitPitt wrote:
| I wonder how it compares to Handbrake
| simple10 wrote:
| 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.
| LeoPanthera wrote:
| It does not compare, because they do not do the same thing.
| Handbrake is a video transcoder. LosslessCut cuts up videos
| specifically without transcoding.
| MitPitt wrote:
| They are both GUIs for ffmpeg, I think you're mistaken and
| they do a lot of similar things
| okamiueru wrote:
| Does handbrake supports slicing and moving around segments
| as well?
| ggjkvcxddd wrote:
| They're not mistaken. They're different programs for
| different tasks.
| TacticalCoder wrote:
| That's an Electron wrapper on top off ffmpeg right?
| relwin wrote:
| Also useful for archiving large video files to DVD-R, just cut
| into 4Gbyte chunks and write to a few discs.
| nathancahill wrote:
| I use and love Shutter Encoder, I wonder how it compares?
|
| https://www.shutterencoder.com
| CharlesW wrote:
| 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
| dsp_person wrote:
| 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.
| slimscsi wrote:
| 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 chooses 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"
| capitainenemo wrote:
| 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]"'
| mjevans wrote:
| Where's the -c copy or -c:v copy -c:a copy ?
| manca wrote:
| 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.
| NKosmatos wrote:
| Reminds me of VirtualDub from the good old days :-)
| sbt567 wrote:
| 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!
___________________________________________________________________
(page generated 2024-06-30 23:00 UTC)