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

[Robert Krüger]

On Mon, Oct 21, 2013 at 4:21 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Robert Krüger <krueger at ...> writes:
>
>> If my debug output is correct, both contain no
>> B-slices/frames (I just noticed that) but they
>> do contain I-slices/frames. If I am not missing
>> something, those I-Frames should be valid random
>> access points then.
>
> Do you mean you debugged the sample (with a stream
> analyzer) and you know that every I-frame is a
> random access point or would you just expect every
> I-frame in the sample being a random access point?

Not with a stream analyzer but by adding code to ffmpeg's h264 parser
and reading the spec. Since only P- and I-slices are parsed (I can see
that in the debug output), I would indeed expect every I-frame
(meaning any frame only consisting of one I-slice in the stream) to be
a valid access point or I am missing something (which may very well be
the case).

>
> Testing the 720p sample, it appears to me that
> FFmpeg thinks the first random access point after
> the initial IDR frame is the 28th frame, a P-frame.

What do you mean "thinks". Are you looking at the seeking code?

Judging by the debug output of the h.264 parser I see that the packet
with pts 79304 (it's the 27th packet from the start) contains an
I-slice and is the only slice parsed from that packet, so I would say
that this is indeed a self-contained I-frame (also the size/bitrate of
that packet is an indication for it being an I slice). There is also
an SPS at 79304.

> If FFmpeg is right (and the 27th frame is no random
> access point), how should the random access point
> be signaled?

You mean what criterion to use to decide it's a random access point? I
naively thought, when only encountering P- and I-slices in the entire
stream any picture that only consists of one I-slice could be
considered a valid random access point especially with the coincidence
that there seems to be an SPS directly before every I-slice in the
stream but I am far from being an h264 expert and may be wrong.

>
> [...]
>
>> > Even better. Which commit are you talking about?
>
> Iirc, fixed ticket with keyword "h264".

You mean 2738?

Robert