From 8a881c1e5524b9313f774163658f402a3fa26f2f Mon Sep 17 00:00:00 2001 From: michael Date: Fri, 3 Nov 2006 21:13:50 +0000 Subject: 2nd try for a keyframe definition based on richs comment git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@20647 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/tech/nut.txt | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/DOCS/tech/nut.txt b/DOCS/tech/nut.txt index 9e7123d4a3..2f68e459d9 100644 --- a/DOCS/tech/nut.txt +++ b/DOCS/tech/nut.txt @@ -42,11 +42,15 @@ 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 + The nth frame is a keyframe if and only if frames n, n+1, ... in + presentation order (that are all frames with a pts >= frame[n].pts) can + be decoded successfully without reference to frames prior n in storeage + order (that are all frames with a dts < frame[n].dts) + if no such frames exist (for example due to use of overlapped transforms + like the MDCT in an audio codec) then the definition shall be extended + by droping n out of the set of frames which must be decodable, if this + is still insufficient then n+1 shall be droped, and so on until there is + a keyframe (FIXME maybe move somewhere else?) -- cgit v1.2.3