Hi On Mon, Nov 13, 2006 at 12:56:56PM -0000, Måns Rullgård wrote:
Michael Niedermayer said:
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)
Not that my word counts for much around here, but that is not a good definition. The PTS must be defined as the presentation time of the first frame/sample that is completed by that coded frame. With your suggested definition, a coded IPBB sequence (displayed IBBP) the PTS of the P and B frames would all be 1. This is clearly not a good situation.
thanks for the suggested improvement, ive added your pts definition [...] -- 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