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.
>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]?
> 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.
Which 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.
Smart 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).
I 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.
Non-linear (i.e. normal) video (and audio) editing is lossless until you export the result. The neat thing that tools like this one, LosslessCut, Avidemux, etc. do is that they don't re-encode the video on save/export.
There are a few caveats, though. Examples: (1) You're limited to cuts-only edits. (2) Because the base unit of video encoded for distribution is a GOP¹, edits either have to happen on GOP boundaries (i.e. at a keyframe) or the apps have to re-encode the GOP.
