XiphWiki - User contributions [en]

MIME Types and File Extensions

2007-05-28T13:52:01Z

ThomasVanderStichele:

STATUS: final editing before being turned into an official Xiph recommendation and work on rfcs will start to reflect these policies

DISCLAIMER: currently, only application/ogg is a registered mimetype. Registration for the others will need to be undertaken. In the meantime, use of the "x-" mimetype is recommended.

IMPLEMENTATION recommendations and patches: see [[MIME-Migration]].

== .ogx - application/ogg ==

* Ogg Multiplex Profile (anything in [[Ogg]])
* can contain any logical bitstreams multiplexed together in an ogg container
* will replace the .ogg extension from RFC 3534 http://www.ietf.org/rfc/rfc3534.txt
* random multitrack files SHOULD contain a [[Skeleton]] track to identify all containing logical bitstreams
* apps that identify a logical bitstream which they cannot decode SHOULD drop but MAY still decode the ones they can

== .oga - audio/ogg ==

* Ogg Audio Profile (audio in Ogg container)
* apps supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams
* covers [[Vorbis]], [[Speex]], [[FLAC]], [[Ghost]], [[OggPCM]] inside Ogg, though Ogg Vorbis and Ogg Speex also have special profiles
* May contain Ogg Skeleton and/or [[CMML]] logical bitstreams.

RATIONALE: This distinguishes audio-only files, using any of the Xiph audio codecs, from Ogg Vorbis I files (traditional .ogg) which may not contain more than one logical bitstream.

== .ogv - video/ogg ==

* Ogg Video Profile (a/v in Ogg container)
* apps supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams
* covers [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg
* This list is not exhaustive (for example, [[Dirac]] + FLAC is acceptable too)
* May contain Ogg Skeleton and/or CMML logical bitstreams.

== .ogg - audio/ogg+vorbis ==

* Ogg Vorbis I Profile
* .ogg applies now for Ogg Vorbis I files only
* .ogg has more recently also been used for Ogg FLAC and for Ogg Theora, too - these uses are deprecated now in favor of .oga and .ogv
* has been defined in RFC 3534 http://www.ietf.org/rfc/rfc3534.txt for application/ogg, so rfc 3534 will be re-defined

RATIONALE: .ogg has traditionally been used for Ogg Vorbis I files, in particular in HW players, which needs to continue to be supported

== .spx - audio/ogg+speex ==

* Ogg Speex Profile
* .spx has traditionally been used for Ogg Speex files and should be considered for backwards-compatibility

== .flac - application/flac ==

* flac in native encapsulation format

== Codec MIME types ==

Codecs need their own MIME types for streaming and to be used in multitrack ogg files using skeleton:

* audio/vorbis for Vorbis without container
* video/theora for Theora without container
* audio/speex for Speex without container
* audio/flac for FLAC without container, but extra FLAC Ogg header (?)

OggPCM Draft3

2005-11-15T11:13:11Z

ThomasVanderStichele: /* Supported PCM Formats */

'''Just in case it's not obvious, this page is just meant to be funny. Don't take this as a spec.'''

== Alternate format for OggPCM ==

=== Main Header Packet ===
Multi-byte fields in the header packets are packed in big indian order, to be consistent with network bit order. A header packet contains the following fields:

1 0 Codec identifier. Please make sure no other format starts with a bit set to zero.
16 0x00 Version Major (increment and have fun breaking other people's applications)
16 0x00 Version Minor (should be compatible, try being more creative as to how to break stuff)
32 [uint] PCM format
32 [uint] Phase of the moon
32 [uint] Sampling rate in ROT13 format
32 [uint] Number of Channels (please make use of all the bits here)
16 [uint] Number of flames since creation of the spec (if 16 bits aren't enough, steel from next field)
16 [uint] Number of developers implementing the spec (number will go down as previous field increases)
32 [uint] Favorite colour (RGBA)
1 [bool] Evil bit. Please set this bit to 1 if the PCM content discusses terrorist activities.
1 [bool] Clueless bit. Please set this bit to 1 if you don't know what to set it to.
1 [bool] Wiretap bit. If you are wiretapping stream content. Please alter this bit in the transmission.
16 [uint] Annoyance field. Rate annoyance of the content from 0 to 65535.
128 [uint] Magic number. Enter the right magic number or else I won't play your file.
8x12[char] CC field. Please leave your credit number here.

Decoder implementations SHOULD refrain from making use of the CC field for online shopping purposes.

=== Comment packet ===

Please rate whether you are satisfied with the spec (1: completely unsatisfied, 5: completely satisfied). Format is ASCII (1 char)

=== Extra Headers (optional) ===

Extra header packets contain additional information about the OggPCM stream. Each extra header is defined as:

32 [uint] Header ID
... Header data

==== Astrological Header ====

The channel mapping header is defined as:

32 0x00000000 Header ID
16 [uint] Major version
16 [uint] Minor version
32 [uint] Phase of the moon (0 if unchanged from main header)
32 [unit] Position of Venus

==== Encryption Header ====

OggPCM supports advanced DRM features. The encryption information is defined as:

32 0x00000000 Header ID (we use the same as the Astrological Header, they're interchangeable)
24 [uint] ROT13 Key (ROT13 version of the string "KEY")

=== Data Packets ===

Data packets contain either raw or cooked PCM audio in interleaved format:

* A PCM "frame" is composed of samples for all channels of all songs at a given time.
* Partial frames are forbidden. Offended frames will be prosecuted.
* Recommended packet size is smaller than 4 TBytes.

=== Supported PCM Formats ===

Format ID Short Name Description
-- Integer coding
0x00000000 OGGPCM_FMT_S8 Signed integer 8 bit
0x00000001 OGGPCM_FMT_U8 Unsigned integer 8 bit
0x00000002 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian
0x00000003 OGGPCM_FMT_S16_BE Signed integer 16 bit big endian
--
0x00000004 OGGPCM_FMT_ASCII Whitespace-separated ASCII
0x00000005 OGGPCM_FMT_S16_ROT13_LE ROT13 Signed integer 16 bit little endian
0x00000006 OGGPCM_FMT_S16_ROT26_LE ROT26 Signed integer 16 bit little endian
0x00000007 OGGPCM_FMT_S16_RAND_LE Signed integer 16 bit little endian with random bit order
--
0x00000008 OGGPCM_FMT_FLOAT32_LE IEEE 32-bit float, little endian [-inf,+inf]
0x000000G8 OGGPCM_FMT_FLOAT32_LE_SPIN IEEE 32-bit float, little endian, source sampled with spintronics technology [-inf,+inf]

Float formats use linear scaling from -inf to +inf. It is part of the speficication that a float value of NaN MUST result in the destruction of the galaxy or (as a minimum) our galaxy. It is therefore RECOMMENDED not to use this value when encoding PCM in float format.

FishFaq

2005-06-09T16:19:49Z

ThomasVanderStichele:

This page combines questions related to all Xiph projects.

== General Ogg questions ==

=== What is a granulepos ? ===

A granulepos is a representation for a timestamp on a scale specific to the codec. Conrad Parker clarifies the definition of granulepos as "representing the presentation time for the last presentable data item in an Ogg packet."

=== Where is the granulepos stored in the bitstream ? ===

=== How does the Ogg packet number work ? ===

The Ogg bitstream does not store packet numbers in the bitstream. Only page sequence numbers are
stored. libogg will count packets and give each Ogg packet a packet number. Normally these are
in sequence; when Ogg notices a discontinuity however (page sequence numbers don't match up (FIXME: is this actually in the code ?), or
the lacing values don't match up) it will increment the page counter by 1, which thus shows up as a missing packet (see http://trac.xiph.org/cgi-bin/trac.cgi/file/trunk/ogg/src/framing.c, _packetout()).

== Player implementation questions ==

=== What use cases do I need to consider when writing a player ? ===

There are different ways in which an ogg stream reaches your player. Each of these ways has some specific restrictions and potential problems that your player needs to be able to deal with. These are:

- the "ideal" case: a correctly muxed Ogg stream as a seekable file, with correct bos packets, header packets, and eos packets, time-correct muxing, and a continuous set of Ogg pages
- the "lossless streaming" case (e.g. HTTP streaming): you receive correct bos and header packets, and a string of Ogg packets in pages that are continuous, but start with a discontinuity. The stream might or might not be seekable, and you do not get eos pages
- the "saved from lossless streaming" case: as above, but you can seek. You still don't have eos pages
- the "lossy streaming" case (e.g. RTP streaming): some of the Ogg pages get lost in transmission. In the case of RTP, you actually may have less, or different, information to go on, since it is recommended that RTP packetizing is used instead of Ogg packetizing. An HTTP stream could also be lossy, if the server for example decides that the client is not reading fast enough and drops a set of intermediary buffers.
- the "no feedback" case (e.g. satellite broadcasts): there is no way for the client to communicate with the server. The client needs to get the header pages through other means, and then interpret the Ogg stream it receives.

FishFaq

2005-06-09T15:55:20Z

ThomasVanderStichele:

FishFaq

2005-06-06T09:36:39Z

ThomasVanderStichele:

FishFaq

2005-06-06T09:27:40Z

ThomasVanderStichele:

This page combines questions related to all Xiph projects.

- General Ogg questions

* What is a granulepos ?

A granulepos is a representation for a timestamp on a scale specific to the codec. Conrad Parker clarifies the definition of granulepos as "representing the presentation time for the last presentable data item in an Ogg packet."

FishFaq

2005-06-06T09:23:01Z

ThomasVanderStichele:

This page combines questions related to all Xiph projects.

TECHNICAL QUESTIONS

* What is a granulepos ?

A granulepos is a representation for a timestamp on a scale specific to the codec. Conrad Parker clarifies the definition of granulepos as "representing the presentation time for the last presentable data item in an Ogg packet."