[MPlayer-dev-eng] MPCF Draft/Discussion (MPlayer ContainerFormat)

[Michael Niedermayer]

Hi

On Friday 07 February 2003 14:41, michael c wrote:
> Hi,
>
> >yes, we can allways add more packet types, stream types, or even fields
> >to most existing headers, without breaking existing demuxers, that should
> >be enough for most advanced features, there are allso info packets which
> >contain information (author, title, ...) about specific parts of the
> >file, these should be fine for chapters
>
> Okay, I see where you're coming from now. I guess I am just proposing a
> different philosophy.
> You put together everything that's needed for the file format (and I think
> it's great from what i can see so far!). Then you and others thought about
> what else could be needed (optionally), so you made a definition for an
> info_packet and stuffing_packet (and the index might maybe be optional
> too?).
> What my idea is - and i think it's much more extensible - is to use a
> "universal_packet" instead of those two or three optional ones, then give
> this universal packet some kind of "fourcc" so you can put ANYTHING you
> like in it.
> so you would have something like this:
>
> universal_packet:
> 	packet header
> 	packet_startcode			f(64)
> 	"fourcc"				v
> 	data_length				v
> 	for(i=0; i<data_length; i++){
> 		data
>         }
> 	reserved_bytes
>         checksum				u(32)
>
> and into the data part you put the stuffing, the info data or the index
> data. For example, for the index you use the fourcc "INDX", and put your
> index into the data section. the demuxer finds the universal packet, sees
> that its an INDX and treats it like that (since it knows its structure). or
> it finds a universal_packet "STFG" (stuffing), knows that it's just
> stuffing and skips it. Or it finds a universal_packet with "MENU" or "CPTR"
> (chapter), realizes that it knows nothing about anything of that type and
> skips it (or passes it to some other external program/decoder?). Or maybe
> it does know it and uses it.
> As you can see, with this approach there would be no need to touch the file
> format later to implement additional packets or something any more.
> everything would already be there. you would only need to think of a new
> "fourcc" for a new feature, put its data into a universal package and
> you're done.
> since you need to know the data format if you make info and stuffing and
> index seperate packages too anyways, this isn't any more complicated
> either.
but whats the difference between a new fourcc & a new 64bit startcode? its the 
same, except that the fourcc adds another layer which isnt needed, and we 
should allso update the docs for a new fourcc if its used in such a way as 
for new packet, or its an undocumented feature and it would cause 
interoperability problems, i mean there are more players then 1 so it must be 
documented or others have to guess / reverse engeneer it, this isnt 
acceptable

[...]

Michael