r20926 - trunk/DOCS/tech/nut.txt

Hi

On Tue, Nov 14, 2006 at 11:42:40PM +0000, Måns Rullgård
wrote:
> Michael Niedermayer <michaelnigmx.at> writes:
> 
> > Hi
> >
> > On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15
wrote:
> >> Author: ods15
> >> Date: Tue Nov 14 18:03:33 2006
> >> New Revision: 20926
> >> 
> >> Modified:
> >>    trunk/DOCS/tech/nut.txt
> >> 
> >> Log:
> >> allow info packets to appear in mid-stream,
outside of main headers.
> >> these SHOULD NOT appear in
non-realtime-streams
> >
> > reverse this at once!
> > not a single person has agreed to this change
except you
> >
> > you cannot just change the (frozen) spec at will,
next time someone
> > is pissed at the dts ordering rule and changes it
to a SHOULD to have
> > audio packets 1 sec before video
> 
> Hmm... does NUT require strict monotony of DTS even
between streams?

not exactly but something similar:
    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)

why we ended up with this and not strict dts ordering is
something i dont
remember, but it doesnt seem like pts-dts vs dts-dts makes a
big difference


> That is not good. Many hardware MPEG decoders require
video to be
> about 80ms ahead of audio.  

since when does a _MPEG_ decoder support nut streams? now if
it doesnt
then what relevance has that comment? none?
and if you meant that demuxing is done in software and than
the ES are
sent to the HW then you can just buffer these 80ms audio (it
just needs
a 4kb buffer assuming ~200kbit audio)

additionally having audio and video with arbitrary delay
will not reduce
the problem but rather make it worse (i think you agree
here?)

and specifying exactly what delay there should be would
again not really
change a thing or?


> Guess I'll just have to stick with MPEG-TS
> for those then...

you will never use anything except mpeg no matter what
advantages
or disadvantages the formats have and iam not saying nut is
better
then mpeg in all cases, just in most 

more specifcially that is
* smaller overhead
* you can actually seek to a specific time (in mpeg thanks
to timestamp
  discontinuities you cant)
* you can seek to keyframes (in mpeg you MUST have many
keyframes or
  live with several second delay for seeking on slow media)
* you can store any codec, mpeg limits you to
mpeg1/mpeg2/h264/ac3
  and a few other standard ones
* muxing is MUCH easier (btw if you disagree please help me
fix the broken
  mpeg-ts muxer in ffmpeg )))))

[...]
-- 
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