On Wed, Nov 15, 2006 at 04:50:13PM +0100, Michael Niedermayer wrote:
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? 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?
BTW, I'm against this - if nothing else, we spent a lot of time calculating and figuring out the syncpoint stuff to make sure exact seeking always works. If we did this, we'd have to revisit the issue and make sure nothing breaks. BTW, a fake large decode_delay for the audio stream causes an audio preload. but it is ofcourse illegal. - ods15