[MPlayer-dev-eng] Patches for NUT

[Oded Shimon]

On Fri, Feb 10, 2006 at 03:51:59PM +0100, Michael Niedermayer wrote:
> 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

Hmm, I used the const you said earlier (0x1EDC6F41) . Seems Ogg uses 
0x04C11DB7 . Byte ordering is global and well defined for NUT ....

Are you still against crc being immediately following syncpoint startcode? 
It's the most natural position for it. Having it after frame header is very 
weird, and having it at end of syncpoint is even worse as it is in the 
middle of the area it checksums.
I'm also still a bit hesitating about the overhead of adding 4 bytes per 
syncpoint, but I guess it's ok.

One more issue - now that index does not mark EOF as it can appear 
anywhere, the index_ptr comes out of nowhere, the demuxer can even mistake 
it for being a frame startcode (It could even appear as a NUT startcode!).
So I suggest making a end_startcode before the index_ptr...

- ods15