Can ffmpeg calculate a new starting keyframe when being asked to split/copy on a non-keyframe?

Question

I understand from a question here that keyframes can (and do) occur anywhere in an h.264 stream, so I'm wondering why most of the advice I see where users want to cut on a specific time or frame (that is not a key frame) is that they'll have to go to the next/previous keyframe and start cutting from there if they want to do a straight stream copy,

Is it possible to make ffmpeg cut anywhere, from any frame and if it just so happens that the start frame is not a keyframe, then seek back to the nearest keyframe, then work forwards composing a new keyframe that will be used much nearer to the non-keyframe the user wants to start from?

For example if we have rules that a keyframe K must be followed by a pattern of any number of n and o starting with n, and the user wants to cut on some o:

KnononononoKnononononoKnonononono
      ^                                 //and the user wants to cut on an o

    knononoKnononononoKnonononono       //use Knono to generate a new k, place it near the o
           '

And then just encode this new keyframe plus original non keyframes knonono and then start stream copying from the frame above the apostrophe?

Does the encoding of the whole of the second Knonononono rely on some output from the first and hence there's a chaining effect/replacing the first block ruins the stream? (And if so then how does cutting on an existing keyframe help in that regard?)

Answer 1

In principle, this is possible, and is usually called "smart" encoding or rendering in the video editors / apps that offer this facility, typically in limited circumstances. FFmpeg does not have support for it.

The main complication is that the parameters of the encoded portion has to match the coding parameters of the existing stream. That is specific to each codec, and ffmpeg supports hundreds of video codecs. It would require significant redesign to parts of ffmpeg to have different handling for parts of an output stream, and to correctly parse the existng stream and ensure a compatible encoding. It's quite a bit of work and testing required for a feature that can be accomplished manually using a few more commands i.e. segmenting the input file, transcoding the changed /trimmed portions, and stitching the transcoded and old segments.