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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Wed, Nov 15, 2006 at 01:47:07PM -0000, Måns Rullgård wrote:
> [...]
>> >> 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.
>
> well, is the dts ordering the only thing preventing use of nut in such
> a system?

The answer to that obviously depends on the exact system, and on what
other rules NUT has.

> would addition of a delay field to each stream header which would then
> be added to all timestamps in that stream solve the issue?
> would a maximum 250ms on such a field be enough?
> and some additional rule like delay MUST be 0 unless the file is encoded
> for a specific specification requireing a larger delay?

That seems unnecessarily complicated.  Simply allowing an offset
between streams would be enough.  A global header could give a maximum
value for the offset in the file.  There is no need to require a
constant offset, even though I can't immediately think of a situation
that would benefit from it being variable.  Placing a reasonable hard
upper bound would still make non-interleaved files invalid.


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