r20926 - trunk/DOCS/tech/nut.txt

Michael Niedermayer <michaelnigmx.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
mruinprovide.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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