----- Original Message -----
From: "Hendrik Leppkes" <[email protected]>
To: "This list is about using libavcodec, libavformat, libavutil,libavdevice and
libavfilter." <[email protected]>
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 <[email protected]> wrote:
----- Original Message ----- From: "Carl Eugen Hoyos" <[email protected]>
To: <[email protected]>
Sent: Tuesday, December 10, 2013 6:12 PM
Subject: Re: [Libav-user] packet flag AV_PKT_FLAG_KEY
Don Moir <donmoir@...> 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.
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
