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