Media Package Format White Paper
This was taken from zzorn's recent post (Subject: [WF-Client] Media Package Format and Client Side Media Library Date: 04 Feb 2002 20:45:08 +0200) to the WF-Client mailing list.
Hello,
We will need some common format for media packages, and conventions of how they are handled. I don't know if this has been discussed already in connection with the media repository, but my impression is that there is no common agreed upon media package format.
The idea presented below specifies a media package format that describes the package and links to contained media files of different types, and a client side media library that implements media downloading, caching, handling / decoding, and gives clients freedom in the way they treat media by allows them to register custom handlers for different media types.
If the general concept is accepted after review, the next step would be to specify the package format and start the design of the client side media library.
Please comment, and suggest improvements or possible alternative solutions.
Requirements
We want to support multiple media types, and we don't know all the possible media types in advance.
We need media for various purposes; for entities in the game, for terrain textures, for background music, for UI themes of different clients, and perhaps even for interface customization files or script files for different clients.
Sometimes the media is automatically retrieved by the client, sometimes the user can browse the media repository and download interesting stuff (through a browser, or through the client itself), such as client skins or background music.
Media often needs to be parametrized before use, this is done by providing the media handler in the client side media library with a set of key=value parameters or similar for this specific use of the media (in the case of media for entities, these parameters could be given by the entity, and could describe the way that particular entity instances appearance is unique from other entities of the same type.)
Note that parameters always should have default values, and need not be provided when accessing the media from the client. The possible keys could perhaps be queried from the client side media library, but the package format should not contain any information about them, because they are used to control how the media handlers generate output data.
To ease the use of media of different types in the clients, a client side media library should be created, that can be used in different clients. It should take care of downloading requested media and caching it. It should have a mechanism to allow clients to register handlers for various custom media types that the client understands, and could also come with default handlers for common media types. The handler gets passed eventual parameters when a media instance is requested by the client.
The media handlers used in the client side library produce some output data that the client understands. This is sometimes just the original data, but in some cases new modified data is generated. It could be generated directly into a client specified context or structure, or be stored and handled by the media library, if the data is such that it makes sense to cache it.
For example, a procedural texture media type could have an own handler that generates the texture, and allows the client to request it as a normal bitmap. The handler could instruct the media library to cache the generated data.
Media Type Examples
Some examples of possible media types:
- Textual description.
- 3D high/low poly model, using an own set of textures.
- 3D high/low poly model, using template textures that are replaced with actual textures before rendering. The entity instance that is to be rendered contains a reference to a TextureSet media file.
- TextureSet description file, that maps various keys to existing textures, or a number of alternative textures, from which one is picked randomly (based on a random seed given as a parameter to its media handler).
- Texture
- 2D sprite, with views from N number of different directions
- Animated 2D sprite, with a number of different animation types, seen from N number of different directions.
- Sound effect
- Music (ogg)
- Tracker music (xm, etc)
- Procedural texture (possibly taking some parameters as input to customize it).
- Procedural (L-system based) plant model (the media handler for it could accept parameters such as age and health, and could be able to produce both 3D models and bitmaps as output to the client).
- Client UI Theme.
And so on.
Not all clients need to support all different media types, and not all different media types are present in each media package.
Media Package
A media package could be a lightweight structured document (for example xml or atlas based). It has a name (unique?), id? (unique), description, license, version number, and version history. The version history contains entries with version number, date, author doing a change, and a comment about what was changed.
It could also have a list of required, optional, and recomended other packages (research into exsiting package system such as debian and rpm3(?) could be done to get additional ideas of what kind of package management and version dependency we are likely to need).
This way we could also have 'virtual packages', that is, packages that list some other packages as required, but don't themselves have any associated media files.
Each media package would also have a list of the media files it contains. This list would contain the media file type, an exact filename or id, the current revision number of it, and a version history for it. The version history contains entries with revision number, date, author doing a change, and a comment about what was changed.
So the media package file in itself doesn't contain all the media data.
Logistics
The media repository would contain the media package files, as well as the media files themselves.
Clients would use the media library to download the media packages (not the actual media files yet), and then when some media is needed from some package, one format is selected based on which ones are available in that package, what media formats the different media handlers in the media library support, what types of media the client supports, and what preferences the user has specified.
The media files, and intermediate output data for the client generated by the media type handlers, are cached on the client. Least used / most un-recently used data is cleared from the client side cache (generated data first, because it can be re-generated without downloading) when it starts to grow full.
Media authors can use various tools to update media packages. When some file in a media package is updated, an event is added both to the version history of that file in the package, and to the version history of the package itself.
A media file could perhaps be shared between multiple packages too.
A central repository is probably used for uploading, and is mirrored by media servers that clients use.
| Current Issue: February 2003, Recent Issues: January 2003, November 2002, October 2002 |