[MPlayer-dev-eng] container format

[D Richard Felker III]

On Thu, Feb 06, 2003 at 07:30:27PM +0100, Michael Niedermayer wrote:
> > First and foremost: Using checksums to detect transaction errors, in
> > order to re-get the packets, is rather pointless. Because:
> >
> > 1. When using TCP, this is already done by the network stack.
> > 2. When using UDP, re-getting a wrong packet is normally not an option.
> >
> > It still can be used in order to detect a defective packet, so it hasn't
> > to be decoded. But this limits it's usefulness. Hence, it should be an
> > option, not required.
> hmmmm, i think u missunderstand the checksum slghtly, the idea is that u 
> download a file somehow from somewhere ;) after or during the download  u 

Hmm... :)))))

> notice that its damaged (by checking the checksum, or seeing the image break 
> into ugly blocks, ...) after that u redownload the damage parts from 
> somewhere else, all that could be automatic or manual, but it only works if 
> we can check the file, yes decoding everything to detect errors is possible 
> to but its slower and more complex

Agree. BTW this is just an implementation detail, but IMHO the demuxer
should not compute or compare checksums (unless specifically asked to
with a debug option) since it's a waste of cpu time and doesn't do any
good.

> > Alternative: We could use a Forward Error Correction. True, this is a
> > bandwidth eater, and yes, it should be optional. But it could prove to
> > be *very* useful for transfers over a UDP connection.
> yes, fec is nice, but i dont see why this should be included in the 
> fileformat, IMHO a idependant format like gzip would be better, actually iam 
> working on that since some time :)))) but i have too many other things to do 
> :(

Agree, it's silly to waste bits on error correction. Detection is more
than enough already.

> > Second point are some small suggestions about indeces. I think, we
> > should place the index at the end of the file. Having it at the
> > beginning would be nice for playback, but it would be a nightmare to
> > correctly mux this.
> IMHO, we could allow both, and even allow the index to be repeated

Muxing index at beginning shouldn't be hard assuming you know movie
length. Just estimate number of keyframes at the beginning and leave
an appropriate size space, then go back and write it at the end.

> > Also, gzip might actually be a better joice here
> > then bzip2. But this is a matter to try.
> the index is <10kb per hour, IMHO its not worth to g/bzip it

Agree. It's a pain for the demuxer to depend on compression libs.

Rich