[FFmpeg-user] Intent of -copyinkf and non-key frames in video stream copy

[Doug Handy]

I am trying to clarify if I am misunderstanding the intent of the -copyinkf flag, or if what I want to do is not possible without transcoding.

I would like to extract frame accurate subsets from an input movie while still getting the speed advantage of a video stream copy. Normally a video stream copy must start on key frame boundaries, and i understand why. But the documentation includes this subset:

‘-copyinkf[:stream_specifier] (output,per-stream)’
When doing stream copy, copy also non-key frames found at the beginning.

I am not finding much more information about this option at all. Perhaps it is wishful thinking on my part and reading it to mean what I want it to mean, but I was hoping this would mean that when specified and your start location was not on a key frame, that it would generate a proper keyframe from the prior keyframe and intermediate frames up to the desired starting point.

I did find a cvslog message from Jan 2012 which showed a bug with this option:

This option only applies to streamcopy, but is currently processed only
when encoding.
The change log is at https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2012-January/045759.html

However, I am not getting it to produce the desired effect. It always subsets on a keyframe boundary. So prior to filing a bug report, I am trying to find out if I just misunderstand the intent of -copyinkf. So the question is:

Should -copyinkf allow me to start a video stream copy on a non-key frame position? If it helps, I can typically copy the video stream only and discard the audio stream.

Thanks

[Carl Eugen Hoyos]

Post by Doug Handy
‘-copyinkf[:stream_specifier] (output,per-stream)’
When doing stream copy, copy also non-key frames
found at the beginning.
I am not finding much more information about this
option at all. Perhaps it is wishful thinking on
my part and reading it to mean what I want it to
mean, but I was hoping this would mean that when
specified and your start location was not on a key
frame, that it would generate a proper keyframe

No.
The option just allows you not to skip
the initial non-keyframes when doing
stream-copy.

Carl Eugen

[Doug Handy]

Carl,

Post by Carl Eugen Hoyos

Post by Doug Handy
‘-copyinkf[:stream_specifier] (output,per-stream)’
When doing stream copy, copy also non-key frames
found at the beginning.

No.
The option just allows you not to skip
the initial non-keyframes when doing
stream-copy.

Not what I wanted to hear, but a definitive no is still better than continuing to try to chase a dream.

So what does that suggest about the playability of the output video stream on those beginning frames? If there is no initial key frame generated, what is the value of using this option to include non-keyframes? I'm trying now to understand the potential uses for the -copyinkf option.

Thanks,
Doug

[Carl Eugen Hoyos]

Post by Doug Handy
If there is no initial key frame generated, what is
the value of using this option to include non-keyframes?
I'm trying now to understand the potential uses for the
-copyinkf option.

If your input video does not start with a keyframe,
the option allows you not to start stream copying
with the first keyframe (this is the defaul
behaviour), but with the first frame of the
input stream (no matter if it is a keyframe or
not).

If you really want to know "why", please be assured
that for every option (of the huge number FFmpeg
provides) a user has once requested it.
(In the specific case of -copyinkf, it is also
useful if you want to copy subtitles that are for
some reason not marked as keyframes, but this is
more a work-around than a feature.)

Carl Eugen

[Doug Handy]

Carl,

Post by Carl Eugen Hoyos
If your input video does not start with a keyframe,
the option allows you not to start stream copying
with the first keyframe (this is the defaul
behaviour), but with the first frame of the
input stream (no matter if it is a keyframe or
not).

In my use case, it isn't the video stream per se that does not start with a keyframe. Rather, it is a trim point that I'd like to be frame accurate even while doing a stream copy instead of transcode. So that even when the point where I want to extract a subset does not start on a key frame, for performance reasons I was hoping -copyinkf would let me start anywhere

I think I just into the argument description what I wanted it to mean. :)

But that is why I was asking for clarification here first instead of submitting a bug report. Sounds like it could well be working as designed; just not the feature I was hoping it would be.

Doug