[Ffmpeg-devel] Wrong duration in a nut container

[Rich Felker]

On Fri, Aug 12, 2005 at 07:11:44PM +0100, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > On Fri, Aug 12, 2005 at 11:02:23AM +0200, Reimar D?ffinger wrote:
> >> Hi,
> >> On Fri, Aug 12, 2005 at 10:31:00AM +0200, Michael Niedermayer wrote:
> >> > and if the file is on something non seekable?
> >> > its a question which is more important, the validity of the duration
> >> > field in randomly cut raw pieces or the availabilty of the duration 
> >> > in non seekable streams
> >> 
> >> Well, my opinion is that knowing the duration in non-seekable streams is
> >> not so important - especially since in quite a few applications
> >> (e.g. streaming) the duration will not be known anyway.
> >> Also adding the duration at a special place also means one more piece of
> >> redundant information - and from my experience with multimedia, this
> >> means in at least 1% of cases this will just contain some random crap
> >> :-(.
> >> But the approach of seeking to the end and reading the last timestamp
> >> reminds me a lot of MPEG where this just doesn't work at all...
> >
> > It only fails on mpeg because mpeg is allowed to have broken
> > timestamps. NUT strictly forbids timestamp discontinuity and
> > nonmonotonicity.
> 
> Can NUT support never-ending streams like DVB?  The only way to avoid
> timestamp wrapping is to use a large number of bits for the timestamp,
> and we all know you wouldn't like that.

nut uses uvlc timestamps, unlimited range. also, anyone sane will use
a proper timebase, so even very very long streams will not need very
big numbers. for fixed fps streams, timebase should just be
1/framerate, and for variable fps it's 1/lcm(framerates).

anyway like michael said, the timestamps are also not stored fully for
every packet, just lsb or delta (preferably lsb, but delta is more
compact and it can be robust in some situations).

rich