r20926 - trunk/DOCS/tech/nut.txt

Hi

On Wed, Nov 15, 2006 at 02:45:04AM +0000, Måns Rullgård
wrote:
> Michael Niedermayer <michaelnigmx.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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel