[MPlayer-dev-eng] Re: MCF ( Multimedia Container Format ) : Invitation to participate

[Michael Niedermayer]

Hi

On Sunday 09 June 2002 11:10, Christian HJ Wiesner wrote:
> Attention ! please use the 'reply all' function of your mail application to
hmm, ok

> make sure a copy is sent to the mailing lists of mplayer and MCF. If this
> discussion is going on we might consider setting up a specific mailing list
> titles 'mplayer-MCF-cooperaion' or similar.
[...]
> Michael Niedermayer ( ein Bayer, wie ich ;-) ?? ):
no, iam from austria, i never was in bayern/germany ...

i did read thorugh the mcf stuff quickly now, here are my comments

everything seems to contain a checksum, thats nice but ...

1. more advanced video codecs can recover most data even if a frame is damaged
a. data partitioning (decode motion vectors & dc even if the texture is lost)
the texture is indeed the least important & biggest part so its most likely 
damaged)
b. slice resync (allows resyncing within a frame after an error)
c. rvlc (allows bidirectional decoding)
the first 2 are completly implemented in ffmpeg/libavcodec
imho droping a frame completly if its damaged is a bad idea

2. detecting errors is nice but correcting them is nicer ... the headers are 
stored only once? it seems so, allthough it would be better to store the main 
header and other important parts at least twice, the checksum could then be 
used to select an undamaged header & even replace the damged one with the 
undamaged copy, this would allso require to add some identifer to each header 
so it could still be found in an badly damaged file (this seems to be done 
for some headers (32-bit id & 32-bit checksum))

it seems that several parts do contain offsets relative to the file start, 
this doesnt seems to be a very good choice (insertion/deletion errors) 
storing file offset differences between the relevant parts should be more 
error tolerant

as i allready mentioned in my last mail, a 64-bit id for each keyframe would 
be nice to allow seeking if the file is damgaged (as the seek entries store 
offsets from the filestart, a single inserted byte will make the them useless)

bidirectional pointers for blocks would make recovering non-keyframes much 
easyer without bloating the file up by much (a byte insertion error in one 
block would make the blocks upto the nextkeyframe difficult to find (if the 
keyframes contain 64-bit ids, otherwise all data afterwards would be 
difficult to find) 
"difficult to find" means that its possible to check by brute force if each 
byte might be the start of a block (by checking timecode order, using 
blocksize and folowing blocks, ...)

it would be possible to use 16bit entries for many things which are stored as 
32bit curently, the idea is to use esc coding if the value doesnt fit in the 
16-bit type, this would save some more overhead
example: 0x12->     00 12
example: 0x123->    01 23
example: 0x1234->   12 34
example: 0x12345->  00 00 00 01 23 45
example: 0x123456-> 00 00 00 12 34 56
example: 0x1234567->00 00 01 23 45 67

[...]

Michael