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

[Michael Niedermayer]

Hi

On Wed, Nov 15, 2006 at 02:45:04AM +0000, Måns Rullgård wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
[...]
> >> 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?
> 
> Since when do the NUT goals exclude certain applications domains
> entirely?

they dont, its just that hw which has been designed solely for the purpose
of demuxing and decoding mpeg cant be expected to support non mpeg be it
nut or something else


> 
> > 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)
> 
> In the chips I'm talking about demuxing is done in hardware.  If
> someone wanted to make a hardware decoder with NUT demuxer, there
> could be trouble because of this restriction.  The reason for the
> offset is that the audio and video decoders have different delays, and
> buffers have to be kept to a minimum.  Even 4kB can be a lot of space
> in these devices.

dont these hw decoders need a few 100kb sized buffer to workaround the
arificial vbv rules?


> 
> I wasn't aware that NUT was intended exclusively for software decoders
> with huge buffers.
> 
> > 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?
> 
> The spec could allow for a constant offset between streams, possibly
> specified in a header field.  I can't think of a case where variable
> delay would make sense.

and a constant delay (which doesnt match _your_ decoder) would help?
how? or should every nut file contain a arbitrary delay at the users
discretion, mpeg doesnt do that either it specifies the vbv rules
and decoders be it hw or sw are then designed to somehow demux and
decode the result, if they need extra buffering to deal with it
(every sw decoder i know of does) so be it


[...]
> > * you can actually seek to a specific time (in mpeg thanks to timestamp
> >   discontinuities you cant)
> 
> You obviously haven't seen the set top boxes we make at work.

they can seek to a specific frame?


> 
> > * you can seek to keyframes (in mpeg you MUST have many keyframes or
> >   live with several second delay for seeking on slow media)
> 
> You seem to be very concerned about seeking.  Personally, I use seek
> functions less than once per hour of video.  When I do use seeking, I
> don't really care if it takes 10ms longer to find the right spot, or
> exactly where it lands.

10ms?
for exact seeking in mpeg you need (assuming there are no timestamp
discontinuiies) a binary search (10ms seek per step at least assuimg
local storeage, if its a slow cdrom, LAN, or the internet that will
be significantly slower, and you need 5-10 such steps) then you need
a linear search to the next or previous keyframe (with the 12frame 
gops commonly used in mpeg thats <500ms with normal common 300frame 
gops that can take 5-10seconds if your channel is as fast as the 
bitrate of your stream)

now with an index be it one in avi, mov,nut, matroska or anything else
seeks are instantaneous the difference is in seconds to mpeg not
milliseconds
sure you can require 2 keyframes per second (like everyone who uses
mpeg does) but still the difference should be on the order of >200ms
not 10ms


> 
> > * 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 :))))))
> 
> A prerequisite of muxing is understanding the spec.  As far as anyone
> knows, this has never happened for NUT.  You and Oded arguing over
> what things mean are proof of this.

did you ever read any ITU or ISO mailinglists? there are plenty of
disscussions of people both members of the standard comitees and
outside who dont understand or missunderstand the specs

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