[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.7,1.8

[Michael Niedermayer]

Hi

On Friday 07 February 2003 15:32, Andreas Hess wrote:
> On Fri, Feb 07, 2003 at 02:44:27PM +0100, Michael Niedermayer wrote:
> > On Friday 07 February 2003 13:57, Andreas Hess wrote:
> > > And what about no checksum at all in plain frames, allowing the
> > > checksum (or frame_checksum) just in keyframes, and there the
> > > checksum is the checksum (or frame_checksum) over all previous
> > > frames.
> >
> > hmm if only the keyframes contain the checksum, then each keyframe would
> > contain the checksum for the previous frames ...
> > the last frames after the last keyframe would have no checksum
> > and if we cut the stream at a keyaframe than its checksum would cover
> > frames which are no longer there, this seems bad, so IMHO the current way
> > of requireing the checksum to be in the last frame before a keyframe (or
> > more often) is better
>
> Ok, I see, but what about making the checksum forward calculated?
u mean storing the checksum for the future frames ...
seems difficult, for write only stuff like realtime streaming we cant write te 
checksum later into the previous keyframe, and i dont see any advantage in 
this even if its possible, so iam against it unless u have some example where 
it would provide an advantage

>
> And the checksum, over what part is it calculated, over the header,
> the payload or over the whole frame? Maybe it would just be enough
whole frame, so damaged frames can be found and redownloaded ...

> to calculate the checksum over the headers to guarantee, that the
> structure of the file itself is ok, and leave the correctness of
> the payload to the respective codecs.
the filestructure is very hard to trash, all packets except the frame headers 
have 64bit startcodes, so they can be found even if they get scrambled around 
randomly, all packets allso have forward & backward pointers, so if they get 
damaged then they wont match anymore, the demuxer then just has to search for 
2 valid forw/backw pointer pairs to resume playback or follow the backward 
pointers from the next keyframe which can be found easily by searching for 
its 64bit startcode
all headers except the (key)frame headers allso have checksums so we know if 
they got damaged, and the frame headers really dont contain that much which 
can be damaged, theres just the flags, stream id & timecode
only a few stream ids are valid and the timecode allso wont be random normally 
so it might be detectable often, a crc32 checksum would be about as long as 
the whole frame header, so it seems like a bad idea IMHO, and another 
question is what should be done if the crc doesnt match, drop the frame?
that would happen most of the time anyway if its start is trashed or we pass 
video packets to the audio decoder if teh stream_id got killed

[...]

Michael