Multimedia container is used for creating multimedia files and streams combining multiple types of sensory inputs, especially visual (video) and audio (audio). XBUP protocol generally allows any combination of data, so it is appropriate to define the term container differently. Container is here meant primarily for non-interactive presentations.

The aim of this container is in addition to video and audio storing also to provide support for other data types such as text descriptions and titles, or for example to store information about smelling, taste and touch, environmental conditions (temperature, humidity, lighting) and various effects. XBUP technology should allow a separate implementation of aspects and their subsequent combination with defined handling techniques.

The aim is to enable the use of the experimental container for the widest range of applications. The aim is to capture static multimedia data with the duration and also the possibilities of interactive walk-through options (menu).

• Multimedia files
• Multimedia streaming
• Environment data with time-course
• Presentations and animations

In the standard case, XBUP protocol will be used only as a some kind of data stream header, where to maximize effectiveness the rest of data will be stored as stream in extended area. To save a file with a variable header it should be possible to include some empty zone in the beginning of the file, which would minimize the need for rewriting the entire file in case of frequent changes.

Following definitions are related to this format:

• Keyframe - This is such a time frame from which you can start playing the file without reading any previous data. Key frames are possible for the entire container, or even for individual streams. In the case of jumping to a location that is not a key frame, closest previous key frame is used for playback, and followed to the desired time (fast forward).
• Color spaces: YUV, YCrCb, RGB
• Sampling -
• Framerate

Generally, the container consists of the following components:

• Header
  • Chapters (temporal distribution)
    • Data streams (topic/space distribution)
• WR14: XBUP_Project/Meta/Containment

Basic block size determines the separation of the container in time. The following are the blocks which determines the count, type and data representation of each stream.

The following block defines the distribution of video on time-separated part of so-called chapters…

The aim is to enable at least the same functionality, which allows existing format. The effort is to choose the most common and most advanced. Container format are for example AVI, OGG, MP4, Matroska MKx, Quictime MOV, Real Media RMx, Windows Media ASF/WMx, MPEG-PS, MPEG-TS.

The aim of the Matroska project is to create a multimedia container based on well-defined and extensible binary format EBML with the following advantages over other existing technologies:

• vint - integer values of variable length
• support for multiple audio/video/subtitle streams

And more. Matroska is gradually gaining more support, but it might reach it's extensibility limits as EBML is no longer developed and it has some forward compatibility issues which renders the future of Matroska at least a bit problematic.

Structure of the file is as follows:

• Header
• Meta Seek Information
• Segment Information
• Track
• Chapters
• Clusters
• Cueing Data
• Attachment
• Tagging

[Matroska] Multimedia Container, URL: http://www.matroska.org
[EBML] Extensible Binary Markup Language, URL: http://ebml.sf.net