[MPlayer-dev-eng] Patches for NUT

[Michael Niedermayer]

Hi

On Fri, Feb 10, 2006 at 02:48:23AM -0500, Rich Felker wrote:
> On Fri, Feb 10, 2006 at 02:34:30AM +0200, Oded Shimon wrote:
> > On Thu, Feb 09, 2006 at 06:43:30PM +0100, Michael Niedermayer wrote:
> > > On Thu, Feb 09, 2006 at 03:04:18PM +0200, Oded Shimon wrote:
> > > [...]
> > > > > 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
> > 
> > Can I use the lutless crc in libnut or is it unusably slow? The biggest 
> > single chunk passed to it is 80kb index, and a total of 200-300kb of 
> > syncpoint data, with 15 byte chunks 30,000 times...
> 
> IMO it's no problem at all. Reading headers does not need to be fast,
> and it won't be slow for summing 10-15 bytes. In fact for this
> purpose, I expect overall decoding will be faster than with the
> table-based one because it won't pollute the cache with tables.

i fully agree with that for the headers, and the same might be true
for the syncpoints, but what about the index? its maybe 100k ...

anyway, it shouldnt matter, the user can calculate crcs with as large or as 
small tables as he wishes, for example:

static const int tab[16]={0x00000000, 0x00000000, 0x00000000, 0x00000000,
  0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
  0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000};

for(i=0; i<size; i++){
    crc ^= buf[i];
    crc = (crc>>4) ^ tab[crc&0xF];
    crc = (crc>>4) ^ tab[crc&0xF];
}

so this isnt a big issue, we just need to decide which generator polynom we
want to use for NUT CRCs, and we should check that its bit ordering and byte
ordering matches the most commonly used one


[...]

-- 
Michael