[MPlayer-dev-eng] container format

[Michael Niedermayer]

Hi

On Thursday 06 February 2003 19:06, Christof Buergi wrote:
> Hello there...
>
> Am Mittwoch, 5. Februar 2003 17.57 schrieb Moritz Bunkus:
> > I'd really like to see a new container format soon.
>
> <AOL>me too ;-)</AOL>
>
> I'd be happy to contribute. Unfortunately, lack of time is a problem
> with me, too. :-( But feel free to ask. I will tell you, if I can't do
> it. ;-)
>
> Well, and there I have some thoughts about the format:
>
> 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 
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

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

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

> 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

>
> Lastly, I have a questions about VLC. I'm not quite sure, what you're
> meaning, so I'm asking you: Do you mean a "variable length coding",
> thus enabling you of using blocks with variable lengths and still being
> able to find the borders of the blocks when the file is damaged?
VLC means "variable length coding", it means that the individual 
fields/variables like width & height are not encoded with a constant number 
of bits 

[...]

Michael