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
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|