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

[Rich Felker]

On Wed, Nov 15, 2006 at 09:22:05PM +0200, Oded Shimon wrote:
> > > 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.

Any nonzero offset between streams is absolutely totally out of the
question for reasosn I described in other posts. There's no need to
even consider this topic. Can we drop this useless thread?

Rich