r20638 - trunk/DOCS/tech/nut.txt
Author: michael Date: Fri Nov 3 15:10:58 2006 New Revision: 20638 Modified: trunk/DOCS/tech/nut.txt Log: keyframe definition Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Fri Nov 3 15:10:58 2006 @@ -41,6 +41,13 @@ MUST the specific part must be done to conform to this standard SHOULD it is recommended to be done that way, but not strictly required +keyframe + a frame which can be decoded correctly on its own (=without using + information from any other frames) + if no such frames exist in a codec (for example due to use of overlapped + transforms like the MDCT in an audio codec) then a keyframe shall be any + frame from which onward all frames can be decoded correctly + (FIXME maybe move somewhere else?) Syntax:
On Fri, Nov 03, 2006 at 03:10:59PM +0100, michael wrote:
Author: michael Date: Fri Nov 3 15:10:58 2006 New Revision: 20638
Modified: trunk/DOCS/tech/nut.txt
Log: keyframe definition
Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Fri Nov 3 15:10:58 2006 @@ -41,6 +41,13 @@ MUST the specific part must be done to conform to this standard SHOULD it is recommended to be done that way, but not strictly required
+keyframe + a frame which can be decoded correctly on its own (=without using + information from any other frames) + if no such frames exist in a codec (for example due to use of overlapped + transforms like the MDCT in an audio codec) then a keyframe shall be any + frame from which onward all frames can be decoded correctly + (FIXME maybe move somewhere else?)
This definition is blatently incorrect, e.g. it makes a B frame with only intra blocks a keyframe. In order to be a keyframe, it must be possible to decode all subsequent (in time) frames without reference to any previous (in storage) frames before the keyframe. Rich
Hi On Fri, Nov 03, 2006 at 01:37:15PM -0500, Rich Felker wrote:
On Fri, Nov 03, 2006 at 03:10:59PM +0100, michael wrote:
Author: michael Date: Fri Nov 3 15:10:58 2006 New Revision: 20638
Modified: trunk/DOCS/tech/nut.txt
Log: keyframe definition
Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Fri Nov 3 15:10:58 2006 @@ -41,6 +41,13 @@ MUST the specific part must be done to conform to this standard SHOULD it is recommended to be done that way, but not strictly required
+keyframe + a frame which can be decoded correctly on its own (=without using + information from any other frames) + if no such frames exist in a codec (for example due to use of overlapped + transforms like the MDCT in an audio codec) then a keyframe shall be any + frame from which onward all frames can be decoded correctly + (FIXME maybe move somewhere else?)
This definition is blatently incorrect, e.g. it makes a B frame with only intra blocks a keyframe. In order to be a keyframe, it must be possible to decode all subsequent (in time) frames without reference to any previous (in storage) frames before the keyframe.
ive fixed it but the new definition is not acceptable, because strictly it requires the muxer to know all macroblock types of all future frames PPPPPPPI would all be keyframes if they all have only intra blocks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
participants (3)
-
michael -
Michael Niedermayer -
Rich Felker