3 ms·
E.g. MPEG4 videos are usually made of I-frames (full frames), P-frames (predictions based on older images) and B-frames (predictions based on older and future p
by _flux 3y ago
E.g. MPEG4 videos are usually made of I-frames (full frames), P-frames (predictions based on older images) and B-frames (predictions based on older and future pictures), and from these Group Of Pictures are made, which always start with an I-frame.
You cannot make frame-precise cuts within this sequence unless you wish to carry on the frames that won't be visible (and I don't think anyone tries to do these cuts by keeping some invisible frames), so you only get to make such edits that always include the first I-frame of the sequence.
Therefore if you want to make completely lossless edits your editing precision is lost. For frame-precise editing one usually ends up re-encoding the stream.
Of course, you could only re-encode only the GoPs that get broken while keeping the rest intact, and I guess this would be better and a lot faster than re-encoding everything. I don't know if any application tries to do this. But that is also a bit troublesome, as you'd like to use the same encoding parameters—and maybe the same encoder—as the other frames, to not have quality differences between the edits and original.
- darcien 3y ago>Of course, you could only re-encode only the GoPs that get broken while keeping the rest intact, and I guess this would be better and a lot faster than re-encoding everything. I don't know if any application tries to do this. LosslessCut does have experimental support for this partial re-encode called "smart cut" [1]. Since it's using ffmpeg internally, the challenge become how to instruct ffmpeg to do this[2]? [1]: https://github.com/mifi/lossless-cut/issues/126 https://github.com/mifi/lossless-cut/issues/126 [2]: https://github.com/mifi/lossless-cut/issues/1216 https://github.com/mifi/lossless-cut/issues/1216
- runlevel1 3y agoI suspect QuickTime Player.app's trim (Edit menu > Trim) does this as well when you save the result (as opposed to exporting it). It's far too fast to be re-encoding the whole video and is too precise to be cutting at the nearest keyframe. It has limited codec and container support, though.
- CharlesW 3y ago> It's far too fast to be re-encoding the whole video and is too precise to be cutting at the nearest keyframe. Correct! For example, if you trim the end of a video in the middle of a GOP, it includes the entire GOP as is, but only plays up to the point where you trimmed.
- j1elo 3y agoWhich is a very bad solution! Imagine cutting a video to remove some very privacy sensitive material, and some of those frames still ending up in the file, just not viewed because in theory the video file politely asks the player to skip until a later timestamp. I'd for sure rather have tools that actually do what they claim to do. Using container metadata tricks feels to me as lazy and misleading to the user.
- pony_sheared 3y agoI don't know if there are many cricket fans here, but I wondered if this is why - when watching the Ashes highlights of the cricket on BBC iPlayer or YouTube - the ball seems transparent as it runs over the grass.
- izacus 3y ago> and I don't think anyone tries to do these cuts by keeping some invisible frames My experience shows that if you try, this confuses and breaks many (especially hardware) players trying to play that file.
- nuxi 3y agoSmart Cutter[1] does frame-accurate edits without re-encoding. I'm not sure what black magic it uses, but it seems to work really well (tested on a couple of MPEG-TS IPTV streams). [1] - https://www.fame-ring.com/smart_cutter.html https://www.fame-ring.com/smart_cutter.html
- pkkm 3y ago> Of course, you could only re-encode only the GoPs that get broken while keeping the rest intact That's exactly what VidCutter does.