[MPlayer-dev-eng] Patches for NUT

[Michael Niedermayer]

Hi

On Thu, Feb 09, 2006 at 03:04:18PM +0200, Oded Shimon wrote:
[...]
> 
> > > > 
> > > > I'm not so paranoid about error detection and this stuff, Adler is good 
> > > > enough for me. We can use a funky 24 bit adler for the syncpoint checksum, 
> > > > 10 bits for s1, 14 bits for s2. Really not hard to implement and not a big 
> > > > complication to spec IMO.
> > > 
> > > Here's my patch.. Please comment.
> > 
> > iam strongly against putting the checksum anywhere except the end of the area
> > to be checked, (it also violates richs no buffering rule)
> 
> Well, forward_ptr of headers already violates that. I think he meant no 
> buffering of frames, which is still kept, you just need to write the frame 
> header in memory, which you would have to anyway if you did checksum.
> 
> > and iam not happy about the 24bit hack either, either store adler32 or crc32
> > everywhere IMHO
> 
> I suppose crc32 then, it's more common...

ok


> 
> > > Other than this, the last issues I'm aware of are:
> > > 1. too big pts - stuck player
> > 
> > several possile solutions
> > A: decide some pts_threshold, and put syncpoints (with checksums) before
> >    all frames which have a pts diff above the threshold
> >    subtitle streams will have large pts diff -> 1 syncpoint per
> >    subtitle packet in not so unlikely cases or pts_threshold large but then
> >    we wont catch many errors, sure the really problematic cases are caught...
> 
> I like this... You can set high pts distance for subtitles and it wouldn't 
> cause stuck player with damage, so that's ok. maybe the pts_threshold 
> should be global and be a pts difference from last frame of any stream.

ok, this seems to fix the main issue i had with A., so iam ok with that


> 
> Makes it kind of hard to measure though, I suppose real time would be the 
> right way... Or basically just specify a timebase and the max pts 
> difference would be a single unit of that timebase (so, 1/2 for making max 
> pts diff without a syncpoint never more than half a second.)
> 
> I like this solution the most.. In implementation:
> 
> tmp = convert_ts(max_last_pts, max_last_pts_timebase, this_timebase);
> if (compare_ts(ABS(this_pts - tmp), this_timebase, 1, max_pts_timebase) >= 0) put_syncpoint();
> 
> Maybe without the ABS. Whatever.

hmm somehow i dont like this, convert_ts & compare_ts are slow, we
should avoid executing them too often, this would need 3xconvert_ts() per
frame on the _demuxer_ side just to check if the pts are ok
a common timebase would only need 1 convert_ts()


> 
> > B: store max_pts after muxing
> >    same problem as A (we wont catch many errors, sure the really 
> >    problematic cases are caught) and theres the issue with storing max_pts
> >    either we seek back or we risk loosing it if the file is truncated
> 
> Obviously this idea has many flaws...
> 
> > C: give syncpoints and frame headers their own checksums, add a checksum
> >    flag to the frame header table
> >    this avoids the 1 checksum covers syncpoint and following header 
> >    complexity and the overhead of case A for large pts frames is 
> >    significantly reduced, there is also no issue with storing the max_pts
> >    after muxing (seeking back or truncation issue)
> > 
> > personally iam in favor of C
> 
> The complexity is litte, syncpoint are always accompanied by their 
> following frame, you can't have a syncpoint without a frame. But I am 
> a bit confused, you want the ability to store a 4 byte checksum for a 3 
> byte frame header? And now both syncpoint and the following frame header 
> needs a total of 8 bytes of checksum? This sounds like horrible overhead. 

8 bytes per 16384 bytes isnt that much, iam just fearing few demuxers will
check the checksum during binary search at all if they need to decode the
following frame header, does/will libnut?


[...]
> > > 2. index_ptr comes out of nowhere when reading the file linearly
> > > 3. split up index?
> > 
> > yes that would be nice
> 
> Well, best I got, just split em up at some syncpoint position, it could 
> work just fine, but I don't really see the point. Damage usually comes in 
> blocks, and yes the index is big, but now you can repeat it. (which is also 
> highly non trivial if you repeat anywhere except EOF and begginning of 
> file, the vlc's will keep changing lengths and hence changing all other 
> vlc's...)
> What is the rule for splitting? Every 5,000 syncpoint? When the index 
> reaches 4kb? (not a good idea, near impossible to measure, because there 
> are 2 parts.)

i think we need to better understand the distribuion of errors on common
media, it would be silly to complicate the index unneccesariely but it
would also be silly if a 1k lost block in a 100k index makes a files
sloooow-seekable

[...]

-- 
Michael