[MPlayer-dev-eng] Patches for NUT

[Michael Niedermayer]

Hi

On Fri, Feb 03, 2006 at 09:07:38AM +0200, Oded Shimon wrote:
> On Fri, Feb 03, 2006 at 08:58:51AM +0200, Oded Shimon wrote:
> > eor in index, 01-eor-index.patch

ok


> > 
> > accurate compare_ts, 02-compare_ts.patch

there is something i dont like ...
we should not force a specific implementation here which this more or less
does, instead we should specify things more like:
compare_ts
    Compares timestamps from 2 different timebases, 
    if a is before b then compare_ts(a, b) = -1
    if a is after  b then compare_ts(a, b) =  1
    else                  compare_ts(a, b) =  0
care must be taken that this is done exactly with no rounding errors, simply
casting to float or double and doing the obvious a*timebase >/<= b*timebase
is not compliant or correct, neither is the same with integers, and
a*a.ts.num*b.ts.den >/<= b*b.ts.num*a.ts.den will overflow
one possible implementation which shouldnt overflow within the range of
legal timestamps and timebases is:
comare_ts(a, b){
    if (convert_ts(a, a_timebase, b_timebase) < b) return -1;
    if (convert_ts(b, b_timebase, a_timebase) < a) return  1;
    return 0;
}


> > 
> > remove 2^n header restriction, 03-header-repeat.patch .

ok


> > 
> > index repetition, 04-index-repeat.patch

ok


> > 
> > 
> > Regarding error recovery michael suggested, checksum for frame header etc.
> > I dislike it, it complicates binary search when looking for startcodes.
> > Rich already proposed a solution to prevent loosing the entire file - if
> > you see a frame with abnormally high size immediately after a syncpoint,
> > while reading the frame (which you have to anyway), linear search entire
> > area for possible syncpoint. The worst that will happen is that you'll skip
> > the entire damaged area in that single frame, and that's actually a good
> > thing...

ok, but that still leaves the issue with abnormally high pts and damaged pts
during binary search

[...]

-- 
Michael