[MPlayer-dev-eng] Patches for NUT

[Michael Niedermayer]

Hi

On Thu, Feb 09, 2006 at 07:55:54AM +0200, Oded Shimon wrote:
> On Tue, Feb 07, 2006 at 01:48:25PM +0200, Oded Shimon wrote:
> > On Tue, Feb 07, 2006 at 12:04:07PM +0100, Michael Niedermayer wrote:
> > > On Tue, Feb 07, 2006 at 06:04:11AM +0200, Oded Shimon wrote:
> > > > On Mon, Feb 06, 2006 at 03:39:23PM +0100, Michael Niedermayer wrote:
> > > > > yep, wanted to comment on that anyway ...
> > > > > adler isnt the best checksum around, but its fast and simple
> > > > > the adler checksum is made of 2 parts s1 and s2
> > > > > 
> > > > > [...]
> > > > 
> > > > So, in conclusion.... ?? What should we do? Add adler32 for the syncpoint? 
> > > > Something else?
> > > 
> > > maybe switch to crc32 everywhere, iam not sure
> > 
> > I hate the LUT spam of crc32. Although it is ofcourse easy to implement...

#define G 0x1EDC6F41
int lutless_crc(uint8_t *buf, int size){
    int i, j, crc=0;

    for(i=0; i<size; i++){
        crc ^= buf[i]<<24;
        for(j=0; j<8; j++)
            crc = (crc<<1) ^ (G & (crc>>31));
    }
    return crc;
}


> > 
> > 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)
and iam not happy about the 24bit hack either, either store adler32 or crc32
everywhere IMHO


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


> 2. index_ptr comes out of nowhere when reading the file linearly
> 3. split up index?

yes that would be nice


> 4. info streams and back ptr - imo nothing should really be done about 
>    this, just suggest to either use eor or repeat info frames.
> 5. droppable flag for frames

i dont strongly care either way, and it seems we can add this later


> 6. split up index somehow?

duplicate of 3. ...


> 7. frame repetition flag?

iam in favor of it ...

[...]

-- 
Michael