[Libav-user] packet flag AV_PKT_FLAG_KEY

[Don Moir]

----- Original Message ----- 
From: "Hendrik Leppkes" <h.leppkes at gmail.com>
To: "This list is about using libavcodec, libavformat, libavutil,libavdevice and libavfilter." <libav-user at ffmpeg.org>
Sent: Wednesday, December 11, 2013 2:07 AM
Subject: Re: [Libav-user] packet flag AV_PKT_FLAG_KEY


> On Wed, Dec 4, 2013 at 1:41 PM, Don Moir <donmoir at comcast.net> wrote:
>>
>> ----- Original Message ----- From: "Carl Eugen Hoyos" <cehoyos at ag.or.at>
>> To: <libav-user at ffmpeg.org>
>> Sent: Tuesday, December 10, 2013 6:12 PM
>>
>> Subject: Re: [Libav-user] packet flag AV_PKT_FLAG_KEY
>>
>>
>>> Don Moir <donmoir at ...> writes:
>>>
>>>> Not sure what AV_PKT_FLAG_KEY is supposed to mean.
>>>> The assumption to me early on is it represented a key
>>>> frame but not necessarily.
>>>
>>>
>>> Apart from the fact that I simply don't understand the
>>> second sentence:
>>
>>
>> Hard to understand is right and still tring to understand.
>>
>>
>>> What is missing here imo is what is unclear in your opinion
>>> about the documentation (or for which input stream the
>>> documentation does not match the behaviour).
>>> Note that valid H.264 streams do not necessarily contain
>>> keyframes and therefore do not necessarily contain packets
>>> with this flag set.
>>>
>>> Carl Eugen
>>
>>
>> Yes I understand about H.264. The confusion is when there are known key
>> frame index_entries and these do represent at least a start point for a key
>> frame. Now seems AV_PKT_FLAG_KEY should dovetail with those entries but it
>> does not.
>>
>> If you look around some you find confusion about the usage of
>> AV_PKT_FLAG_KEY. If this is used internally for some special case, then IMO
>> another flag should have been used. The intent of the flag is just not
>> documented well. Ideally I think it should mark the start of a key frame and
>> at least dovetail with index_entries but I am sure it goes deeper than that.
>
>
> The index usually comes directly from the source file. Its not
> generated by avformat. (avformat has some limited index generation
> functionality, but only for content you already read from the file, so
> its kinda worthless)

Might be useful to add entries at times like for scrubbing. App could add the entries with care.

> The key flag comes either from the file as well, or its filled by the
> codec parser. In the first case, its up to the file if it matches to
> an index entry, in the second, there is no guarantee whatsoever.
>
> If i take MKV as an example, index entries correspond to the Cue
> elements in the file. While the position pointed to by a Cue should
> start with a keyframe, there is no rule whatsoever that every keyframe
> also needs to have a Cue element.

Yeah just trying to understand that connection if any.

> In short, as with many things in avformat, it just gives you the data
> as it was stored in the file. If that doesn't match your expectations,
> blame the file.

I suppose my only initial expectation long ago was that AVDISCARD_NONKEY worked as expected. I see its gotten better in some areas 
but not in others. Haven't tested it too much lately though. Even if AVDISCARD_NONKEY was dependable, I like the better control you 
get with AV_PKT_FLAG_KEY as long that works as it should.

Thanks for the info.