Difference between (K) & (I)?

[dosdan]

I'm using Virtualdub FilterMod. I know that (K) is a keyframe but what's (I)? Is this an IDR-frame?

Dan.

[raffriff42]

'K' is from the original Vdub code, 'I' ('Intra') is from ffmpeg-based code. Probably.
https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md FFPICT_TYPE

The picture type of the most recently requested frame as the ASCII number of the character listed below. Use Chr() to convert it to an actual letter in Avisynth. Use after_frame=true in Avisynth's conditional scripting for proper results. Only set when rffmode=0. The FFmpeg source definition of the characters:

I: Intra
P: Predicted
B: Bi-dir predicted
S: S(GMC)-VOP MPEG4
i: Switching Intra
p: Switching Predicted
b: FF_BI_TYPE (no good explanation available)
?: Unknown

[dosdan]

Here's a 5s clip (29 MB) MP4 from a Panasonic HC-V770 camcorder. It's nominally 50Mbps 1080p50. I've losslessly cut it on key-frames using ADM:

https://dl.dropboxusercontent.com/s/cv5lfq51jip0jof/Panasonic%20HC-V770%2050M%201080p50%20clip.mp4

The GOP length appears to be 24 frames.

The latest Vdub Filtermod still reports the frame-type sequence as:

KBIBBPBBPBBPBBPBBPBBPBBP

I'm hoping someone can confirm this sequence and explain why the 3rd frame in this sequence is showing as (I)?

Dan.

[poisondeathray]

coded order (how it's stored) can differ from display order (what you see)

In display order, the first frame, frame zero, is a "B" frame . I don't know why it uses "K" notation for this . The I is correct for display order (it's frame 2 starting counting from zero) . In coded order the I-frame is zero.

[dosdan]

Vdub FilterMod offers two ways of opening a file:

Caching Input Driver
FFMPEG

The program was using the caching input driver to open the clip. When I switched it to FFMPEG the frame-types changed to:

BBIBBPBBPBBPBBPBBPBBPBBP

So it appears to be coming from the caching input driver. I'll start a ticket to see if I can find out what's going on.

Dan.

[shekh]

K identifies keyframe. AFAIK the real keyframe is supposed to be IDR but here it is offset for some reason.
I noticed this behavior long ago: when the stream begins with B-frames the "keyframe" flags are offset. In theory it should be BBKBBP...
Unfortunately dealing with keyframes in FFmpeg is unsupported/loose. What I have is best guess effort.

[kolak]

ffmpeg should distinguish IDR frames which are key frames and "normal" I frames.
Not every I frame has to be an IDR frame.


This is an explanation from x264 thread:

IDR-Frame clears the reference picture buffer, i.e. no frame after IDR can reference any frame before IDR. That's not the case with "normal" I-Frame, i.e. P- or B-Frame after I-Frame can use as reference frames before I-Frame.

In other words: You are always "cleanly" start decoding at an IDR-Frame, which is not (in general) possible with a "normal" I-Frame.