[MPlayer-dev-eng] more NUT questions

[Michael Niedermayer]

Hi

On Saturday 17 April 2004 19:39, Ivan Kalvachev wrote:
[...]
> >> > > 11. There is no way to check is frame_type  broken. If there is
> >> > > small
> >> > > broken part in frame_type_0 beginning we will get wrong frame_code.
> >> > > We will read some values. We will seek to some position.
> >> > > And so on, until we jump out of stream, calculate negative or
> >> > > forbidden value.
> >> >
> >> > yes, its always the case, u parse format foobar until u see a illegal
> >>
> >> value
> >> I though that error resistance was one of the main goals. We need
> >> something
> >> to catch possible error (read - spend few more bytes).
> >> One naked byte sitting in the middle of nowhere. This is the weakest
> >> spot
> >> in the chain. After one broken frame_type0, we will lose all frames of
> >> type  after it, even if they are not broken.
> >
> > IMO error recovery at the expense of significant size is not a good
> > tradeoff. You shouldn't have corrupt files lying around... But perhaps
> > there's a way to meet both goals.
>
> It is just an goal priority. I think that in a different thread
> Michael showed that if frame_type0 is not used, the overhead doesn't
> increase dramaticaly.
frame type 1!!
if u drop type 0 there will be 4x larger overhead

[...]

> >> > > Solution 4.
> >> > > GOP. All frame headers at one place. Kinda of #2.
> >> > > Even better, it could be some kind of destributed index.
> >> > > small indexes all over connected with forward/backward pointers.
> >> > > Hmm sound familiar, maybe I have seen it before?
> >>
> >> I think that this is the right solution:
> >> Headers of frame_type0 frames should be packet together with the last
> >> packed_header-ed packet. This way they would be protected by the crc
> >> of the same packet. Anyway if the packet is broken usually demux of
> >> next frame_type0 it won't be possible.
> >
> > WTF?!?! There is no CRC!!! CRC is totally useless.
>
> No. We need some system for validation of packet headers data.
> We cannot afford one broken packet to break the chain.
> Just like I gave example with frame_type0.
>
> If we have broken part, we may read wrong forward pointer,
> we may jump near the end of file and after that to jump out of the file.
please read, the spec or RTFS, this isnt possible, theres a forward pointer or 
if we remove them then a maximum distance for type 1 and or 2 frames, so such 
cases are always detectable

> The demuxer will find the error and will try to resync (look for
> startcode). Unfortunatly we will think that only this packet is damaged and
> we will sync a long after the problematic position.
the demuxer is smarter then u, it will resync from the last correct position 
(last 64bit startcode)

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

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