But at least in x264 they are not independent It should not affect your answer to OP, since -g 24 alone should be sufficient. No idea about vp8/9, but I have learned my lesson in x264.

In x264, setting both to the same value does not do what you think it does. I don't recall whether that is FFmpeg or x264's logic and neither have I tested vp8/9. I have learned to be very careful with these, as there is an undocumented dependency and no console warning. I don't know about vp8/9, but at least with x264, an undocumented gotcha is that keyint_min cannot be set greater than ((keyint/2)+1), otherwise it is ceiled at ((keyint/2)+1). I hope if someone can apply this, and tell us how, or mention some of the ffmpeg team, or deliver it to them anyhow.BTW - watch out with these two. It can be even faster if we can do multiple cuts with one command, so we traverse the frames once.

This will make us able to have exact cuts with slightly slower operation but still super faster than re-encoding the full video. Note that the first two parts are expected to be small (and one of them or both can be zero length), so, the re-encoding process will be fast. I suggested suggest this algorithm, to divide the segment (t1, t2) that we want to copy to 3 parts:ġ.a part (t1-x, t1+y), which is a complete encoded block that should be re-encoded to be able to copy the part (t1, y) precisely.Ģ.a part (t2-z, t3+w), which is a complete encoded block that should be re-encoded to be able to copy the part (z, t2) precisely.ģ.a middle part (y, z) which contains complete encoded blocks, where it can be copied as is.Ĥ.Join the 3 parts resulted from the above steps.

I want to know how ffmpeg decides the cutpoints). I have a solution, but I don't know how to do it using current ffmpeg commands (my trials to copy at keyframes didn't come accurate too.

Ffmpeg copy keyframe