[MPlayer-dev-eng] container format

[Michael Niedermayer]

Hi

On Thursday 06 February 2003 17:39, D Richard Felker III wrote:
> 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.
hmm, are u sure its droped completly if the crc doesnt match? if it is then 
its really lame, but i doubt it

>
> > 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, 
yes, fully agree

> 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.
yes, i thought thats clear from 
"headers may be repated, but if they are then they MUST all be repeated 
together
and repeated headers MUST be identical"

feel free to change the words (simply cvs commit) to make it more clear

> 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.
IIRC vorbis really has 4k headers ...

[...]

Michael