[Ffmpeg-devel] Wrong duration in a nut container

Michael Niedermayer michaelni
Fri Aug 12 22:04:30 CEST 2005


Hi

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?  

yes


> 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.

well, complete timestamps only have to be stored at sync points, the 
other packets can store either a full one or timestamp differences 
relative to the last frame of the same stream or they store only a few of
the least significant bits, later is more robust against errors but a 
little larger then delta timestamps

[...]
-- 
Michael





More information about the ffmpeg-devel mailing list