[MPlayer-dev-eng] A few minor things about NUT
michaelni at gmx.at
Sat Jan 28 18:04:43 CET 2006
On Sat, Jan 28, 2006 at 05:50:21PM +0100, Michael Niedermayer wrote:
> > > 5. convert_ts() overflow behavior
> > > _IIRC_ this can overflow if timestamps are > 10 or 50years or so
> > > is that an issue, it could be fixed if it is ...
> > Uhh, let's say you use timebase sampling rate for audio, 44100..
> > If I did my math right, that's 13264000 years until 64 bit overflow, not
> > sure how many bits convert_ts gives you before overflow, either way, I
> > think by then we'll have native 128 bit math...
> lets say your timebase is 31bit/31bit (thats legal and with AVI as source
> you will have no difficulty finding such files ...)
> the value within the () of (ln/d1*sn + ln%d1*sn/d1)/d2 is the dst_timestamp *
> the dst_numerator if we assume 64bit unsigned then we have 33bit left for the
> timestamp -> <300 years
> > > 6. behavior of damaged files on slow media (cdrom/dvd use case)
> > Well, what do you expect to be done? you can't just guess where the damaged
> > area stops, you have to linear search it... you could use the index to
> > do a syncpoint binary search i guess, but thats about it.
> 6a. damaged header (detect, search copy, go back play file)
> 6b. damaged index (very slow seeking, tell user to buy/make new cd)
IMHO we need to make the index more robust against errors, maybe even
repeat it once at the end (<file><index><index>)
> 6c. damaged pts or back_ptr during binary search
> maybe we should add a checksum to the syncpoints so the pts&ptrs are
> 6d. damaged frame size (MUST be detected or we skip the whole file, but how?)
> originally forward ptrs allowed trivial detection but richs no buffering
> rules killed them
> with just the syncpoint placement rules its more tricky, if the framesize
> is larger then the max syncpoint distantance there should be no syncpoint
> before the end and one at the end of the frame, we cant check the end as
> that wouldnt solve the issue for notseekable streams
> so we would have to speculatively linear search until the next syncpoint
> that should be mentioned in some error robustness section
> maybe (optionally) store some max framesize for each stream?
could be solved by including the first framecode after a syncpoint
in the checksum at the syncpoint
More information about the MPlayer-dev-eng