7 ms·

As has been said, this happens because of cutting on the closest keyframe, which is the only point where the cut can be done losslessly. This is how it's been

by j1elo 4y ago

As has been said, this happens because of cutting on the closest keyframe, which is the only point where the cut can be done losslessly. This is how it's been done traditionally, since basically forever as far as I can remember. To be honest, I think modern tools could do better. If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted. There are a myriad tools to do the typical lossless easy cut, but no idea of one that goes the extra mile to do this more advanced technique. UPDATE: Navigating the GitHub issues I found out that this is indeed an in-progress experimental feature! That's amazing -- https://github.com/mifi/lossless-cut/issues/126 https://github.com/mifi/lossless-cut/issues/126

oefrha 4y ago
> If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted. All the P-frames and B-frames in between two I-frames have to be recomputed. That’s by definition re-encoding and not lossless. You could re-encode just that small segment though.
- maria2 4y ago
  This would obviously be codec dependent, but I'm surprised it's impossible to losslessly re-encode a video given I, P, and B frames. Mentally, I think of P frames as containing "changes" in the frame. The changes would be the same regardless of whether or not the previous frame was an I or P frame.
  - oefrha 4y ago
    > I'm surprised it's impossible to losslessly re-encode a video It is possible, it will just be a ridiculously large video. > Mentally, I think of P frames as containing "changes" in the frame. The changes would be the same regardless of whether or not the previous frame was an I or P frame. P-frames in modern codecs use multiple previously decoded frames, not just the previous frame. And I'm not getting into the complexity of frame ordering (decoded frames and presented frames can be ordered differently).
    - infogulch 4y ago
      Oh so the P frame after the one you want to cut at may be looking farther back than just one I frame. I guess you could do the lossless cut at the previous I frame as this tool does, then also set the start media timestamp to the frame that you actually wanted to cut at, as described elsetheread by NelsonMinar.
      - oefrha 4y ago
        > set the start media timestamp to the frame that you actually wanted to cut at You can do that, but it’s container format-dependent (e.g. mov edit list) and player support is uneven. If the player doesn’t support it you get extended cut and A/V desync.
    - maria2 4y ago
      > It is possible, it will just be a ridiculously large video. Ha true, I guess you could encode every P/B frame after the cut as an I-frame.
    - dublin 4y ago
      It's perfectly possible, just not with the common media-mogul owned and propagated video encoding formats. There are applications where you need a compressed video stream that does not have keyframes, so that you are not blind until the next one if one happens to get scrogged in transit. (Think things like UAV pilots blowing up things halfway around the world.) These algorithms had methods have existed for 20 years - nearly that long ago, I held in my hand a single DVD with thirty full-length movies on it - all compressed losslessly using such an codec on a laptop. I actually accepted a job with the company (they even sent tickets for the flight out to Seattle for my first day on Monday) before calling me on Friday afternoon to tell me that the company had been acquired by a government-related entity and my role (being public-facing) was not needed. (Pissing me off because I'd turned down another good offer to take theirs!) It's the only time I've ever even heard of getting laid off before you start. The company vanished from the face of the earth that week...
      - dikei 4y ago
  - brigade 4y ago
    Decoding the “changes” can be dependent on the “changes” in a previous frame, notably that the prediction for motion vectors can come from previous frames’ motion vectors. Which I frames obviously don’t have. Besides that the only way to losslessly re-encode frames is to use lossless encoding, which would easily be a 50-100x size bloat.
- BoorishBears 4y ago
  They could do much better than that, cut at a keyframe and change the metadata to start at the correct time. You end up with a tiny bit of wasted data, but it's happy middle ground compared to having to give up the key selling point
  - astrange 4y ago
    MOV/MP4 files can do that, but most other video formats can't. You can also leave out the B-frames prior to the new start time.
  - rndgermandude 4y ago
    The problem with that is that the skipped data will still be present and therefore easy to recover if you know what you're looking for. That may "leak" seconds worth of video (and audio) the user may have thought was removed. And those seconds may contain something sensitive, e.g. a pan over some confidential information on some paper or screen, or genitals, or whatever.
    - BoorishBears 4y ago
      It'd take one button with a label to solve that.
- FullyFunctional 4y ago
  It would be lossless for the vast majority of the video, only the cut point would be lossy. I'm sure that is ideal for most people. Sounds like it's in progress.
acchow 4y ago
B-frames should simplify this a lot. Only this very short portion would be re-encoded

by j1elo 4y ago

oefrha 4y ago

> If you happen to want a cut just 20 frames after a keyframe, those 20 frames could be computed (decoded) in order to create a new keyframe right in the spot you wanted. All the P-frames and B-frames in between two I-frames have to be recomputed. That’s by definition re-encoding and not lossless. You could re-encode just that small segment though.

maria2 4y ago
This would obviously be codec dependent, but I'm surprised it's impossible to losslessly re-encode a video given I, P, and B frames. Mentally, I think of P frames as containing "changes" in the frame. The changes would be the same regardless of whether or not the previous frame was an I or P frame.
- oefrha 4y ago
  > I'm surprised it's impossible to losslessly re-encode a video It is possible, it will just be a ridiculously large video. > Mentally, I think of P frames as containing "changes" in the frame. The changes would be the same regardless of whether or not the previous frame was an I or P frame. P-frames in modern codecs use multiple previously decoded frames, not just the previous frame. And I'm not getting into the complexity of frame ordering (decoded frames and presented frames can be ordered differently).
  - infogulch 4y ago
    Oh so the P frame after the one you want to cut at may be looking farther back than just one I frame. I guess you could do the lossless cut at the previous I frame as this tool does, then also set the start media timestamp to the frame that you actually wanted to cut at, as described elsetheread by NelsonMinar.
    - oefrha 4y ago
      > set the start media timestamp to the frame that you actually wanted to cut at You can do that, but it’s container format-dependent (e.g. mov edit list) and player support is uneven. If the player doesn’t support it you get extended cut and A/V desync.
  - maria2 4y ago
    > It is possible, it will just be a ridiculously large video. Ha true, I guess you could encode every P/B frame after the cut as an I-frame.
  - dublin 4y ago
    It's perfectly possible, just not with the common media-mogul owned and propagated video encoding formats. There are applications where you need a compressed video stream that does not have keyframes, so that you are not blind until the next one if one happens to get scrogged in transit. (Think things like UAV pilots blowing up things halfway around the world.) These algorithms had methods have existed for 20 years - nearly that long ago, I held in my hand a single DVD with thirty full-length movies on it - all compressed losslessly using such an codec on a laptop. I actually accepted a job with the company (they even sent tickets for the flight out to Seattle for my first day on Monday) before calling me on Friday afternoon to tell me that the company had been acquired by a government-related entity and my role (being public-facing) was not needed. (Pissing me off because I'd turned down another good offer to take theirs!) It's the only time I've ever even heard of getting laid off before you start. The company vanished from the face of the earth that week...
    - dikei 4y ago
- brigade 4y ago
  Decoding the “changes” can be dependent on the “changes” in a previous frame, notably that the prediction for motion vectors can come from previous frames’ motion vectors. Which I frames obviously don’t have. Besides that the only way to losslessly re-encode frames is to use lossless encoding, which would easily be a 50-100x size bloat.
BoorishBears 4y ago
They could do much better than that, cut at a keyframe and change the metadata to start at the correct time. You end up with a tiny bit of wasted data, but it's happy middle ground compared to having to give up the key selling point
- astrange 4y ago
  MOV/MP4 files can do that, but most other video formats can't. You can also leave out the B-frames prior to the new start time.
- rndgermandude 4y ago
  The problem with that is that the skipped data will still be present and therefore easy to recover if you know what you're looking for. That may "leak" seconds worth of video (and audio) the user may have thought was removed. And those seconds may contain something sensitive, e.g. a pan over some confidential information on some paper or screen, or genitals, or whatever.
  - BoorishBears 4y ago
    It'd take one button with a label to solve that.
FullyFunctional 4y ago
It would be lossless for the vast majority of the video, only the cut point would be lossy. I'm sure that is ideal for most people. Sounds like it's in progress.

acchow 4y ago

B-frames should simplify this a lot. Only this very short portion would be re-encoded