Hi On Sun, Nov 12, 2006 at 09:42:17PM -0500, Rich Felker wrote:
On Sun, Nov 12, 2006 at 01:24:57PM +0100, michael wrote:
Author: michael Date: Sun Nov 12 13:24:57 2006 New Revision: 20862
Modified: trunk/DOCS/tech/nut.txt
Log: least restrictive dts ordering rule which ensures frames are in decoding order
Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Sun Nov 12 13:24:57 2006 @@ -670,6 +670,8 @@ Pts of all frames in all streams MUST be bigger or equal to dts of all previous frames in all streams, compared in common timebase. (EOR frames are NOT exempt from this rule) + Dts of all frames MUST be bigger or equal to dts of all previous frames + in the same stream
This is guaranteed by the definition of DTS and the above condition on PTS, isn't it?
i dont know but just looking at the definition of decode_delay gives me doubt "decode_delay maximum time between input and output for a codec, used to generate dts from pts is set to 0 for streams without B-frames, and set to 1 for streams with B-frames, may be larger for future codecs decode_delay MUST NOT be set higher than necessary for a codec." what is the "maximum time between input and output for a codec" ? its not the time between a frame input and output IPBBB ->IBBBP (=3) its neither the smallest number so that dts are monotone (IPPPP) and codec is decoder + encoder that too makes no sense i dont know what i was thinking when i wrote that :( its rather dts of a frame is the time when it is input into the decoder pts is the time of presentation of the first corresponding decoded sample and decode_delay is then the size of the timestamp sorting buffer that the above has a solution for note, the above is a little fuzzy i know but if we define pts like pts is the time of presentation of the first sample affected by the frame then IPBBB would have I.pts=0 P.pts=1 as the b frame is affected by P comments, objections? (if there are no objections then ill change that in the spec) and what about audio? with a MDCT a frame which feeded into the decoder affects samples 2t..2t+4 it combines that with the previous frame like: __ Frame 0: / \ __ Frame 1: / \ __ Frame 2: / \ out 1: ** out 2: ** that gives the expected decode_delay=0 another thing i was thinking about was if we maybe should add a field to indicate how many initial inexact (or not outputed) samples there are after seeking? [...] -- 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