On Mon, Nov 13, 2006 at 04:23:45PM +0100, michael wrote:
Author: michael Date: Mon Nov 13 16:23:45 2006 New Revision: 20886
Modified: trunk/DOCS/tech/nut.txt
Log: pts definition by mans dts definition and decode_delay definition by me
Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Mon Nov 13 16:23:45 2006 @@ -68,6 +68,11 @@ keyframe status of the current frame but instead just set the frame as non keyframe (FIXME maybe move somewhere else?) +pts + presentation time of the first frame/sample that is completed by decoding + the coded frame. +dts + of a frame is the time when it is input into the decoder
I don't like defining dts like this because it makes it sound like NUT must be used with a synchronous decoder, which is of course not necessary. A note that it corresponds to the time the frame should be fed to the decoder for synchronous (and cfr-like) decoding could be included, but IMO the ONLY point of defining dts whatsoever in NUT is to have a way of specifying interleaving order. Rich