[NUT-devel] r20926 - trunk/DOCS/tech/nut.txt

[Michael Niedermayer]

Hi

On Tue, Nov 14, 2006 at 11:42:40PM +0000, Måns Rullgård wrote:
> Michael Niedermayer <michaelni at gmx.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