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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|