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

[Måns Rullgård]

Michael Niedermayer said:
> 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

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 at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
>
>


-- 
Måns Rullgård
mru at inprovide.com