[Libav-user] Criteria for h.264 key-frame detection

[Robert Krüger]

On Sun, Oct 20, 2013 at 2:16 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Robert Krüger <krueger at ...> writes:
>
>> I have AVCHD files from a camera (Panasonic Lumix GH1) that demux and
>> decode with libavformat/libavcodec detecting no other keyframe but the
>> first (both, the first video packet and video frame are marked as
>> keyframe), which is not what I would have expected for those clips as
>> the GOP structure of files produced by this camera is known to be
>> different.
>
> Afaiu, the files are field-encoded and I suspect it is not easy
> to decide if a "frame" (as output by libavcodec) is a keyframe
> or not if it consists of one field that can be decoded by itself
> and a second field that depends on earlier data, possibly older
> than the other (key-) field.

You are implying things here. This is not about ticket #3063 but a
different camera. There the behaviour is different from the one
described in #3063 and the same also for progressive files.

>
>> My question is now, what libavcodec/libavformat uses as criteria to
>> decide whether a packet is a keyframe packet or a frame is a keyframe
>> in this case.
>
> I wonder how the criteria could look like (to make you happy)...

I am asking what the criteria are, not requesting something or
reporting a defect (yet), just to be able to decide whether I should
open a ticket.

>
>> Does it only trigger in the case of IDRs or are recovery
>> point SEIs also detected?
>
> The recovery points are definitely detected, see also below.
>
>> Should I open a trac issue for this with a sample?
>
> Didn't you already open a ticket?

Not for this (explained above).

>
>> My requirement is, I want to find points in the stream suitable for
>> random access using libavformat/libavcodec. What are my options for
>> this kind of files?
>
> I was under the impression that lavf/lavc support recovery
> points very well (even in slightly broken streams), ie
> that you (as a user) can choose if you only want to seek to
> a recovery point (slower, done by ffplay) or to some frame
> no matter if it is a recovery point or not (faster, this
> is what MPlayer does).
> Do I miss something?

I don't know if you miss something. I am simply asking for
help/information. So are you saying that AVPacket.key_frame should be
set to 1 for recovery points in H.264?


>
> Or to try it differently: If FFmpeg would report an output frame
> consisting of an I-field and a non-I field as a keyframe, I believe
> that you would have no guarantee that the frame can be decoded
> by itself (because the second field may depend on something
> very old).

I agree but you are again implying things. I have not requested that
but merely asked a question and I am still not really sure if you have
answered it.

Robert