Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
Ogg Media Types
Ogg媒体类型
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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.
本文档描述了Ogg容器格式的媒体类型注册以及这些类型实现的一致性要求。本文件淘汰了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 . . . . . . . . . . . . . . . . . . . . . . . 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
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.
该文档描述了OGG的媒体类型，它是由XIPH.org公共用途基金会定义的数据封装格式。有关此容器格式的背景信息，请参阅[RFC3533]中的“简介”和[Ogg]中的“概述”。
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.
Ogg中包含的二进制数据，如Vorbis和Theora，历史上使用[RFC3534]定义的应用程序/Ogg媒体类型进行交换。本文档淘汰了[RFC3534]，并为Ogg中不同类型的内容定义了三种媒体类型，以反映IANA媒体类型注册表中的使用情况，通过定义未指定的方面来促进互操作性，并提供一般安全注意事项。
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.
已知Ogg容器格式包含[Theora]或[Dirac]视频、[Speex]（窄带和宽带）语音、[Vorbis]或[FLAC]音频以及[CMML]定时文本/元数据。由于Ogg封装二进制数据，因此可以包括任何其他类型的视频、音频、图像、文本，或者，一般来说，任何时间连续采样的数据。
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.
虽然来自这些数据源的原始数据包可以直接由传输机制使用，这些传输机制提供它们自己的帧和数据包分离机制（如UDP数据报或RTP），但Ogg是基于流的存储（如文件）和传输（如TCP流或管道）的解决方案。当通过HTTP提供、包含在多部分文档中或在使用媒体类型[RFC2045]的其他地方使用这些内容时，需要使用本文档中定义的媒体类型来正确识别这些内容。
o The type "application/ogg" is redefined.
o 类型“application/ogg”被重新定义。
o The types "video/ogg" and "audio/ogg" are defined.
o 定义了“视频/ogg”和“音频/ogg”类型。
o New file extensions are defined.
o 定义了新的文件扩展名。
o New Macintosh file type codes are defined.
o 定义了新的Macintosh文件类型代码。
o The codecs parameter is defined for optional use.
o codecs参数是为可选使用而定义的。
o The Ogg Skeleton extension becomes a recommended addition for content served under the new types.
o Ogg骨架扩展成为新类型下服务内容的推荐添加。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中的描述进行解释，并指出合规实施的要求级别。除非另有说明，否则要求适用于所有实现。
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".
未能满足一个或多个“必须”要求的实现被视为不符合要求。满足所有“必须”要求，但未能满足一个或多个“应该”要求的实现称为“有条件兼容”。所有其他实现都是“无条件兼容的”。
The application/ogg media type has been used in an ad hoc fashion to label and exchange multimedia content in Ogg containers.
应用程序/ogg媒体类型已以特殊方式用于标记和交换ogg容器中的多媒体内容。
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 视频/ogg
o audio/ogg
o 音频/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.
这是为了共同使用，并应在处理视频或音频内容时分别使用。本文件还废除了应用程序/ogg的[RFC3534]定义，并将其标记为复杂数据（例如，多轨视频、音频、文本和其他时间连续采样数据），这些数据不是清晰的视频或音频数据，因此不适用于视频/ogg或音频/ogg类型。有关更多详细信息，请参阅以下章节。
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
Ogg比特流通常由一个或多个逻辑比特流组成，每个逻辑比特流由一系列将时间连续二进制数据打包的头和数据页组成[RFC3533]。可以通过使用[骨架]比特流来识别逻辑比特流的内容类型，而无需解码逻辑比特流的头页。需要使用Ogg骨架来提供以下内容：
the application/ogg type and RECOMMENDED for video/ogg and audio/ogg, as Skeleton contains identifiers to describe the different encapsulated data.
application/ogg类型，建议用于video/ogg和audio/ogg，因为骨架包含描述不同封装数据的标识符。
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.
这些媒体类型可以选择使用[RFC4281]中描述的“codecs”参数。封装在Ogg中的编解码器需要在第一个头页的开头有一个文本标识符，因此识别封装编解码器的机器可读方法将通过该头。下表说明了在处理Ogg媒体类型时，这些头值如何映射为“codecs”参数中使用的字符串。
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
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]).
此表的最新版本保存在Xiph.org（参见[编解码器]）。
Possible examples include:
可能的例子包括：
o application/ogg; codecs="theora, cmml, ecmascript"
o 应用程序/ogg；codecs=“theora、cmml、ecmascript”
o video/ogg; codecs="theora, vorbis"
o 视频/ogg；codecs=“theora，vorbis”
o audio/ogg; codecs=speex
o 音频/ogg；编解码器=speex
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.
如前一节所述，本文档描述了三种针对Ogg中封装的不同数据的媒体类型。由于Ogg能够封装任何类型的数据，因此在处理仅在application/Ogg类型下提供的内容时，多个使用场景暴露了实现之间的互操作性问题。
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.
虽然本文档确实重新定义了应用程序/ogg的早期定义，但这种媒体类型将继续包含尽可能广泛的内容，视频/ogg和音频/ogg类型是其较小的子集。然而，视频/ogg和音频/ogg类型在使用的子集中优先，特别是在服务不足以保证使用应用/ogg的复杂多媒体内容时。按照这一思路，音频/ogg类型在视频/ogg中是一个更小的子集，因为它不是指视觉内容。
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.
同样地，应用/ogg类型是推荐的选择，以服务于针对需要各种多路复用信号或连续数据流的科学和其他应用的内容，具有或不具有内容的脚本控制。对于包含可视、定时文本和任何其他类型的材料（需要可视界面，但不够复杂，无法保证在应用程序/ogg下提供）的比特流，建议使用视频/ogg类型。在Ogg比特流主要包含音频数据的情况下（尽管有歌词、元数据或封面），建议使用音频/Ogg类型。
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 Ogg封装的内容是二进制数据，应以适当的编码传输，无需CR/LF转换、7位剥离等。；base64[RFC4648]通常是二进制到文本编码的首选。
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.
o 本文档中描述的媒体类型用于基于流的存储（如文件）和传输（如TCP流或管道）；单独的类型用于识别编解码器，例如在实时应用中用于Theora[ThRTP]视频、Vorbis[RFC5215]或Speex[SpRTP]音频的RTP有效载荷格式，以及用于通过骨架识别Ogg内的封装数据。
Refer to [RFC3552] for a discussion of terminology used in this section.
有关本节中使用的术语的讨论，请参阅[RFC3552]。
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封装格式是一个容器，只是内容（如音频、视频和可显示文本数据）的载体，具有非常严格的定义。这种格式本身并不比任何其他内容框架机制更容易受到攻击。
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.
Ogg不为其自身或其包含的比特流提供任何通用加密或签名。但是，它封装了任何类型的二进制内容，因此能够包含加密和签名的内容数据。还可以添加外部安全机制，对Ogg比特流进行加密或签名，从而提供内容机密性和真实性。
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.
由于Ogg封装二进制数据，因此可以在Ogg比特流中包含可执行内容。未经最终用户事先验证其来源，实现不应执行此类内容。
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.
在网络场景中，使用Ogg进行流式传输或文件传输的应用程序可能会出现问题。在这种情况下，解码Ogg及其封装位流的实现必须确保正确处理被操纵的位流、缓冲区溢出和类似问题。
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比特流，试图调用过大的图片大小、高采样率音频等。实现应保护自己免受此类攻击。
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.
Ogg有一个可扩展的结构，因此理论上，将来可能会定义元数据字段或媒体格式，这些字段或格式可能会被用于诱导接收方的特定操作，从而带来额外的安全风险。但是，参考规范中目前不支持这种类型的功能。
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.
实现可能无法实现特定的安全模型或其他方法来防止可能的危险操作。此类故障可能被利用来获得对系统或敏感信息的未经授权访问；此类故障构成未知因素，因此不在本文件范围内。
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.
Ogg容器格式与设备、平台和供应商无关，并已证明可通过各种编码器和解码器在不同的计算平台上广泛实现。广泛可移植的参考实现[libogg]在修订版（3条款）BSD许可证下可用，这是一种自由软件许可证。
The Xiph.Org Foundation has defined the specification, interoperability, and conformance and conducts regular interoperability testing.
XIPH.org基金会定义了规范、互操作性和一致性，并进行定期的互操作性测试。
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.
Ogg框架扩展的使用已被确认不会导致与现有实现的互操作性问题。但是，欢迎第三方自行进行测试。
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.
根据[RFC4288]中规定的程序，本文件注册了两种新的媒体类型，并重新定义了下一节中定义的现有应用程序/ogg。
Type name: application
类型名称：应用程序
Subtype name: ogg
子类型名称：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.
可选参数：编解码器，其语法在RFC 4281中定义。有关允许值的列表，请参见RFC 5334第4节。
Encoding considerations: See section 6 of RFC 5334.
编码注意事项：参见RFC 5334第6节。
Security considerations: See section 7 of RFC 5334.
安全注意事项：见RFC 5334第7节。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
互操作性注意事项：无，如RFC 5334第8节所述。
Published specification: RFC 3533
已发布规范：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".
幻数：前四个字节0x4f 0x67 0x67 0x53对应字符串“OggS”。
File extension(s): .ogx
文件扩展名：.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.
RFC 3534为application/ogg定义了文件扩展名.ogg，RFC 5334放弃了该文件扩展名，取而代之的是.ogx，因为在历史上，一些实现预期.ogg文件仅为Vorbis编码的音频。
Macintosh File Type Code(s): OggX
Macintosh文件类型代码：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.
使用限制：类型application/ogg只能在不适合在video/ogg或audio/ogg类型下提供数据的情况下使用。在application/ogg类型下提供的数据应使用.ogx文件扩展名，并且必须包含ogg骨架逻辑位流，以标识所有其他包含的逻辑位流。
Author: See "Authors' Addresses" section.
作者：见“作者地址”一节。
Change controller: The Xiph.Org Foundation.
变更控制器：XIPH.org基金会。
Type name: video
类型名称：视频
Subtype name: ogg
子类型名称：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.
可选参数：编解码器，其语法在RFC 4281中定义。有关允许值的列表，请参见RFC 5334第4节。
Encoding considerations: See section 6 of RFC 5334.
编码注意事项：参见RFC 5334第6节。
Security considerations: See section 7 of RFC 5334.
安全注意事项：见RFC 5334第7节。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
互操作性注意事项：无，如RFC 5334第8节所述。
Published specification: RFC 3533
已发布规范：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".
幻数：前四个字节0x4f 0x67 0x67 0x53对应字符串“OggS”。
File extension(s): .ogv
文件扩展名：.ogv
Macintosh File Type Code(s): OggV
Macintosh文件类型代码：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.
使用限制：类型“video/ogg”应用于包含视觉、音频、定时文本或任何其他类型的需要视觉界面的材料的ogg比特流。它用于内容不够复杂，不足以保证在“应用程序/ogg”下提供服务的内容；例如，Theora视频、Vorbis音频、骨架元数据和CMML字幕的组合。“video/ogg”类型下提供的数据应包含ogg骨架逻辑位流。与“video/ogg”类型交互的实现应该支持多路复用比特流。
Author: See "Authors' Addresses" section.
作者：见“作者地址”一节。
Change controller: The Xiph.Org Foundation.
变更控制器：XIPH.org基金会。
Type name: audio
类型名称：音频
Subtype name: ogg
子类型名称：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.
可选参数：编解码器，其语法在RFC 4281中定义。有关允许值的列表，请参见RFC 5334第4节。
Encoding considerations: See section 6 of RFC 5334.
编码注意事项：参见RFC 5334第6节。
Security considerations: See section 7 of RFC 5334.
安全注意事项：见RFC 5334第7节。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
互操作性注意事项：无，如RFC 5334第8节所述。
Published specification: RFC 3533
已发布规范：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".
幻数：前四个字节0x4f 0x67 0x67 0x53对应字符串“OggS”。
File extension(s): .oga, .ogg, .spx
文件扩展名：.oga、.ogg、.spx
Macintosh File Type Code(s): OggA
Macintosh文件类型代码：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.
使用限制：当ogg比特流主要包含音频数据时，应使用类型“audio/ogg”。使用default.oga文件扩展名时，“audio/ogg”类型下提供的内容应具有ogg骨架逻辑位流。.ogg和.spx文件扩展名表示一种专门化，由于与现有实现的向后兼容性问题，这种专门化不需要框架。特别是，.ogg用于仅包含Vorbis位流的ogg文件，而.spx用于仅包含Speex位流的ogg文件。
Author: See "Authors' Addresses" section.
作者：见“作者地址”一节。
Change controller: The Xiph.Org Foundation.
变更控制器：XIPH.org基金会。
The authors gratefully acknowledge the contributions of Magnus Westerlund, Alfred Hoenes, and Peter Saint-Andre.
作者衷心感谢马格纳斯·韦斯特隆德、阿尔弗雷德·霍恩斯和彼得·圣安德烈的贡献。
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.
作者同意授予第三方不可撤销的权利，在任何媒体上复制、使用和分发作品，无论是否修改，无需版税，前提是，除非授予单独许可，否则重新分发的修改作品不包含误导作者、版本、作品名称或背书信息。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, May 2003.
[RFC3533]Pfeiffer，S.，“Ogg封装格式版本0”，RFC 3533，2003年5月。
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs Parameter for "Bucket" Media Types", RFC 4281, November 2005.
[RFC4281]Gellens，R.，Singer，D.，和P.Frojdh，“桶”媒体类型的编解码器参数”，RFC 42812005年11月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous Media Markup Language (CMML)", Work in Progress, March 2006.
[CMML]Pfeiffer，S.，Parker，C.和A.Peng，“连续媒体标记语言（CMML）”，正在进行的工作，2006年3月。
[Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME types and respective codecs parameter", July 2008, <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
[编解码器]Pfeiffer，S.和I.Goncalves，“MIME类型和相应编解码器参数的规范”，2008年7月<http://wiki.xiph.org/index.php/MIMETypesCodecs>.
[Dirac] Dirac Group, "Dirac Specification", <http://diracvideo.org/specifications/>.
[Dirac]Dirac集团，“Dirac规范”<http://diracvideo.org/specifications/>.
[FLAC] Coalson, J., "The FLAC Format", <http://flac.sourceforge.net/format.html>.
[FLAC]Colason，J.，“FLAC格式”<http://flac.sourceforge.net/format.html>.
[libogg] Xiph.Org Foundation, "The libogg API", June 2000, <http://xiph.org/ogg/doc/libogg>.
[Libgg ] XIPH.org基金会，“LiBOGG API”，2000年6月，<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>.
[OGG] XIPH.org基金会，“OGG比特流文档：OGG逻辑和物理比特流概述，OGG逻辑比特流框架，OGG多流复用”，<http://xiph.org/ogg/doc>.
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534, May 2003.
[RFC3534]Walleij，L.，“应用程序/ogg媒体类型”，RFC 3534，2003年5月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded Audio", RFC 5215, August 2008.
[RFC5215]Barbato，L.，“Vorbis编码音频的RTP有效载荷格式”，RFC 52152008年8月。
[Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata Bitstream", November 2007, <http://xiph.org/ogg/doc/skeleton.html>.
[Skeleton]Pfeiffer，S.和C.Parker，“Ogg骨架元数据比特流”，2007年11月<http://xiph.org/ogg/doc/skeleton.html>.
[Speex] Valin, J., "The Speex Codec Manual", February 2002, <http://speex.org/docs/manual/speex-manual>.
[Speex]Valin，J.，“Speex编解码器手册”，2002年2月<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.
[SpRTP]Herlein，G.，Valin，J.，Heggestad，A.，和A.Moizard，“Speex编解码器的RTP有效载荷格式”，正在进行的工作，2008年2月。
[Theora] Xiph.Org Foundation, "Theora Specification", October 2007, <http://theora.org/doc/Theora.pdf>.
[理论] XIPH.org基金会，《理论规范》，2007年10月，<http://theora.org/doc/Theora.pdf>.
[ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded Video", Work in Progress, June 2006.
[ThRTP]Barbato，L.，“Theora编码视频的RTP有效载荷格式”，正在进行的工作，2006年6月。
[Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004, <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
[VorbIS] XIPH.org基金会，“Vorbi I规范”，2004年7月，<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
IVO伊曼纽尔GangalvsXIPH.org基金会21学院山路，萨默维尔，马02144美国
EMail: justivo@gmail.com
URI: xmpp:justivo@gmail.com
EMail: justivo@gmail.com
URI: xmpp:justivo@gmail.com
Silvia Pfeiffer Xiph.Org Foundation
Silvia Pfeiffer Xiph基金会基金会
EMail: silvia@annodex.net
URI: http://annodex.net/
EMail: silvia@annodex.net
URI: http://annodex.net/
Christopher Montgomery Xiph.Org Foundation
Christopher Montgomery Xiph基金会基金会
EMail: monty@xiph.org
URI: http://xiph.org
EMail: monty@xiph.org
URI: http://xiph.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.