[MPlayer-dev-eng] A few minor things about NUT

[Michael Niedermayer]

Hi

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
>     protected?
> 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


[...]
-- 
Michael