[Libav-user] Criteria for h.264 key-frame detection
Carl Eugen Hoyos
cehoyos at ag.or.at
Sun Oct 20 14:16:44 CEST 2013
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
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.
> 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)...
> 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?
> 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?
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
(Disclaimer: My knowledge of H264 is quite limited, so maybe
More information about the Libav-user