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

[michael c]

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.

>if we ever support menus then IMHO, we should only store the logical
>information in the file like various alternative scenes, but not some >menu 
>image + script ...

you could do that, or use an image/script or both or whatever you like i 
guess. just pick a fourcc and implement it. if the demuxer knows how to use 
it or how to pass it on, it will. and if not, then it can easily be skipped.

mike


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail