|
List Info Thread: r20926 - trunk/DOCS/tech/nut.txt
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
r20926 - trunk/DOCS/tech/nut.txt |
|
List Info Thread: r20926 - trunk/DOCS/tech/nut.txt
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
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
I was considering the possibility of future hardware
supporting NUT.
>> > 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?
Call it workarounds if you like. Yes, there are some
buffers. That doesn't
mean there are infinite amounts of memory available for more
buffers.
>> 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
These cheap hardware decoders will of course not be able to
handle *any*
stream. The difference between MPEG and NUT is that it is
possible to
create a valid MPEG stream with the necessary constraints.
The data sheet
for a decoder tells you what the requirements are, and you
can then make
sure that the streams meet those requirements, or choose a
decoder that
can handle your streams.
MPEG is often used in closed systems, or in systems will
very well defined
constraints. I see no reason why (a future, complete) NUT
wouldn't be
suitable as a base format in such systems.
>> > * 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?
Yes.
>> > * 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
Oh, 200ms is a terribly long time. It would be really
boring waiting all
that time for a seek to finish.
>> > * 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-devel