[MPlayer-dev-eng] Nut, few ideas

[D Richard Felker III]

On Tue, Apr 20, 2004 at 04:55:50PM +0300, Ivan Kalvachev wrote:
> ok
> 
> So, we get some flaming each other.
> Here is summary of my proposals about nut format.
> (not yet finished)
> 
> In summary.
> making main header startcode in human readable format.
> add maximum known vlc size limits.

There's really no good reason for vlc size limits. Naturally it
doesn't make sense for any quantity to be larger than the addressing
scheme used for files...or rather, a computer will not be able to play
a nut file that has offsets larger than the maximum filesize. :)

Yes, having limits would allow error detection, but it also inhibits
extensibility in the future. There's no reason that 20 years from now,
someone shouldn't be able to have 80+ bit file sizes...

> For now I keep the checksum at the end. But I don't like it.
> As packet headers are written in memory buffers it doesn't really
> matter.

I assume you mean the checksum for header packets, since normal
packets don't (and won't!) have checksum.

> Removing frame_code compression and using another flag scheme.

I mostly agree. But only if it can be made efficient. IMO a good
criterion is that vorbis-in-nut must be smaller than vorbis-in-ogg. :)

> TODO:
> Creating an distributed index - small indexes
> at fixed size block (16k), describing nearly 2 hours of the movie.
> all pointers in, are relative to the index.

This is useless and overcomplicated. The index isn't necessary, but
for convenience (O(1) seek) one can be stored at the END of the file,
once it's known.

> Additional pointer to the next index.

Impossible. There's no way to know where the next index will be.
Rejected.

> Additional packet type for error resistance. It is fixed size
> contains all packets, but without backward_pointers and framedata.
> The data is mixed and distributed across the file and
> protected with error correction code.

This is a huge waste of space. And it cannot be written sequentially.
Rejected.

Rich