[MPlayer-dev-eng] more NUT questions

[Michael Niedermayer]

Hi

On Saturday 17 April 2004 23:47, Michael Niedermayer wrote:
[...]
> > >> And yes, there MUST have crc. We may not calculate crc for the whole
> > >> packet, but only for the header(s). This may allow smaller crc (1, 2
> > >> bytes).
> > >
> > > What good does this do? Knowing that the data is corrupt is totally
> > > useless unless you can repair it. All CRC does is waste space. CRC is
> > > absolutely not acceptable!!
> >
> > Well, ther are error correction codes available. I have seen
> > e.g. rar file to repair and fair big chunk of bytes (512),
> > using only 1% overhead (in 1mb file).
>
> ROTFL 10k parity data and 512bytes fixed
>
> > I'm not very skilled in this area but this is the only
> > way to learn:)
>
> RS codes can correct n/2 symbols with arbitrary and unknown positions if
> there are n parity symbols, or they can correct n symbols with arbitrary
> but known positions if there are n parity symbols
> so if we take an RS code over GF(2^8) with 2 bytes parity, and interleave
> 4096 such codes then we can correct a 4k bytes block if we dont know its
> position, and if we do know the position we could fix a 8k byte block with
> 8kb parity data in a ~1mb file
implementation finished, see attachment :)

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: siec.c
Type: text/x-csrc
Size: 3491 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040418/39f56135/attachment.c>