Comment by pixelmonkey | Hacker News Reader

Comment by pixelmonkey | Hacker News Reader

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.

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'.

Lol I did all kinds of nonsense like that. I got Adobe Premiere in 8th grade and had no clue what I was doing.

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.

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.

320mbps sounds like a lot :)

Oops, obviously meant kbps there.

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.

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.

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/

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

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.)

> 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

  0           1  |<-->|   2
  KdddddddddddKdddddddddddKddddddddddd
              Kdd       = keyframe "L"
              Kdddddddd = keyframe "M"
  
  KdddddddddddKdLMddKddddddddddd

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?

  0           1  |<-->|   2
  KdddddddddddKdddddddddddKddddddddddd
  KdddddddddddKddeeeKddddddddddd

(where 'e' marks recomputed deltas)

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.

How many frames per group, usually?

Varies by codec.

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 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

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.

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.

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!

Reply on news.ycombinator.com