Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 6381 QUALCOMM, Inc.
Obsoletes: 4281 D. Singer
Updates: 3839, 4337, 4393 Apple, Inc.
Category: Standards Track P. Frojdh
ISSN: 2070-1721 Ericsson AB
August 2011
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 6381 QUALCOMM, Inc.
Obsoletes: 4281 D. Singer
Updates: 3839, 4337, 4393 Apple, Inc.
Category: Standards Track P. Frojdh
ISSN: 2070-1721 Ericsson AB
August 2011
The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types
“Bucket”媒体类型的“codec”和“Profiles”参数
Abstract
摘要
Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content-Type alone if the content can be rendered.
存在多个MIME类型/子类型组合，它们可以包含不同的媒体格式。因此，接收代理需要检查此类媒体内容的细节，以确定在给定一组可用编解码器的情况下是否可以呈现特定元素。特别是当终端系统具有有限的资源，或者到终端系统的连接具有有限的带宽时，仅从内容类型了解内容是否可以呈现是很有帮助的。
This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.
本文档指定了两个参数“codecs”和“profiles”，它们与各种MIME类型或类型/子类型组合一起使用，以明确指定包含在整个容器格式中的媒体格式所使用的编解码器或配置文件。本文件淘汰了RFC 4281；RFC 4281定义了“codecs”参数，本文件以向后兼容的方式保留该参数，并进行了少量澄清；“profiles”参数由本文档添加。
By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).
通过使用指定用于呈现包含媒体的特定编解码器标记内容，接收系统可以确定终端系统是否支持编解码器，如果不支持，则可以采取适当的操作（例如拒绝内容、发送情况通知、将内容转换为支持的类型、获取和安装所需的编解码器、进一步检查以确定是否足以支持所示编解码器的子集等）。
Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean.
类似地，简档可以向接收器提供内容符合的规范的总体指示。这表明容器格式及其内容与某些规范兼容。接收者可以通过检查它支持哪些声明的概要文件以及它们的含义，来计算出它能够处理和呈现内容的程度。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6381.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6381.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. The 'Codecs' Parameter ..........................................5
3.1. Introduction ...............................................5
3.2. Generic Syntax .............................................7
3.3. ISO Base Media File Format Name Space ......................8
3.4. ISO-Family Syntax .........................................11
3.5. Use in Additional Media Types .............................11
3.6. Examples ..................................................12
3.7. Additional Media Feature Details ..........................12
4. The 'Profiles' Parameter .......................................12
4.1. Introduction ..............................................12
4.2. Formal Declaration ........................................13
4.3. 'Profiles' Parameter Definition ...........................14
4.4. Profiles for Files Carrying MP4RA-Registered Brands .......14
4.5. 'Profiles' Parameter BNF Definition .......................15
5. IANA Considerations ............................................15
6. Registration ...................................................15
7. Security Considerations ........................................16
8. Differences from RFC 4281 ......................................16
9. Acknowledgements ...............................................17
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................18
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. The 'Codecs' Parameter ..........................................5
3.1. Introduction ...............................................5
3.2. Generic Syntax .............................................7
3.3. ISO Base Media File Format Name Space ......................8
3.4. ISO-Family Syntax .........................................11
3.5. Use in Additional Media Types .............................11
3.6. Examples ..................................................12
3.7. Additional Media Feature Details ..........................12
4. The 'Profiles' Parameter .......................................12
4.1. Introduction ..............................................12
4.2. Formal Declaration ........................................13
4.3. 'Profiles' Parameter Definition ...........................14
4.4. Profiles for Files Carrying MP4RA-Registered Brands .......14
4.5. 'Profiles' Parameter BNF Definition .......................15
5. IANA Considerations ............................................15
6. Registration ...................................................15
7. Security Considerations ........................................16
8. Differences from RFC 4281 ......................................16
9. Acknowledgements ...............................................17
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................18
One of the original motivations for MIME is the ability to identify the specific media type of a message part. However, due to various factors, it is not always possible from looking at the MIME type and subtype to know which specific media formats are contained in the body part or which codecs are indicated in order to render the content.
MIME最初的动机之一是能够识别消息部分的特定媒体类型。但是，由于各种因素，查看MIME类型和子类型并不总是能够知道主体部分中包含哪些特定媒体格式，或者为了呈现内容指示哪些编解码器。
There are several media type/subtypes (either currently registered or deployed with registration pending) that contain codecs chosen from a set. In the absence of the parameters described here, it is necessary to examine each media element in order to determine the codecs or other features required to render the content. For example, video/3gpp may contain any of the video formats H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate - WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or Enhanced aacPlus, as specified in [3GPP-Formats].
有几种媒体类型/子类型（当前已注册或已部署且注册挂起）包含从集合中选择的编解码器。在缺少此处描述的参数的情况下，有必要检查每个媒体元素，以确定呈现内容所需的编解码器或其他功能。例如，视频/3gpp可以包含任何视频格式H.263简档0、H.263简档3、H.264、MPEG-4简单简档和/或任何音频格式自适应多速率（AMR）、自适应多速率宽带（AMR-WB）、扩展AMR-WB、高级音频编码（AAC）或增强aacPlus，如[3gpp格式]中所规定。
In some cases, the specific codecs can be determined by examining the header information of the media content. While this isn't as bad as examining the entire content, it still requires specialized knowledge of each format and is resource consumptive.
在某些情况下，可以通过检查媒体内容的头部信息来确定特定编解码器。虽然这并不像检查整个内容那么糟糕，但它仍然需要对每种格式的专门知识，而且会消耗资源。
This ambiguity can be a problem for various clients and servers. For example, it presents a significant burden to Multimedia Messaging (MMS) servers, which must examine the media sent in each message in order to determine which codecs are required to render the content. Only then can such a server determine if the content requires transcoding or specialized handling prior to being transmitted to the handset.
对于各种客户端和服务器来说，这种模糊性可能是一个问题。例如，它给彩信（MMS）服务器带来了巨大的负担，这些服务器必须检查每条消息中发送的媒体，以确定需要哪些编解码器来呈现内容。只有这样，这样的服务器才能确定内容在传输到手机之前是否需要转码或专门处理。
Additionally, it presents a challenge to smart clients on devices with constrained memory, processing power, or transmission bandwidth (such as cellular telephones and PDAs). Such clients often need to determine in advance if they are currently capable of rendering the content contained in an MMS or email message.
此外，它对内存、处理能力或传输带宽受限的设备（如蜂窝电话和PDA）上的智能客户端提出了挑战。此类客户端通常需要提前确定当前是否能够呈现彩信或电子邮件中包含的内容。
Ambiguity:
歧义：
o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or Enhanced aacPlus contents as specified in [3GPP-Formats].
o 音频/3gpp可以包含[3gpp格式]中指定的AMR、AAC、AMR-WB、扩展AMR-WB或增强aacPlus内容。
o audio/3gpp2 can contain AMR, AAC, 13K (as per [RFC3625]), Enhanced Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or Variable Multi Rate WideBand (VMR-WB), as specified in [3GPP2-Formats].
o 音频/3gpp2可以包含AMR、AAC、13K（根据[RFC3625]）、增强型可变速率编解码器（EVRC）、可选模式声码器（SMV）或可变多速率宽带（VMR-WB），如[3gpp2格式]中所述。
o video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC, or Enhanced aacPlus, as specified in [3GPP-Formats].
o 视频/3gpp可以包含H.263配置文件0、H.263配置文件3、H.264、MPEG-4简单配置文件和/或AMR、AMR-WB、扩展AMR-WB、AAC或增强aacPlus，如[3gpp格式]中所述。
o video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [RFC3625]), EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats].
o 视频/3gpp2可以包含H.263配置文件0、H.263配置文件3、H.264、MPEG-4简单配置文件和/或AMR、AAC、13K（根据[RFC3625]）、EVRC、SMV或VMR-WB，如[3gpp2格式]中所规定。
o audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 or registered at the MP4 registration authority [MP4RA].
o 音频/mp4可以包括在MPEG-1、MPEG-2、MPEG-4中定义的或在mp4注册机构[MP4RA]注册的任何编解码器。
o video/mp4 has the same issues as audio/mp4, and in addition many video codecs, and especially the MPEG codecs, have a variety of profiles and levels, not all of which are supported by every implementation.
o 视频/mp4与音频/mp4具有相同的问题，此外，许多视频编解码器，尤其是MPEG编解码器，具有各种配置文件和级别，并非所有实现都支持这些配置文件和级别。
Note that there are additional media types that are ambiguous, but are outside the scope of this document, including:
请注意，还有其他不明确但不在本文档范围内的介质类型，包括：
o video/mpeg4-generic, which can contain anything allowed by the MPEG-4 specification, or any codec registered with the MP4 registration authority [MP4RA];
o 视频/mpeg4通用，可包含MPEG-4规范允许的任何内容，或在MP4注册机构[MP4RA]注册的任何编解码器；
With each "bucket" type, a receiving agent only knows that it has a container format. It doesn't even know whether content that is labeled video/3gpp or video/3gpp2 contains video; it might be audio only, audio and video, or video only.
对于每个“bucket”类型，接收代理只知道它有一个容器格式。它甚至不知道标记为video/3gpp或video/3gpp2的内容是否包含视频；它可能是纯音频、音频和视频或纯视频。
A solution that permits a receiving agent to determine the specific codecs or profiles required to render media content would help provide efficient and scalable servers, especially for Multimedia Messaging (MMS), and aid the growth of multimedia services in wireless networks.
允许接收代理确定呈现媒体内容所需的特定编解码器或配置文件的解决方案将有助于提供高效和可扩展的服务器，特别是用于彩信（MMS），并有助于无线网络中多媒体服务的增长。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] .
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
The syntax in this document uses the BNF rules specified in [RFC2045] and [RFC2231].
本文档中的语法使用[RFC2045]和[RFC2231]中指定的BNF规则。
This section adds a parameter to allow unambiguous specification of all codecs indicated to render the content in the MIME part. This parameter is optional in all current types to which it is added. Future types that contain ambiguity are strongly encouraged to include this parameter.
本节添加了一个参数，以允许明确指定用于呈现MIME部分内容的所有编解码器。此参数在添加到的所有当前类型中都是可选的。强烈建议包含歧义的未来类型包含此参数。
This parameter applies to:
此参数适用于：
1. Files in the family based on the ISO Base Media File Format [ISO14496-12] called "ISO family files" in this specification.
1. 基于ISO基本媒体文件格式[ISO14496-12]的系列文件，在本规范中称为“ISO系列文件”。
2. The QuickTime file format, owned by Apple, Inc.
2. QuickTime文件格式，归苹果公司所有。
This includes the media types:
这包括媒体类型：
1. audio/3gpp, video/3gpp [RFC3839]
1. 音频/3gpp、视频/3gpp[RFC3839]
2. audio/3gpp2, video/3gpp2 [RFC4393]
2. 音频/3gpp2、视频/3gpp2[RFC4393]
3. audio/mp4, video/mp4, application/mp4 [RFC4337]
3. 音频/mp4、视频/mp4、应用程序/mp4[RFC4337]
4. video/quicktime
4. 视频/快速时间
5. application/mp21 (see note below)
5. 应用程序/mp21（见以下注释）
Note that MPEG-21 files under the type application/mp21 may, but are not required to, contain a top-level 'moov' atom providing a timed, coded, resource. The 'codecs' parameter SHOULD only be used for MPEG-21 files when this timed material is also present in the file.
请注意，application/mp21类型下的MPEG-21文件可能（但不要求）包含顶级“moov”原子，提供定时、编码的资源。“codecs”参数应仅用于MPEG-21文件，如果该文件中也存在此定时材料。
Parameter name: codecs
参数名称：编解码器
Parameter value: A single value, or a comma-separated list of values identifying the codec(s) indicated to render the content in the body part.
参数值：单个值或逗号分隔的值列表，用于标识指示用于呈现正文部分内容的编解码器。
Each value consists of one or more dot-separated elements. The name space for the first element is determined by the MIME type. The name space for each subsequent element is determined by the preceding element. The precise syntax is given below in the Generic Syntax (Section 3.2).
每个值由一个或多个点分隔的元素组成。第一个元素的名称空间由MIME类型决定。每个后续元素的名称空间由前面的元素确定。下面的通用语法（第3.2节）给出了精确的语法。
Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value be enclosed in quotes.
请注意，根据[RFC2045]，某些字符（包括用于分隔多个值的逗号）要求将整个参数值括在引号中。
An element MAY include an octet that [RFC2045] requires encoding. In this case, [RFC2231] is used: an asterisk ("*") is placed at the end of the parameter name (becoming 'codecs*' instead of 'codecs'), the parameter value usually starts with two single quote ("'") characters (indicating that neither character set nor language is specified), and each octet that requires encoding is represented as a percent sign ("%") followed by two hexadecimal digits. Note that, when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be percent encoded.
元素可以包括[RFC2045]需要编码的八位字节。在这种情况下，将使用[RFC2231]：在参数名称的末尾放置一个星号（“*”）（变为“codecs*”而不是“codecs”），参数值通常以两个单引号（“”）字符开头（表示未指定字符集或语言），需要编码的每个八位字节表示为百分号(“%”，后跟两个十六进制数字。请注意，使用[RFC2231]格式时，百分号、星号和单引号字符具有特殊含义，因此必须对其本身进行百分号编码。
Examples of Generic Syntax:
codecs=a.bb.ccc.d
codecs="a.bb.ccc.d, e.fff"
codecs*=''fo%2e
codecs*="''%25%20xz, gork"
Examples of Generic Syntax:
codecs=a.bb.ccc.d
codecs="a.bb.ccc.d, e.fff"
codecs*=''fo%2e
codecs*="''%25%20xz, gork"
When the 'codecs' parameter is used, it MUST contain all codecs indicated by the content present in the body part. The 'codecs' parameter MUST NOT include any codecs that are not indicated by any media elements in the body part.
使用“codecs”参数时，它必须包含由正文部分中的内容指示的所有编解码器。“codecs”参数不得包括正文部分中任何媒体元素未指示的任何编解码器。
In some cases, not all indicated codecs are absolutely required in order to render the content. Therefore, when a receiver does not support all listed codecs, special handling might be required. For example, the media element(s) could be examined in order to determine if an unsupported codec is actually required (e.g., there may be alternative tracks (such as English and Spanish audio), there may be timed text that can be dropped, etc.).
在某些情况下，并非绝对需要所有指定的编解码器才能呈现内容。因此，当接收器不支持所有列出的编解码器时，可能需要进行特殊处理。例如，可以检查媒体元素以确定是否实际需要不受支持的编解码器（例如，可能存在替代曲目（例如英语和西班牙语音频），可能存在可丢弃的定时文本等）。
Although the encoder MUST create parameter values that are complete and accurate in 'breadth' (that is, the encoder MUST report all four-character codes used in all tracks for ISO family files, for example) receivers MUST NOT rely on the parameter values being complete in 'depth'. (If the hierarchical rules for a given code (e.g., 'qvxy') were written after a server was implemented, for example, that server would not know what elements to place after 'qvxy').
尽管编码器必须创建在“宽度”上完整且准确的参数值（即，编码器必须报告ISO系列文件的所有轨迹中使用的所有四字符代码），但接收器不得依赖在“深度”上完整的参数值。（例如，如果给定代码（例如，“qvxy”）的分层规则是在服务器实现之后编写的，则该服务器将不知道在“qvxy”之后放置哪些元素）。
Although a mismatch is not permitted by this specification, the body part is definitive of the actual codecs needed; the parameter supplied here is informative. If a receiver encounters a body part whose 'codecs' parameter contains codecs that are not indicated by any media elements, then the receiver SHOULD process the body part by discarding the information in the 'codecs' parameter.
尽管本规范不允许不匹配，但正文部分确定了所需的实际编解码器；这里提供的参数是信息性的。如果接收器遇到其“codecs”参数包含未由任何媒体元素指示的编解码器的正文部分，则接收器应通过丢弃“codecs”参数中的信息来处理正文部分。
If a receiver encounters a body part whose 'codecs' parameter does not contain all codecs indicated by the media elements, then the receiver MAY process the body part by discarding the information in the 'codecs' parameter.
如果接收器遇到其“codecs”参数不包含由媒体元素指示的所有编解码器的主体部分，则接收器可通过丢弃“codecs”参数中的信息来处理主体部分。
The 'codecs' parameter takes either of two forms. The first form is used when the value does not contain any octets that require encoding. The second form uses [RFC2231] to allow arbitrary octets to be encoded. With either form, quotes allow for commas and other characters in <tspecials> (quotes MAY be used even when not required).
“codecs”参数采用两种形式之一。当值不包含任何需要编码的八位字节时，使用第一种形式。第二种形式使用[RFC2231]允许对任意八位字节进行编码。无论采用哪种形式，引号都允许在<t特殊规范>（即使不需要引号，也可以使用引号）中使用逗号和其他字符。
This BNF uses the rules specified in [RFC2045] and [RFC2231].
此BNF使用[RFC2045]和[RFC2231]中指定的规则。
While [RFC2231] allows specification of character set and language, this parameter does not contain items intended for human consumption, and hence makes no use of language. The language element SHOULD be
虽然[RFC2231]允许指定字符集和语言，但此参数不包含供人类使用的项目，因此不使用语言。语言元素应该是
omitted; the character set SHOULD also be omitted. A receiver MAY ignore language and MAY choose to support only US-ASCII [RFC1345] and UTF-8 [RFC3629].
省略；字符集也应该省略。接收机可以忽略语言，并且可以选择仅支持US-ASCII[RFC1345]和UTF-8[RFC3629]。
Implementations MUST NOT add comments and/or folding white space (CFWS) between the tokens except after ",". TOKEN is defined in [RFC2045], and <ext-octet> and <attribute-char> are defined in [RFC2231].
实现不得在令牌之间添加注释和/或折叠空格（CFWS），除非在“，”之后。令牌在[RFC2045]中定义，<ext octet>和<attribute char>在[RFC2231]中定义。
The BNF syntax is as follows:
BNF语法如下所示：
codecs := cod-simple / cod-fancy
cod-simple := "codecs" "=" unencodedv
unencodedv := id-simple / simp-list
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
id-simple := element
; "." reserved as hierarchy delimiter
element := 1*octet-sim
octet-sim := <any TOKEN character>
codecs := cod-simple / cod-fancy
cod-simple := "codecs" "=" unencodedv
unencodedv := id-simple / simp-list
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
id-simple := element
; "." reserved as hierarchy delimiter
element := 1*octet-sim
octet-sim := <any TOKEN character>
; Within a 'codecs' parameter value, "." is reserved
; as a hierarchy delimiter
cod-fancy := "codecs*" "=" encodedv
encodedv := fancy-sing / fancy-list
fancy-sing := [charset] "'" [language] "'" id-encoded
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
id-list := id-encoded *( "," id-encoded )
id-encoded := encoded-elm *( "." encoded-elm )
; "." reserved as hierarchy delimiter
encoded-elm := 1*octet-fancy
octet-fancy := ext-octet / attribute-char
; Within a 'codecs' parameter value, "." is reserved
; as a hierarchy delimiter
cod-fancy := "codecs*" "=" encodedv
encodedv := fancy-sing / fancy-list
fancy-sing := [charset] "'" [language] "'" id-encoded
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
id-list := id-encoded *( "," id-encoded )
id-encoded := encoded-elm *( "." encoded-elm )
; "." reserved as hierarchy delimiter
encoded-elm := 1*octet-fancy
octet-fancy := ext-octet / attribute-char
DQUOTE := %x22 ; " (double quote)
DQUOTE := %x22 ; " (double quote)
Initial name space: This document only defines values for files in the ISO Base Media File Format and QuickTime families. Other file formats may also define codec naming.
初始名称空间：此文档仅定义ISO基本媒体文件格式和QuickTime系列中的文件的值。其他文件格式也可以定义编解码器命名。
For the ISO Base Media File Format, and the QuickTime movie file format, the first element of a 'codecs' parameter value is a sample description entry four-character code as registered by the MP4 Registration Authority [MP4RA]. Values are case sensitive.
对于ISO基本媒体文件格式和QuickTime电影文件格式，“codecs”参数值的第一个元素是MP4注册机构[MP4RA]注册的样本描述条目四字符代码。值区分大小写。
Note that there are potentially multiple tracks in a file, each potentially carrying multiple sample entries (some but not all uses of the ISO Base Media File Format restrict the number of sample entries in a track to one).
请注意，一个文件中可能有多个磁道，每个磁道可能包含多个示例条目（ISO基本媒体文件格式的某些但并非全部使用将一个磁道中的示例条目数限制为一个）。
When the first element of a value is 'mp4a' (indicating some kind of MPEG-4 audio), or 'mp4v' (indicating some kind of MPEG-4 part-2 video), or 'mp4s' (indicating some kind of MPEG-4 Systems streams such as MPEG-4 BInary Format for Scenes (BIFS)), the second element is the hexadecimal representation of the MP4 Registration Authority ObjectTypeIndication (OTI), as specified in [MP4RA] and [MP41] (including amendments). Note that [MP4RA] uses a leading "0x" with these values, which is omitted here and hence implied.
当值的第一个元素是“mp4a”（表示某种MPEG-4音频）或“mp4v”（表示某种MPEG-4第2部分视频）或“mp4s”（表示某种MPEG-4系统流，例如用于场景的MPEG-4二进制格式（BIFS））时，第二个元素是[MP4RA]和[MP41]（包括修正案）中规定的MP4注册机构ObjectTypeIndication（OTI）的十六进制表示形式。请注意，[MP4RA]将前导“0x”与这些值一起使用，此处省略，因此暗示。
One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio). For this value, the third element identifies the audio ObjectTypeIndication (OTI) as defined in [MP4A] (including amendments), expressed as a decimal number.
“mp4a”的OTI值之一是40（识别MPEG-4音频）。对于该值，第三个元素标识[MP4A]（包括修改件）中定义的音频对象类型指示（OTI），表示为十进制数。
For example, AAC low complexity (AAC-LC) has the value 2, so a complete string for AAC-LC would be "mp4a.40.2".
例如，AAC低复杂度（AAC-LC）的值为2，因此AAC-LC的完整字符串应为“mp4a.40.2”。
One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2 video). For this value, the third element identifies the video ProfileLevelIndication as defined in [MP4V] (including amendments), expressed as a decimal number.
“mp4v”的OTI值之一是20（标识MPEG-4第2部分视频）。对于该值，第三个元素标识[MP4V]（包括修改件）中定义的视频配置文件级别指示，表示为十进制数。
For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so a complete string for MPEG-4 Visual Simple Profile Level 0 would be "mp4v.20.9".
例如，MPEG-4视觉简单配置文件级别0的值为9，因此MPEG-4视觉简单配置文件级别0的完整字符串应为“mp4v.20.9”。
When the first element of a value is a code indicating a codec from the Advanced Video Coding specification [AVC], specifically one of the sample entries defined in [AVC-Formats] (such as 'avc1', 'avc2', 'svc1', 'mvc1', and 'mvc2') -- indicating AVC (H.264), Scalable Video Coding (SVC), or Multiview Video Coding (MVC), the second element (referred to as 'avcoti' in the formal syntax) is the hexadecimal representation of the following three bytes in the (subset) sequence parameter set Network Abstraction Layer (NAL) unit specified in [AVC]:
当值的第一个元素是指示来自高级视频编码规范[AVC]的编解码器的代码时，特别是在[AVC格式]（例如“avc1”、“avc2”、“svc1”、“mvc1”和“mvc2”）中定义的示例项之一——指示AVC（H.264）、可伸缩视频编码（SVC）或多视图视频编码（MVC），则为第二个元素（在正式语法中称为“avcoti”）是[AVC]中指定的（子集）序列参数集网络抽象层（NAL）单元中以下三个字节的十六进制表示：
(1) profile_idc,
(1) 国际数据中心简介，
(2) the byte containing the constraint_set flags (currently constraint_set0_flag through constraint_set5_flag, and the reserved_zero_2bits), and
(2) 包含约束集标志（当前约束集0标志到约束集5标志，以及保留的0标志）的字节，以及
(3) level_idc.
(3) 一级国际数据中心。
Note that the sample entries 'avc1' and 'avc2' do not necessarily indicate that the media only contains AVC NAL units. In fact, the media may be encoded as an SVC or MVC profile and thus contain SVC or MVC NAL units. In order to be able to determine which codec is used, further information is necessary (profile_idc). Note also that reserved_zero_2bits is required to be equal to 0 in [AVC], but other values for it may be specified in the future by ITU-T or ISO/IEC.
请注意，示例条目“avc1”和“avc2”不一定表示介质仅包含AVC NAL单元。事实上，媒体可以编码为SVC或MVC配置文件，因此包含SVC或MVC NAL单元。为了能够确定使用哪种编解码器，需要进一步的信息（profile_idc）。还请注意，保留的0位要求等于[AVC]中的0，但ITU-T或ISO/IEC将来可能会指定它的其他值。
This is as previously defined in the 3GPP File Format specification 3GPP TS 26.244 [3GPP-Formats], Section A.2.2.
这与之前在3GPP文件格式规范3GPP TS 26.244[3GPP格式]第A.2.2节中的定义相同。
When SVC or MVC content is coded in an AVC-compatible fashion, the sample description may include both an AVC configuration record and an SVC or MVC configuration record. Under those circumstances, it is recommended that the two configuration records both be reported as they may contain different AVC profile, level, and compatibility indicator values. Thus, the codecs reported would include the sample description code (e.g., 'avc1') twice, with the values from one of the configuration records forming the 'avcoti' information in each.
当SVC或MVC内容以AVC兼容的方式编码时，示例描述可以包括AVC配置记录和SVC或MVC配置记录。在这些情况下，建议报告这两个配置记录，因为它们可能包含不同的AVC配置文件、级别和兼容性指示符值。因此，所报告的编解码器将包括样本描述代码（例如，“avc1”）两次，其中来自其中一个配置记录的值在每一次中形成“avcoti”信息。
id-simple :=/ id-iso
id-encoded :=/ id-iso
id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc
iso-gen := cpid *( element / encoded-elm )
; <element> used with <codecs-simple>
; <encoded-elm> used with <codecs-fancy>
;
; Note that the BNF permits "." within <element>
; and <encoded-elm> but "." is reserved as the
; hierarchy delimiter
iso-mpega := mp4a "." oti [ "." aud-oti ]
iso-mpegv := mp4v "." oti [ "." vid-pli ]
iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ]
cpid := 4(octet-simple / octet-fancy)
; <octet-simple> used with <codecs-simple>
; <octet-fancy> used with <codecs-fancy>
mp4a := %x6d.70.34.61 ; 'mp4a'
oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
avc1 := %x61.76.63.31 ; 'avc1'
avc2 := %x61.76.63.32 ; 'avc2'
svc1 := %x73.76.63.31 ; 'svc1'
mvc1 := %x6d.76.63.31 ; 'mvc1'
mvc2 := %x6d.76.63.32 ; 'mvc2'
avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
aud-oti := 1*DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v'
vid-pli := 1*DIGIT
id-simple :=/ id-iso
id-encoded :=/ id-iso
id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc
iso-gen := cpid *( element / encoded-elm )
; <element> used with <codecs-simple>
; <encoded-elm> used with <codecs-fancy>
;
; Note that the BNF permits "." within <element>
; and <encoded-elm> but "." is reserved as the
; hierarchy delimiter
iso-mpega := mp4a "." oti [ "." aud-oti ]
iso-mpegv := mp4v "." oti [ "." vid-pli ]
iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ]
cpid := 4(octet-simple / octet-fancy)
; <octet-simple> used with <codecs-simple>
; <octet-fancy> used with <codecs-fancy>
mp4a := %x6d.70.34.61 ; 'mp4a'
oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
avc1 := %x61.76.63.31 ; 'avc1'
avc2 := %x61.76.63.32 ; 'avc2'
svc1 := %x73.76.63.31 ; 'svc1'
mvc1 := %x6d.76.63.31 ; 'mvc1'
mvc2 := %x6d.76.63.32 ; 'mvc2'
avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
aud-oti := 1*DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v'
vid-pli := 1*DIGIT
This parameter MAY be specified for use with additional MIME media types.
可以指定此参数与其他MIME媒体类型一起使用。
For ISO family file formats where the name space as defined here is sufficient, all that needs to be done is to update the media type registration to specify the 'codecs' parameter with a reference to this document. For existing media types, it is generally advisable for the parameter to be optional; for new media types, the parameter MAY be optional or required, as appropriate.
对于此处定义的名称空间足够大的ISO系列文件格式，只需更新媒体类型注册以指定“codecs”参数并引用此文档即可。对于现有媒体类型，通常建议将参数设置为可选参数；对于新媒体类型，参数可能是可选的，也可能是必需的（视情况而定）。
For ISO family file formats where the name space as defined here needs to be expanded, a new document MAY update this one by specifying the additional detail.
对于需要扩展此处定义的名称空间的ISO系列文件格式，新文档可以通过指定其他详细信息来更新此文件。
For non-ISO family file formats, a new document MAY update this one by specifying the name space for the media type(s).
对于非ISO系列文件格式，新文档可以通过指定媒体类型的名称空间来更新此文件。
Content-Type: video/3gpp2; codecs="sevc, s263"
(EVRC audio plus H.263 video)
Content-Type: audio/3gpp; codecs=samr
(AMR audio)
Content-Type: video/3gpp; codecs="s263, samr"
(H.263 video plus AMR audio)
Content-Type: audio/3gpp2; codecs=mp4a.E1
(13K audio)
Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1"
(MPEG-4 Visual Simple Profile Level 0 plus 13K voice)
Content-Type: video/mp4; codecs="avc1.640028"
(H.264/AVC video, High Profile, Level 40,
e.g., DVB 720p 50Hz HDTV)
Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E"
(SVC video, Scalable High Profile, Level 30,
with a Main Profile AVC base layer, e.g., DVB 25 Hz SDTV)
Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030"
(MVC video, Stereo High Profile, Level 42,
with a High Profile base layer, e.g., as adopted in Blu-ray)
Content-Type: video/3gpp2; codecs="sevc, s263"
(EVRC audio plus H.263 video)
Content-Type: audio/3gpp; codecs=samr
(AMR audio)
Content-Type: video/3gpp; codecs="s263, samr"
(H.263 video plus AMR audio)
Content-Type: audio/3gpp2; codecs=mp4a.E1
(13K audio)
Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1"
(MPEG-4 Visual Simple Profile Level 0 plus 13K voice)
Content-Type: video/mp4; codecs="avc1.640028"
(H.264/AVC video, High Profile, Level 40,
e.g., DVB 720p 50Hz HDTV)
Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E"
(SVC video, Scalable High Profile, Level 30,
with a Main Profile AVC base layer, e.g., DVB 25 Hz SDTV)
Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030"
(MVC video, Stereo High Profile, Level 42,
with a High Profile base layer, e.g., as adopted in Blu-ray)
Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated Amendment(s) and Corrigendum(a). The actual object types are defined in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in [MP4V], Annex K." (references adjusted).
注：[MP4RA]中的OTI值20（“0x20”）表示“包括相关修正案和勘误表（a）。实际对象类型在[MP4V]中定义，并在[MP4V]附录K中规定的解码器规范信息中传达”（参考调整）。
It is sometimes helpful to provide additional details for a media element (e.g., the number of X and Y pixels, the color depth, etc.). These details are sometimes called "media features" or "media characteristics".
有时，提供媒体元素的附加细节（例如，X和Y像素的数量、颜色深度等）会有所帮助。这些细节有时被称为“媒体特征”或“媒体特征”。
When such additional features are included, the content-features [RFC2912] header provides a handy way to do so.
当包含这些附加功能时，content features[RFC2912]标题提供了一种方便的方法。
Just as some codecs have a variety of profiles (subsets of their functionality within which a bitstream can be coded), some media files can also be profiled and be associated with one or more profile identifiers of the profiles to which they conform. These profiles
正如一些编解码器具有各种配置文件（其功能的子集，可以在其中编码比特流），一些媒体文件也可以被配置文件，并与它们所符合的配置文件的一个或多个配置文件标识符相关联。这些配置文件
can indicate features of the file format itself, which codecs may be present, the profiles of those codecs, and so on. It can be advantageous to a receiving system to know the overall file profile(s) of a file; indeed, under these circumstances it may not be necessary to know the codecs themselves if they are implied by the profile.
可以指示文件格式本身的功能、可能存在哪些编解码器、这些编解码器的配置文件，等等。对接收系统来说，了解文件的总体文件简档是有利的；事实上，在这些情况下，如果概要文件暗示了编解码器，则可能没有必要了解它们本身。
The 'profiles' parameter reports on the profile(s) of the overall container format. A profile of the container format may have restrictions on not only the features of the container format itself but also on what codecs may be included, and it may indeed have restrictions on the profiles of those codecs. The 'profiles' parameter does not, however, report directly any profiles of the contained media: when such codec-specific profiles are reported, this report is part of the 'codecs' parameter. The 'profiles' parameter reports only the profile(s) applying to the complete container.
“profiles”参数报告整个容器格式的概要文件。容器格式的概要文件可能不仅对容器格式本身的特性有限制，而且对可能包含的编解码器也有限制，并且它可能确实对那些编解码器的概要文件有限制。但是，“profiles”参数不直接报告所包含媒体的任何配置文件：当报告此类特定于编解码器的配置文件时，此报告是“codecs”参数的一部分。“profiles”参数仅报告应用于完整容器的概要文件。
When the use of the 'profiles' parameter is defined for a given format, that definition SHOULD indicate that it directly reflects information in the body part, i.e., that it does not convey information beyond, or different from, what can be learnt by inspecting the body part. Although a mismatch is not permitted by this specification, the body part is definitive of the actual profiles; the parameter supplied here is informative.
当为给定格式定义“profiles”参数的使用时，该定义应表明它直接反映身体部位的信息，即它不会传递超出或不同于通过检查身体部位所能学到的信息。尽管本规范不允许出现不匹配，但车身部分是实际外形的确定部分；这里提供的参数是信息性的。
This section adds a parameter to allow unambiguous specification of the profiles to which a file claims conformance. This parameter is OPTIONAL in all current types to which it is added.
本节添加了一个参数，以允许明确指定文件声称符合的概要文件。此参数在添加到的所有当前类型中都是可选的。
This parameter applies to Box-structured (also known as atom-structured) files that have an initial box containing compatibility brands, as registered at the MP4 Registration Authority [MP4RA], such as a filetype or segment-type box. Principally, this includes files in the family based on the ISO Base Media File Format [ISO14496-12] and the QuickTime file format, owned by Apple, Inc. (A brand can indicate conformance with restrictions regarding which codecs and file format features are used, adherence to quantitative limits such as the length/size of the file, and so on.)
此参数适用于框结构（也称为atom结构）文件，这些文件的初始框包含在MP4注册机构[MP4RA]注册的兼容品牌，例如文件类型或段类型框。主要包括苹果公司拥有的基于ISO基本媒体文件格式[ISO14496-12]和QuickTime文件格式的系列文件（一个品牌可以表示符合使用哪些编解码器和文件格式功能的限制，遵守文件长度/大小等数量限制）
This includes the media types:
这包括媒体类型：
1. audio/3gpp, video/3gpp [RFC3839]
1. 音频/3gpp、视频/3gpp[RFC3839]
2. audio/3gpp2, video/3gpp2 [RFC4393]
2. 音频/3gpp2、视频/3gpp2[RFC4393]
3. audio/mp4, video/mp4 [RFC4337]
3. 音频/mp4、视频/mp4[RFC4337]
4. video/quicktime
4. 视频/快速时间
5. application/mp21
5. 应用软件/mp21
Parameter name: profiles
参数名称：profiles
Parameter value: A single value, or a comma-separated list of values identifying the profiles(s) to which the file claims conformance.
参数值：单个值或逗号分隔的值列表，用于标识文件声明符合的配置文件。
The name space is determined by the MIME type.
名称空间由MIME类型决定。
Note that, per [RFC2045], some characters (including the comma used to separate multiple values) require that the entire parameter value be enclosed in quotes.
请注意，根据[RFC2045]，某些字符（包括用于分隔多个值的逗号）要求将整个参数值括在引号中。
An element MAY include an octet that [RFC2045] requires encoding. In this case, [RFC2231] is used: an asterisk ("*") is placed at the end of the parameter name (becoming 'profiles*' instead of 'profiles'), the parameter value usually starts with two single quote ("'") characters(indicating that neither character set nor language is specified), and each octet that requires encoding is represented as a percent sign ("%") followed by two hexadecimal digits. Note that, when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning and so MUST themselves be percent encoded.
元素可以包括[RFC2045]需要编码的八位字节。在这种情况下，将使用[RFC2231]：在参数名称的末尾放置一个星号（“*”）（变为“profiles*”而不是“profiles”），参数值通常以两个单引号（“”）字符开头（表示未指定字符集或语言），每个需要编码的八位字节都用百分号（“%”）表示，后跟两个十六进制数字。请注意，使用[RFC2231]表单时，百分号、星号和单引号字符具有特殊含义，因此必须对其本身进行百分号编码。
Examples of Generic Syntax: profiles="isom,mp41,qvXt" profiles*="''%25%20xz, gork"
通用语法示例：profiles=“isom，mp41，qvXt”profiles*=“''%25%20xz，gork”
The 'profiles' parameter is an OPTIONAL parameter that indicates one or more profiles to which the file claims conformance. Like the 'codecs' parameter described above, it may occur as either 'profiles' or 'profiles*', with the same encoding rules. The value is, as for the 'codecs' parameter, a comma-separated list of profile identifiers.
“profiles”参数是一个可选参数，用于指示文件声称符合的一个或多个概要文件。与上面描述的“codecs”参数类似，它可能以“profiles”或“profiles*”的形式出现，并且具有相同的编码规则。与“codecs”参数一样，该值是以逗号分隔的配置文件标识符列表。
For any file format carrying a brand registered at the MP4 Registration Authority [MP4RA], notably files based on the ISO Base Media File Format ISO/IEC 14496-12 [ISO14496-12] and QuickTime movie files, the 'profiles' parameter MUST list exactly the major-brand, followed by the compatible-brands, as listed in the filetype box ('ftyp') or segment-type box ('styp'). The major-brand MUST be first, and MAY be removed from the compatible-brands list. (The file
对于任何带有在MP4注册机构[MP4RA]注册的品牌的文件格式，尤其是基于ISO基本媒体文件格式ISO/IEC 14496-12[ISO14496-12]的文件和QuickTime电影文件，“profiles”参数必须准确列出主要品牌，然后是兼容品牌，如文件类型框（“ftyp”）中所列或段类型框（“styp”）。主要品牌必须排在第一位，并且可以从兼容品牌列表中删除。（档案
format requires that it be repeated in the compatible-brands, but this requirement is relaxed here for compactness.)
格式要求在兼容品牌中重复，但为紧凑起见，此处放宽了此要求。）
An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4 version 1 is the major-brand and preferred use, that the file is compatible with the version of the base file format identified by 'isom', and that it is also compatible with the specification/profile 'qvXt' (whatever that may be).
例如profiles=“mp41，isom，qvXt”，表明MPEG-4版本1是主要品牌和首选用途，该文件与“isom”标识的基本文件格式版本兼容，并且还与规范/配置文件“qvXt”（无论是什么）兼容。
profiles := pro-simple / pro-fancy
pro-simple := "profiles" "=" unencodedv
pro-fancy := "profiles*" "=" encodedv
profiles := pro-simple / pro-fancy
pro-simple := "profiles" "=" unencodedv
pro-fancy := "profiles*" "=" encodedv
IANA has replaced references to [RFC4281] with references to this document in the "MIME Media Types" registry, thereby indicating that the 'codecs' and/or 'profiles' parameters are optional for the following media types (as listed in Sections 3 and 4):
IANA已在“MIME媒体类型”注册表中将对[RFC4281]的引用替换为对本文档的引用，从而表明“编解码器”和/或“配置文件”参数对于以下媒体类型是可选的（如第3节和第4节所列）：
1. audio/3gpp, video/3gpp [RFC3839]
1. 音频/3gpp、视频/3gpp[RFC3839]
2. audio/3gpp2, video/3gpp2 [RFC4393]
2. 音频/3gpp2、视频/3gpp2[RFC4393]
3. audio/mp4, video/mp4, application/mp4 [RFC4337]
3. 音频/mp4、视频/mp4、应用程序/mp4[RFC4337]
4. video/quicktime
4. 视频/快速时间
5. application/mp21
5. 应用软件/mp21
The MPEG4 Registration Authority can be consulted for the most up-to-date registration of sub-parameters for the codecs type, for specific codecs.
有关特定编解码器的编解码器类型的子参数的最新注册信息，请咨询MPEG4注册机构。
The 'codecs' parameter itself does not alter the security considerations of any of the media types with which it is used. Each audio and video media type has its own set of security considerations that continue to apply, regardless of the use of the 'codecs' parameter.
“codecks”参数本身不会改变使用它的任何媒体类型的安全考虑。每种音频和视频媒体类型都有自己的一组安全注意事项，无论使用“codecs”参数如何，这些注意事项都将继续适用。
An incorrect 'codecs' parameter might cause media content to be received by a device that is not capable of rendering it or might cause media content not to be sent to a device that is capable of receiving it. An incorrect 'codecs' parameter is therefore capable of some types of denial-of-service attacks. However, this is most likely to arise by accident, as an attacker capable of altering media data in transit could cause more harm by altering the media format itself, or even the content type header, rather than just the 'codecs' parameter of the content type header.
不正确的“codecs”参数可能导致无法呈现媒体内容的设备接收媒体内容，或者可能导致媒体内容无法发送到能够接收媒体内容的设备。因此，不正确的“codecs”参数可能导致某些类型的拒绝服务攻击。但是，这很可能是偶然发生的，因为能够在传输过程中更改媒体数据的攻击者可能会通过更改媒体格式本身，甚至内容类型标头，而不仅仅是内容类型标头的“codecs”参数，造成更大的伤害。
To the extent that a receiver reacts to a 'codecs' parameter that indicates an unsupported codec, by fetching and installing the required codecs, such reaction needs to be performed carefully and in accord with the system's normal validity and security checks and procedures.
如果接收器通过获取和安装所需的编解码器，对指示不受支持的编解码器的“codecs”参数作出反应，则需要根据系统的正常有效性和安全性检查和程序谨慎执行此类反应。
1. Improved the introduction and other supporting and explanatory text;
1. 改进了导言和其他支持性和解释性文本；
2. improved the references;
2. 改进参考文献；
3. clarified the MIME types to which the parameters apply, and clarified the consequent IANA actions;
3. 阐明参数适用的MIME类型，并阐明随后的IANA操作；
4. added the 'profiles' parameter;
4. 添加了“profiles”参数；
5. fixed an error in the BNF, where it did not correspond to either the examples or common usage;
5. 修复了BNF中的一个错误，该错误与示例或常用用法不一致；
6. added the definition of the sub-parameters for the AVC family of codecs;
6. 添加了AVC编解码器系列的子参数定义；
7. added a security consideration for possible triggering of downloads;
7. 增加了可能触发下载的安全考虑；
8. updated acknowledgments.
8. 更新确认。
Harinath Garudadri provided a great deal of help, which is very much appreciated. Mary Barnes and Bruce Lilly provided detailed and helpful comments. Reviews and comments by Sam Hartman, Russ Housley, and Bert Wijnen were much appreciated. Chris Newman carefully reviewed and improved the BNF.
Harinath Garudadri提供了大量帮助，我们对此深表感谢。玛丽·巴恩斯和布鲁斯·莉莉提供了详细而有益的评论。Sam Hartman、Russ Housley和Bert Wijnen的评论和评论非常受欢迎。Chris Newman仔细审查并改进了BNF。
Christian Timmerer helped with the MPEG-21 material, and Thomas Schierl and Yago Sanchez helped with SVC and MVC.
克里斯蒂安·蒂默尔（Christian Timmer）帮助制作MPEG-21素材，托马斯·席尔（Thomas Schierl）和雅戈·桑切斯（Yago Sanchez）帮助制作SVC和MVC。
[3GPP-Formats] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244.
[3GPP格式]第三代合作伙伴项目，“技术规范组服务和系统方面；透明端到端分组交换流媒体服务（PSS）；3GPP文件格式（3GP）”，3GPP TS 26.244。
[AVC] "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, ISO/ IEC 14496-10:2009.
[AVC]“通用视听服务的高级视频编码”，ITU-T建议H.264，ISO/IEC 14496-10:2009。
[AVC-Formats] "Information technology -- Coding of audio-visual objects -- Part 15: Advanced Video Coding (AVC) file format", ISO/IEC 14496-15:2010.
[AVC格式]“信息技术——视听对象的编码——第15部分：高级视频编码（AVC）文件格式”，ISO/IEC 14496-15:2010。
[ISO14496-12] "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/IEC 14496-12:2008.
[ISO14496-12]“信息技术——视听对象的编码——第12部分：ISO基本媒体文件格式”，ISO/IEC 14496-12:2008。
[MP4RA] "MP4REG, The MPEG-4 Registration Authority", <http://www.mp4ra.org>.
[MP4RA]“MP4REG，MPEG-4注册机构”<http://www.mp4ra.org>.
[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月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC2912] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[RFC2912]Klyne，G.“为MIME内容指示媒体功能”，RFC 2912，2000年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3839] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
[RFC3839]Castagno，R.和D.Singer，“第三代合作伙伴关系项目（3GPP）多媒体文件的MIME类型注册”，RFC 38392004年7月。
[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月。
[RFC4337] Y Lim and D. Singer, "MIME Type Registration for MPEG-4", RFC 4337, March 2006.
[RFC4337]Y Lim和D.Singer，“MPEG-4的MIME类型注册”，RFC 4337，2006年3月。
[RFC4393] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia Files", RFC 4393, March 2006.
[RFC4393]Garudadri，H.，“3GPP2多媒体文件的MIME类型注册”，RFC 4393，2006年3月。
[3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 File Formats for Multimedia Service", <http:// www.3gpp2.org/Public_html/specs/ C.S0050-0_v1.0_121503.pdf>.
[3GPP2格式]第三代合作项目2，“多媒体服务的3GPP2文件格式”，<http://www.3GPP2.org/Public\u html/specs/C.S0050-0\u v1.0\u 121503.pdf>。
[MP41] "Information technology--Coding of audio-visual objects -- Part 1: Systems", ISO/IEC 14496-1:2010.
[MP41]“信息技术——视听对象的编码——第1部分：系统”，ISO/IEC 14496-1-2010。
[MP4A] "Information technology--Coding of audio-visual objects -- 3: Audio", ISO/IEC 14496-3:2009.
[MP4A]“信息技术——视听对象的编码——3：音频”，ISO/IEC 14496-3-2009。
[MP4V] "Information technology--Coding of audio-visual objects -- Part 2: Visual", ISO/IEC 14496-2:2004.
[MP4V]“信息技术——视听对象的编码——第2部分：视觉”，ISO/IEC 14496-2:2004。
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, June 1992.
[RFC1345]Simonsen，K.，“字符助记符和字符集”，RFC13451992年6月。
[RFC3625] Gellens, R. and H. Garudadri, "The QCP File Format and Media Types for Speech Data", RFC 3625, September 2003.
[RFC3625]Gellens，R.和H.Garudadri，“语音数据的QCP文件格式和媒体类型”，RFC 36252003年9月。
Authors' Addresses
作者地址
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 US
美国加利福尼亚州圣地亚哥Morehouse大道5775号Randall Gellens高通公司，邮编92121
EMail: rg+ietf@qualcomm.com
EMail: rg+ietf@qualcomm.com
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 US
David Singer苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 996 1010
EMail: singer@apple.com
Phone: +1 408 996 1010
EMail: singer@apple.com
Per Frojdh Ericsson AB Ericsson Research Stockholm SE-164 80 Sweden
Per Frojdh Ericsson AB Ericsson Research斯德哥尔摩SE-164 80瑞典
Phone: +46 10 7190000
EMail: Per.Frojdh@ericsson.com
Phone: +46 10 7190000
EMail: Per.Frojdh@ericsson.com