This has always bothered me, I suspect it’s the same underlying reason most video players can’t do reverse frame-by-frame. But Quicktime allowed it twenty years ago, so it’s possible. I suppose you’d have to actually decode the entire keyframe interval and use the resulting frames as new “baked-in” keyframes so to say. I suppose that’s more or less what djv and other frame checkers do under the hood. But I don’t know what I’m talking about so…
That’s what I’ve always assumed it does since back when quicktime player barely even ran on my PC yet for timeline operations it was significantly more responsive than WMP/MPC.
For Losslesscut I just get around this by encoding my input from source using keyint=n:scenecut=0 in ffmpeg where n is a manually set keyframe interval.
So e.g. if my expected cut occurs on a frame that occurs at t+10 seconds of footage, n can be the same as the fps and then there’ll always be a keyframe exactly at timestamp 00:00:01, 00:00:02 and so on. I can then open it in losslesscut and easily snap to the frame I want and make the cut losslessly.
Yeah the first encode generally means a lossy transcode by the time I get to my final video but being realistic that’d be a part of my workflow either way and this way it’s less
This has always bothered me, I suspect it’s the same underlying reason most video players can’t do reverse frame-by-frame. But Quicktime allowed it twenty years ago, so it’s possible. I suppose you’d have to actually decode the entire keyframe interval and use the resulting frames as new “baked-in” keyframes so to say. I suppose that’s more or less what djv and other frame checkers do under the hood. But I don’t know what I’m talking about so…
That’s what I’ve always assumed it does since back when quicktime player barely even ran on my PC yet for timeline operations it was significantly more responsive than WMP/MPC.
For Losslesscut I just get around this by encoding my input from source using keyint=n:scenecut=0 in ffmpeg where n is a manually set keyframe interval.
So e.g. if my expected cut occurs on a frame that occurs at t+10 seconds of footage, n can be the same as the fps and then there’ll always be a keyframe exactly at timestamp 00:00:01, 00:00:02 and so on. I can then open it in losslesscut and easily snap to the frame I want and make the cut losslessly.
Yeah the first encode generally means a lossy transcode by the time I get to my final video but being realistic that’d be a part of my workflow either way and this way it’s less