[MPlayer-dev-eng] container format

[D Richard Felker III]

On Thu, Feb 06, 2003 at 04:48:58PM +0100, Michael Niedermayer wrote:
> i didnt seriously plan it yesterday but, it seems alot of ppl want a new 
> container format (asf,mov/mp4 are patented AFAIK, avi/rm sucks, ogg has alot 
> of unneeded overhead, and seems more designed toward audio instead of video, 
> at least the docs i found are quite audio specific, it surely could be 
> improved though ...)

All I can say, is that if ogg was designed toward audio, I'd hate to
see how bad it would suck for audio if it weren't! Seriously, the
page-granularity is horrible for audio! It inhibits precise seeking,
and if the page checksum is bad, a whole page of audio (typically 8k)
will be dropped, leaving a nasty gap in the song.

> anyway, first draft of the MPlayer container format is in DOCS/tech/mpcf.txt
> comments VERY welcome :)

Excellent! Glad to hear that you're taking this plan seriously. It's
also quite amusing that the Matroska and MCF people take months to put
together a crappy spec, and that you put together something much
better pretty much overnight. :))

Naturally, it still needs some review and discussion before we go
implementing it, but very cool nonetheless. I read through it and most
things look good.

One comment...it seems like one of the things you were a bit undecided
on is repetition of headers. I'd like to recommend requiring headers
for ALL streams to be repeated whenever headers for any stream are
repeated. Maybe you already had that in mind. Anyway that should
simplify playback of cropped/broken files, especially in cases where
the codec-specific headers are necessary.

One other issue...do you know how big codec-specific headers can be? I
didn't do much research on the internals of vorbis, but in my radio
server I ended up sending the first two pages of the current file to
clients when they connect, which amounts to around 4k. Hopefully some
of that is the beginning of the encoded audio and not the header
stuff, but it's probably important for us to look into how big
codec-specific headers might be before requiring that they be repeated
at a fixed interval.

And one question...how do we plan on handling non-integral framerates?
(29.97 and 23.976 come to mind... :) Is the time base a fixed point
number, and if so, do we need to specify the precision on a per-file
basis?

Rich