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
        
1. Introduction
1. 介绍

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),并有助于无线网络中多媒体服务的增长。

2. Conventions Used in This Document
2. 本文件中使用的公约

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规则。

3. The 'Codecs' Parameter
3. “编解码器”参数
3.1. Introduction
3.1. 介绍

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”参数中的信息来处理主体部分。

3.2. Generic Syntax
3.2. 泛型语法

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系列中的文件的值。其他文件格式也可以定义编解码器命名。

3.3. ISO Base Media File Format Name Space
3.3. ISO基本媒体文件格式名称空间

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