Ogg Media Types
How the web and other transports should label content that sits in an Ogg container.
Goncalves, I., Pfeiffer, S., and C. Montgomery, "Ogg Media Types", RFC 5334, DOI 10.17487/RFC5334, September 2008, <https://www.rfc-editor.org/info/rfc5334>.
@misc{rfc5334,
series = {Request for Comments},
number = 5334,
howpublished = {RFC 5334},
publisher = {RFC Editor},
doi = {10.17487/RFC5334},
url = {https://www.rfc-editor.org/info/rfc5334},
author = {I. Goncalves and S. Pfeiffer and C. Montgomery},
title = {{Ogg Media Types}},
pagetotal = 14,
year = 2008,
month = sep,
} RFC text
Contents
Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
Ogg Media Types
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes the registration of media types for the Ogg
container format and conformance requirements for implementations of
these types. This document obsoletes RFC 3534.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changes Since RFC 3534 . . . . . . . . . . . . . . . . . . 2
3. Conformance and Document Conventions . . . . . . . . . . . 3
4. Deployed Media Types and Compatibility . . . . . . . . . . 3
5. Relation between the Media Types . . . . . . . . . . . . . 5
6. Encoding Considerations . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . 6
8. Interoperability Considerations . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7
10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7
10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
12. Copying Conditions . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document describes media types for Ogg, a data encapsulation
format defined by the Xiph.Org Foundation for public use. Refer to
"Introduction" in [RFC3533] and "Overview" in [Ogg] for background
information on this container format.
Binary data contained in Ogg, such as Vorbis and Theora, has
historically been interchanged using the application/ogg media type
as defined by [RFC3534]. This document obsoletes [RFC3534] and
defines three media types for different types of content in Ogg to
reflect this usage in the IANA media type registry, to foster
interoperability by defining underspecified aspects, and to provide
general security considerations.
The Ogg container format is known to contain [Theora] or [Dirac]
video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
audio, and [CMML] timed text/metadata. As Ogg encapsulates binary
data, it is possible to include any other type of video, audio,
image, text, or, generally speaking, any time-continuously sampled
data.
While raw packets from these data sources may be used directly by
transport mechanisms that provide their own framing and packet-
separation mechanisms (such as UDP datagrams or RTP), Ogg is a
solution for stream based storage (such as files) and transport (such
as TCP streams or pipes). The media types defined in this document
are needed to correctly identify such content when it is served over
HTTP, included in multi-part documents, or used in other places where
media types [RFC2045] are used.
2. Changes Since RFC 3534
o The type "application/ogg" is redefined.
o The types "video/ogg" and "audio/ogg" are defined.
o New file extensions are defined.
o New Macintosh file type codes are defined.
o The codecs parameter is defined for optional use.
o The Ogg Skeleton extension becomes a recommended addition for
content served under the new types.
3. Conformance and Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119] and
indicate requirement levels for compliant implementations.
Requirements apply to all implementations unless otherwise stated.
An implementation is a software module that supports one of the media
types defined in this document. Software modules may support
multiple media types, but conformance is considered individually for
each type.
Implementations that fail to satisfy one or more "MUST" requirements
are considered non-compliant. Implementations that satisfy all
"MUST" requirements, but fail to satisfy one or more "SHOULD"
requirements, are said to be "conditionally compliant". All other
implementations are "unconditionally compliant".
4. Deployed Media Types and Compatibility
The application/ogg media type has been used in an ad hoc fashion to
label and exchange multimedia content in Ogg containers.
Use of the "application" top-level type for this kind of content is
known to be problematic, in particular since it obfuscates video and
audio content. This document thus defines the media types,
o video/ogg
o audio/ogg
which are intended for common use and SHOULD be used when dealing
with video or audio content, respectively. This document also
obsoletes the [RFC3534] definition of application/ogg and marks it
for complex data (e.g., multitrack visual, audio, textual, and other
time-continuously sampled data), which is not clearly video or audio
data and thus not suited for either the video/ogg or audio/ogg types.
Refer to the following section for more details.
An Ogg bitstream generally consists of one or more logical bitstreams
that each consist of a series of header and data pages packetising
time-continuous binary data [RFC3533]. The content types of the
logical bitstreams may be identified without decoding the header
pages of the logical bitstreams through use of a [Skeleton]
bitstream. Using Ogg Skeleton is REQUIRED for content served under
the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
as Skeleton contains identifiers to describe the different
encapsulated data.
Furthermore, it is RECOMMENDED that implementations that identify a
logical bitstream that they cannot decode SHOULD ignore it, while
continuing to decode the ones they can. Such precaution ensures
backward and forward compatibility with existing and future data.
These media types can optionally use the "codecs" parameter described
in [RFC4281]. Codecs encapsulated in Ogg require a text identifier
at the beginning of the first header page, hence a machine-readable
method to identify the encapsulated codecs would be through this
header. The following table illustrates how those header values map
into strings that are used in the "codecs" parameter when dealing
with Ogg media types.
Codec Identifier | Codecs Parameter
-----------------------------------------------------------
char[5]: 'BBCD\0' | dirac
char[5]: '\177FLAC' | flac
char[7]: '\x80theora' | theora
char[7]: '\x01vorbis' | vorbis
char[8]: 'CELT ' | celt
char[8]: 'CMML\0\0\0\0' | cmml
char[8]: '\213JNG\r\n\032\n' | jng
char[8]: '\x80kate\0\0\0' | kate
char[8]: 'OggMIDI\0' | midi
char[8]: '\212MNG\r\n\032\n' | mng
char[8]: 'PCM ' | pcm
char[8]: '\211PNG\r\n\032\n' | png
char[8]: 'Speex ' | speex
char[8]: 'YUV4MPEG' | yuv4mpeg
An up-to-date version of this table is kept at Xiph.org (see
[Codecs]).
Possible examples include:
o application/ogg; codecs="theora, cmml, ecmascript"
o video/ogg; codecs="theora, vorbis"
o audio/ogg; codecs=speex
5. Relation between the Media Types
As stated in the previous section, this document describes three
media types that are targeted at different data encapsulated in Ogg.
Since Ogg is capable of encapsulating any kind of data, the multiple
usage scenarios have revealed interoperability issues between
implementations when dealing with content served solely under the
application/ogg type.
While this document does redefine the earlier definition of
application/ogg, this media type will continue to embrace the widest
net possible of content with the video/ogg and audio/ogg types being
smaller subsets of it. However, the video/ogg and audio/ogg types
take precedence in a subset of the usages, specifically when serving
multimedia content that is not complex enough to warrant the use of
application/ogg. Following this line of thought, the audio/ogg type
is an even smaller subset within video/ogg, as it is not intended to
refer to visual content.
As such, the application/ogg type is the recommended choice to serve
content aimed at scientific and other applications that require
various multiplexed signals or streams of continuous data, with or
without scriptable control of content. For bitstreams containing
visual, timed text, and any other type of material that requires a
visual interface, but that is not complex enough to warrant serving
under application/ogg, the video/ogg type is recommended. In
situations where the Ogg bitstream predominantly contains audio data
(lyrics, metadata, or cover art notwithstanding), it is recommended
to use the audio/ogg type.
6. Encoding Considerations
Binary: The content consists of an unrestricted sequence of octets.
Note:
o Ogg encapsulated content is binary data and should be transmitted
in a suitable encoding without CR/LF conversion, 7-bit stripping,
etc.; base64 [RFC4648] is generally preferred for binary-to-text
encoding.
o Media types described in this document are used for stream based
storage (such as files) and transport (such as TCP streams or
pipes); separate types are used to identify codecs such as in
real-time applications for the RTP payload formats of Theora
[ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
as for identification of encapsulated data within Ogg through
Skeleton.
7. Security Considerations
Refer to [RFC3552] for a discussion of terminology used in this
section.
The Ogg encapsulation format is a container and only a carrier of
content (such as audio, video, and displayable text data) with a very
rigid definition. This format in itself is not more vulnerable than
any other content framing mechanism.
Ogg does not provide for any generic encryption or signing of itself
or its contained bitstreams. However, it encapsulates any kind of
binary content and is thus able to contain encrypted and signed
content data. It is also possible to add an external security
mechanism that encrypts or signs an Ogg bitstream and thus provides
content confidentiality and authenticity.
As Ogg encapsulates binary data, it is possible to include executable
content in an Ogg bitstream. Implementations SHOULD NOT execute such
content without prior validation of its origin by the end-user.
Issues may arise on applications that use Ogg for streaming or file
transfer in a networking scenario. In such cases, implementations
decoding Ogg and its encapsulated bitstreams have to ensure correct
handling of manipulated bitstreams, of buffer overflows, and similar
issues.
It is also possible to author malicious Ogg bitstreams, which attempt
to call for an excessively large picture size, high sampling-rate
audio, etc. Implementations SHOULD protect themselves against this
kind of attack.
Ogg has an extensible structure, so that it is theoretically possible
that metadata fields or media formats might be defined in the future
which might be used to induce particular actions on the part of the
recipient, thus presenting additional security risks. However, this
type of capability is currently not supported in the referenced
specification.
Implementations may fail to implement a specific security model or
other means to prevent possibly dangerous operations. Such failure
might possibly be exploited to gain unauthorized access to a system
or sensitive information; such failure constitutes an unknown factor
and is thus considered out of the scope of this document.
8. Interoperability Considerations
The Ogg container format is device-, platform-, and vendor-neutral
and has proved to be widely implementable across different computing
platforms through a wide range of encoders and decoders. A broadly
portable reference implementation [libogg] is available under the
revised (3-clause) BSD license, which is a Free Software license.
The Xiph.Org Foundation has defined the specification,
interoperability, and conformance and conducts regular
interoperability testing.
The use of the Ogg Skeleton extension has been confirmed to not cause
interoperability issues with existing implementations. Third parties
are, however, welcome to conduct their own testing.
9. IANA Considerations
In accordance with the procedures set forth in [RFC4288], this
document registers two new media types and redefines the existing
application/ogg as defined in the following section.
10. Ogg Media Types
10.1. application/ogg
Type name: application
Subtype name: ogg
Required parameters: none
Optional parameters: codecs, whose syntax is defined in RFC 4281.
See section 4 of RFC 5334 for a list of allowed values.
Encoding considerations: See section 6 of RFC 5334.
Security considerations: See section 7 of RFC 5334.
Interoperability considerations: None, as noted in section 8 of RFC
5334.
Published specification: RFC 3533
Applications which use this media type: Scientific and otherwise that
require various multiplexed signals or streams of data, with or
without scriptable control of content.
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .ogx
RFC 3534 defined the file extension .ogg for application/ogg,
which RFC 5334 obsoletes in favor of .ogx due to concerns where,
historically, some implementations expect .ogg files to be solely
Vorbis-encoded audio.
Macintosh File Type Code(s): OggX
Person & Email address to contact for further information: See
"Authors' Addresses" section.
Intended usage: COMMON
Restrictions on usage: The type application/ogg SHOULD only be used
in situations where it is not appropriate to serve data under the
video/ogg or audio/ogg types. Data served under the application/ogg
type SHOULD use the .ogx file extension and MUST contain an Ogg
Skeleton logical bitstream to identify all other contained logical
bitstreams.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
10.2. video/ogg
Type name: video
Subtype name: ogg
Required parameters: none
Optional parameters: codecs, whose syntax is defined in RFC 4281.
See section 4 of RFC 5334 for a list of allowed values.
Encoding considerations: See section 6 of RFC 5334.
Security considerations: See section 7 of RFC 5334.
Interoperability considerations: None, as noted in section 8 of RFC
5334.
Published specification: RFC 3533
Applications which use this media type: Multimedia applications,
including embedded, streaming, and conferencing tools.
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .ogv
Macintosh File Type Code(s): OggV
Person & Email address to contact for further information: See
"Authors' Addresses" section.
Intended usage: COMMON
Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
bitstreams containing visual, audio, timed text, or any other type of
material that requires a visual interface. It is intended for
content not complex enough to warrant serving under "application/
ogg"; for example, a combination of Theora video, Vorbis audio,
Skeleton metadata, and CMML captioning. Data served under the type
"video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
Implementations interacting with the type "video/ogg" SHOULD support
multiplexed bitstreams.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
10.3. audio/ogg
Type name: audio
Subtype name: ogg
Required parameters: none
Optional parameters: codecs, whose syntax is defined in RFC 4281.
See section 4 of RFC 5334 for a list of allowed values.
Encoding considerations: See section 6 of RFC 5334.
Security considerations: See section 7 of RFC 5334.
Interoperability considerations: None, as noted in section 8 of RFC
5334.
Published specification: RFC 3533
Applications which use this media type: Multimedia applications,
including embedded, streaming, and conferencing tools.
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .oga, .ogg, .spx
Macintosh File Type Code(s): OggA
Person & Email address to contact for further information: See
"Authors' Addresses" section.
Intended usage: COMMON
Restrictions on usage: The type "audio/ogg" SHOULD be used when the
Ogg bitstream predominantly contains audio data. Content served
under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
bitstream when using the default .oga file extension. The .ogg and
.spx file extensions indicate a specialization that requires no
Skeleton due to backward compatibility concerns with existing
implementations. In particular, .ogg is used for Ogg files that
contain only a Vorbis bitstream, while .spx is used for Ogg files
that contain only a Speex bitstream.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
11. Acknowledgements
The authors gratefully acknowledge the contributions of Magnus
Westerlund, Alfred Hoenes, and Peter Saint-Andre.
12. Copying Conditions
The authors agree to grant third parties the irrevocable right to
copy, use and distribute the work, with or without modification, in
any medium, without royalty, provided that, unless separate
permission is granted, redistributed modified works do not contain
misleading author, version, name of work, or endorsement information.
13. References
13.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533, May 2003.
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
Parameter for "Bucket" Media Types", RFC 4281,
November 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288,
December 2005.
13.2. Informative References
[CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
Media Markup Language (CMML)", Work in Progress,
March 2006.
[Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME
types and respective codecs parameter", July 2008,
<http://wiki.xiph.org/index.php/MIMETypesCodecs>.
[Dirac] Dirac Group, "Dirac Specification",
<http://diracvideo.org/specifications/>.
[FLAC] Coalson, J., "The FLAC Format",
<http://flac.sourceforge.net/format.html>.
[libogg] Xiph.Org Foundation, "The libogg API", June 2000,
<http://xiph.org/ogg/doc/libogg>.
[Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
logical and physical bitstream overview, Ogg logical
bitstream framing, Ogg multi-stream multiplexing",
<http://xiph.org/ogg/doc>.
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
May 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded
Audio", RFC 5215, August 2008.
[Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
Bitstream", November 2007,
<http://xiph.org/ogg/doc/skeleton.html>.
[Speex] Valin, J., "The Speex Codec Manual", February 2002,
<http://speex.org/docs/manual/speex-manual>.
[SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
"RTP Payload Format for the Speex Codec", Work
in Progress, February 2008.
[Theora] Xiph.Org Foundation, "Theora Specification",
October 2007, <http://theora.org/doc/Theora.pdf>.
[ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded
Video", Work in Progress, June 2006.
[Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004,
<http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
Authors' Addresses
Ivo Emanuel Goncalves
Xiph.Org Foundation
21 College Hill Road
Somerville, MA 02144
US
EMail: justivo@gmail.com
URI: xmpp:justivo@gmail.com
Silvia Pfeiffer
Xiph.Org Foundation
EMail: silvia@annodex.net
URI: http://annodex.net/
Christopher Montgomery
Xiph.Org Foundation
EMail: monty@xiph.org
URI: http://xiph.org
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
ISO Plain Language
On this page
§1Introduction
The document describes media types for Ogg, a data encapsulation format defined by the Xiph.Org Foundation for public use. The container format itself is specified in RFC 3533.
Binary data contained in Ogg, such as Vorbis and Theora, has historically been interchanged using the application/ogg media type defined by RFC 3534. This document obsoletes that definition and defines three media types for different kinds of content in Ogg, to reflect this usage in the IANA media type registry, to foster interoperability by defining underspecified aspects, and to provide general security considerations.
The Ogg container format is known to contain Theora or Dirac video, Speex speech in both narrow-band and wide-band forms, Vorbis or FLAC audio, and CMML timed text and metadata. Because Ogg encapsulates binary data, it is possible to include any other type of video, audio, image, text, or, generally speaking, any time-continuously sampled data.
Raw packets from these data sources may be used directly by transport mechanisms that provide their own framing and packet separation, such as UDP datagrams or RTP. Ogg is instead a solution for stream-based storage, such as files, and transport, such as TCP streams or pipes. The media types are needed to identify such content correctly when it is served over HTTP, included in multipart documents, or used in any other place where media types apply.
Ogg is a box that holds compressed media. The document gives that box a set of labels so that a server can say what is inside it and a player can react correctly.
§2Changes Since RFC 3534
The document lists what changed. The type application/ogg is redefined. The types video/ogg and audio/ogg are defined. New file extensions are defined, and new Macintosh file type codes are defined. The codecs parameter is defined for optional use. The Ogg Skeleton extension becomes a recommended addition for content served under the new types.
The short list of changes is the whole point of the document: one type is narrowed, two are added, and a way of describing the codecs inside a file is made official.
§3Conformance and Document Conventions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in BCP 14, and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.
An implementation is a software module that supports one of the media types defined in the document. Software modules may support multiple media types, but conformance is considered individually for each type.
An implementation that fails to satisfy one or more MUST requirements is considered non-compliant. One that satisfies all MUST requirements but fails one or more SHOULD requirements is said to be conditionally compliant. All other implementations are unconditionally compliant.
The document sets three grades. Failing a MUST makes an implementation non-compliant. Failing a SHOULD makes it conditionally compliant. Meeting everything makes it unconditionally compliant. Each media type is judged on its own, even when one module handles all three.
§4Deployed Media Types and Compatibility
The application/ogg media type had been used in an ad hoc fashion to label and exchange multimedia content in Ogg containers. Using the application top-level type for this kind of content is known to be problematic, in particular since it obfuscates video and audio content. The document therefore defines video/ogg and audio/ogg, which are intended for common use and should be used when dealing with video or audio content respectively. It also obsoletes the RFC 3534 definition of application/ogg and marks it for complex data, such as multitrack visual, audio, textual and other time-continuously sampled data, which is not clearly video or audio and so is not suited to either of the two new types.
An Ogg bitstream generally consists of one or more logical bitstreams, each of which consists of a series of header and data pages packetising time-continuous binary data. The content types of the logical bitstreams may be identified without decoding the header pages through the use of an Ogg Skeleton bitstream. Using Ogg Skeleton is required for content served under the application/ogg type and recommended for video/ogg and audio/ogg, since the Skeleton contains identifiers that describe the different encapsulated data.
It is also recommended that implementations that identify a logical bitstream they cannot decode should ignore it, while continuing to decode the ones they can. Such a precaution ensures backward and forward compatibility with existing and future data.
These media types can optionally use the codecs parameter. Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page, so a machine-readable way to identify the encapsulated codecs is through that header. The document gives a table mapping those header values onto the strings used in the codecs parameter, and keeps an up-to-date version of the table at Xiph.org.
Each media type also says what a file must contain. Under application/ogg the file must carry an Ogg Skeleton bitstream, a small map that names the streams inside. Under the two narrower types it is recommended.
The codecs parameter names the encoders inside the file. The identifier for each codec sits at the start of the first header page, and the table in the document maps those bytes onto the names used in the parameter.
| Media type | Use it for | File extension |
|---|---|---|
| application/ogg | Complex data: multiplexed signals or streams of continuous data, with or without scriptable control | .ogx |
| video/ogg | Visual, timed text or any other material that needs a visual interface | .ogv |
| audio/ogg | Bitstreams that predominantly contain audio data | .oga, .ogg, .spx |
char[5]: 'BBCD\0' | dirac
char[5]: '\177FLAC' | flac
char[7]: '\x80theora' | theora
char[7]: '\x01vorbis' | vorbis
char[8]: 'CELT ' | celt
char[8]: 'CMML\0\0\0\0' | cmml
char[8]: '\213JNG\r\n\032\n' | jng
char[8]: '\x80kate\0\0\0' | kate
char[8]: 'OggMIDI\0' | midi
char[8]: '\212MNG\r\n\032\n' | mng
char[8]: 'PCM ' | pcm
char[8]: '\211PNG\r\n\032\n' | png
char[8]: 'Speex ' | speex
char[8]: 'YUV4MPEG' | yuv4mpeg§5Relation between the Media Types
The document describes three media types targeted at different data encapsulated in Ogg. Since Ogg is capable of encapsulating any kind of data, the multiple usage scenarios have revealed interoperability issues between implementations when dealing with content served solely under the application/ogg type.
While the earlier definition of application/ogg is redefined, this media type continues to embrace the widest net possible of content, with video/ogg and audio/ogg being smaller subsets of it. The two narrower types take precedence in a subset of the usages, specifically when serving multimedia content that is not complex enough to warrant the use of application/ogg. The audio/ogg type is an even smaller subset within video/ogg, as it is not intended to refer to visual content.
The application/ogg type is the recommended choice for content aimed at scientific and other applications that require various multiplexed signals or streams of continuous data, with or without scriptable control of content. For bitstreams containing visual, timed text, and any other material that requires a visual interface, but that is not complex enough to warrant serving under application/ogg, the video/ogg type is recommended. In situations where the Ogg bitstream predominantly contains audio data, lyrics, metadata or cover art notwithstanding, it is recommended to use the audio/ogg type.
The three types are nested. application/ogg covers everything, video/ogg covers a smaller part of it, and audio/ogg covers a smaller part again. The rule is to pick the narrowest type that still describes the file honestly.
- application/ogg The widest net: complex multiplexed data
- video/ogg Material that needs a visual interface
- audio/ogg Predominantly audio data
- video/ogg Material that needs a visual interface
§10The Media Type Registrations
In accordance with the procedures set forth in RFC 4288, the document registers two new media types and redefines the existing application/ogg. None of the three requires any parameters, and each may optionally carry the codecs parameter whose syntax is defined in RFC 4281. The published specification for all three is RFC 3533.
All three share the same magic number: the first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string OggS. The file extensions differ. application/ogg uses .ogx, because RFC 3534 defined .ogg for it and this document obsoletes that in favour of .ogx, due to concerns where historically some implementations expect .ogg files to be solely Vorbis-encoded audio. video/ogg uses .ogv, and audio/ogg uses .oga, .ogg and .spx. The Macintosh file type codes are OggX, OggV and OggA respectively. All three are marked for common usage, and the change controller for each is the Xiph.Org Foundation.
The restrictions on usage differ. application/ogg should only be used where the data is not suited to video/ogg or audio/ogg; data served under it should use the .ogx extension and must contain an Ogg Skeleton logical bitstream identifying all other contained logical bitstreams. video/ogg should be used for bitstreams containing visual, audio, timed text, or any other material that requires a visual interface, for content not complex enough to warrant application/ogg, for example a combination of Theora video, Vorbis audio, Skeleton metadata and CMML captioning; data served under it should contain an Ogg Skeleton logical bitstream, and implementations interacting with the type should support multiplexed bitstreams. audio/ogg should be used when the bitstream predominantly contains audio data; content served under it should have an Ogg Skeleton logical bitstream when using the default .oga extension, while the .ogg and .spx extensions indicate a specialisation that requires no Skeleton, because of backward compatibility concerns with existing implementations: .ogg is used for files that contain only a Vorbis bitstream and .spx for files that contain only a Speex bitstream.
The document records no interoperability considerations for any of the three types. The Ogg container format is device-, platform- and vendor-neutral, and a broadly portable reference implementation, libogg, is available under the revised 3-clause BSD license. The Xiph.Org Foundation has defined the specification, interoperability and conformance, and conducts regular interoperability testing.
Each type gets a file extension and a Macintosh type code so that a desktop can recognise the file without reading it. The extensions also carry meaning: .ogg and .spx mean a single Vorbis or Speex stream, while .oga is the general audio extension.
§6Encoding Considerations
The content consists of an unrestricted sequence of octets, so the media type is binary. Ogg encapsulated content is binary data and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping, and the like. Base64 is generally preferred for binary-to-text encoding.
The media types are used for stream-based storage, such as files, and transport, such as TCP streams or pipes. Separate types are used to identify codecs such as in real-time applications for the RTP payload formats of Theora video, Vorbis or Speex audio, as well as for identification of encapsulated data within Ogg through Skeleton.
The payload is raw binary. If it has to travel as text, it should be encoded, and base64 is the usual choice, because anything that rewrites line endings or strips the seventh bit will corrupt it.
§7Security Considerations
The Ogg encapsulation format is a container and only a carrier of content, such as audio, video and displayable text data, with a very rigid definition. The format itself is not more vulnerable than any other content framing mechanism.
Ogg does not provide for any generic encryption or signing of itself or its contained bitstreams. It does, however, encapsulate any kind of binary content and so is able to contain encrypted and signed content data. It is also possible to add an external security mechanism that encrypts or signs an Ogg bitstream and thus provides content confidentiality and authenticity.
Because Ogg encapsulates binary data, it is possible to include executable content in an Ogg bitstream. Implementations should not execute such content without prior validation of its origin by the end user.
Issues may arise in applications that use Ogg for streaming or file transfer. Implementations decoding Ogg and its encapsulated bitstreams have to ensure correct handling of manipulated bitstreams, of buffer overflows, and similar issues. It is also possible to author malicious Ogg bitstreams that attempt to call for an excessively large picture size or high sampling-rate audio, and implementations should protect themselves against this kind of attack.
Ogg has an extensible structure, so it is theoretically possible that metadata fields or media formats might be defined in the future which could be used to induce particular actions on the part of the recipient. That capability is currently not supported in the referenced specification. Implementations may fail to implement a specific security model or other means of preventing possibly dangerous operations, and such a failure might be exploited to gain unauthorised access to a system or sensitive information; it is considered out of the scope of this document.
Ogg is only a container, so it adds no new attack surface of its own, but a file inside it can still be dangerous. A decoder has to cope with manipulated files, oversized pictures and buffer overflows, and nothing in the container should be executed without checking where it came from.
- The container is not the riskOgg is a rigid carrier for content and is not more vulnerable than any other framing mechanism.
- No built-in protectionOgg provides no generic encryption or signing of itself or of the bitstreams it carries. An external mechanism is needed.
- Executable contentA bitstream can contain executable content, which should not be run without the end user validating where it came from.
- Malformed inputDecoders have to handle manipulated bitstreams and buffer overflows correctly.
- Absurd resource requestsA malicious bitstream can ask for an excessively large picture size or high sampling-rate audio, and implementations should protect themselves against that.