SkeletonHeaders: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
(started page)
 
(added more details)
Line 15: Line 15:




=== Role ===
=== Content-role ===


=== Content-language ===




=== Track order ===
=== Track order ===


In many applications it is necessary to walk through all the tracks in a media resource and address tracks by an index.
In many applications it is necessary to walk through all the tracks in a media file and address tracks by an index.


In Ogg, the means to number through the tracks is by the order in which the bos pages of the tracks appear in the Ogg stream.
In Ogg, the means to number through the tracks is by the order in which the bos pages of the tracks appear in the Ogg stream. If a file is re-encoded, the order may change, so you can only rely on this for addressing if the file doesn't change.


For example, a video file with the following composition would have the following indexes:
For example, a video file with the following composition would have the following indexes:
Line 33: Line 35:
* track[5]: Vorbis BOS for audio descriptions
* track[5]: Vorbis BOS for audio descriptions
* track[6]: Theora BOS for sign language
* track[6]: Theora BOS for sign language
This track order is simply to have a means to address tracks through an index. It has no influence on what should be displayed on top of which other track.

Revision as of 01:37, 20 March 2010

Adding Required Headers to Skeleton

With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.

One particular such use case is dealing with multitrack audio and video, such as in videos with multiple view angles encoded in one, or ones with a sign language video track, an audio description audio track, a caption track and several subtitle tracks in different languages (i.e. several theora, several vorbis and several kate tracks).

While encoding of multitrack files is already possible, it is unclear how such files would be rendered, how tracks would be differentiated and addressed (e.g. from a JavaScript API), etc. Skeleton has been built in a way such that it is extensible with message header fields for this purpose.

On this wiki page, we are collecting such new information fields.


Content-type

Right now, there is one mandatory Message header field for all of the logical bitstreams: the "Content-type" header field, which contains the mime type of the track. The mime types in use here are listed at http://wiki.xiph.org/MIME_Types_and_File_Extensions#Codec_MIME_types.


Content-role

Content-language

Track order

In many applications it is necessary to walk through all the tracks in a media file and address tracks by an index.

In Ogg, the means to number through the tracks is by the order in which the bos pages of the tracks appear in the Ogg stream. If a file is re-encoded, the order may change, so you can only rely on this for addressing if the file doesn't change.

For example, a video file with the following composition would have the following indexes:

  • track[0]: Skeleton BOS
  • track[1]: Theora BOS for main video
  • track[2]: Vorbis BOS for main audio
  • track[3]: Kate BOS for English captions
  • track[4]: Kate BOS for German subtitles
  • track[5]: Vorbis BOS for audio descriptions
  • track[6]: Theora BOS for sign language

This track order is simply to have a means to address tracks through an index. It has no influence on what should be displayed on top of which other track.