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
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.
この文書では、2つのパラメータ内に含まれるメディアフォーマットによって使用されるコーデックの明確な指定を可能にするために、様々なMIMEタイプまたはタイプ/サブタイプの組み合わせで使用される「コーデック」と「プロファイル」、またはプロファイル（複数可）を指定し全体的なコンテナフォーマット。この文書はRFC 4281を廃止します。 RFC 4281は、このドキュメントがマイナー明確化との後方互換性のある方法で保持する「コーデック」パラメータを定義します。 「プロファイル」パラメータは、このドキュメントで追加されます。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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）、[3GPP-フォーマット]で指定され、AMR-WB、アドバンストオーディオコーディング（AAC）、または拡張aacPlus対応を拡張。
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などの）制約されたメモリ、処理能力、または伝送帯域幅を持つデバイス上のスマートクライアントへの挑戦を提示します。彼らは現在、MMSや電子メールメッセージに含まれるコンテンツをレンダリングすることができる場合には、このようなクライアントは、多くの場合、事前に決定する必要があります。
Ambiguity:
あいまいさ：
o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or Enhanced aacPlus contents as specified in [3GPP-Formats].
[3GPP-フォーマット]で指定されるように、Oオーディオ/ 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は、拡張可変レートコーデック（EVRC）、選択可能モードボコーダ（SMV）、またはで指定されたように、可変マルチレート広帯域（VMR-WB）、[3GPP2（[RFC3625]に従って）AMR、AAC、13Kを含有することができます-formats]。
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は、プロファイルとレベルの多様性を持って、多くのビデオコーデック、および特にMPEGコーデックをオーディオ/ mp4形式と同じ問題があり、それに加えて、いないすべては、すべての実装によってサポートされています。
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.
各「バケット」タイプでは、受信エージェントは、それがコンテナフォーマットを持っていることを知っています。それも、ビデオ/ 3GPPまたはビデオ/ 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] .
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります「要求レベルを示すためのRFCsにおける使用のためのキーワード」[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ベースメディアファイルフォーマットに基づきます。
This includes the media types:
これは、メディアタイプが含まれています。
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」原子を含有することが必要とされないことに留意されたいです。このタイミング材料はまた、ファイル内に存在するときに「コーデック」パラメータは、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).
各値は、1つまたは複数のドットで区切られた要素から成ります。最初の要素の名前空間には、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]が使用される：アスタリスク（「*」）は、パラメータ名の末尾に配置されている（代わりに「コーデック」の「コーデック*」となる）、パラメータ値は通常、「（二単一引用符で始まります「『）文字（いずれも文字セットや言語が指定されていることを示す）、及び符号化を必要とする各オクテットは、パーセント記号（として表され、』 2つの16進数字が続く％」）。 [RFC2231]フォームを使用する場合は、パーセント記号、アスタリスク、および単一引用符は特別な意味を持っているので、自身がパーセント符号化しなければならない、ということに注意してください。
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.
「コーデック」パラメータを使用する場合には、ボディ部に存在するコンテンツで示されるすべてのコーデックを含まなければなりません。 「コーデック」パラメータは、本体部の任意のメディア要素で示されていない任意のコーデックを含んではいけません。
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ファミリーファイル用のすべてのトラックで使用されるすべての4文字のコードを報告しなければなりません）レシーバはされたパラメータ値に依存してはなりません「深さ」で完了します。 （与えられたコード（例えば、「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.
不一致がこの仕様によって許可されていないが、本体部分が必要な実際のコーデックの決定的です。ここで指定されたパラメータは有益です。受信機は、その「コーデック」パラメータは、任意のメディア要素で示されていないコーデックを含んでいる身体の部分に遭遇した場合、受信機は「コーデック」パラメータの情報を破棄することによって身体部分を処理しなければなりません。
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.
受信機は、その身体の一部に遭遇した場合は「コーデック」パラメータは、メディア要素で示されるすべてのコーデックが含まれていない場合、受信機は、「コーデック」パラメータの情報を破棄することにより、身体の一部を処理することができます。
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).
「コーデック」パラメータは、次の2つの形式のいずれかを取ります。値は、符号化を必要とする任意のオクテットを含んでいない場合に最初のフォームが使用されます。第2の形態は、任意のオクテットを符号化することを可能にする[RFC2231]を使用します。フォームのいずれかで、引用符が<tspecials>（引用符は必要ありません場合でも使用することがあります）にカンマやその他の文字を可能にします。
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 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].
[RFC2231]は、文字セットと言語を指定できますが、このパラメータは、人間の消費のために意図アイテムが含まれ、ひいては言語のない利用しません。言語要素が省略されるべきです。文字セットも省略する必要があります。受信機は言語を無視するかもしれなくて、唯一の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オクテット>と<属性チャーは> [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>
コーデック：=タラシンプル/タラファンシータラ - シンプル：= "コーデック" "=" unencodedv unencodedv：= ID-シンプル/簡体字リストSIMP-リスト：= DQUOTEのID-シンプル*（ "" ID-シンプル） DQUOTE ID-簡単：=エレメント。 ""階層区切り文字要素として予約：= 1 *オクテット-SIMオクテット-SIM：= <任意の文字TOKEN>
; 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
; 「コーデック」パラメータ値の中で、「」予約されています。階層デリミタタラ空想として：= "コーデック*" "=" encodedv encodedv：=空想-歌う/空想リスト空想-歌う：= [文字セット] " '" [言語] "'" IDエンコード。パーサは<言語>を無視してもよいです。パーサは唯一のUS-ASCIIとUTF-8空想リストをサポートすることがあります。= DQUOTE [文字セット] " '" [言語] "'" ID-リストDQUOTE。パーサは<言語>を無視してもよいです。パーサはUS-ASCIIとUTF-8のIDリストをサポートすることがあります。= ID-エンコード*（ "" ID-エンコード）ID-エンコード：=エンコード-ニレ*（エンコード-ELMを ""）; ""階層符号化されたデリミタ、ニレとして予約：= 1 *オクテット-空想オクテット空想：= EXT-オクテット/属性チャー
DQUOTE := %x22 ; " (double quote)
DQUOTE：=％X22; "（二重引用符）
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.
MP4の登録機関[MP4RA]で登録されたとしてISOベースメディアファイルフォーマット、およびQuickTimeムービーファイルの形式については、「コーデック」パラメータ値の最初の要素は、サンプル記述エントリ4文字のコードです。値は、大文字と小文字が区別されます。
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.
値の最初の要素は、（MPEG-4オーディオのいくつかの種類を示す）「MP4A」、または「mp4v」（MPEG-4パート2ビデオのいくつかの種類を示す）、または「MP4S」（MPEGのいくつかの種類を示す情報である場合（）修正を含む[MP4RA]および[MP41]指定されるよう-4システムのようなシーンのためのMPEG-4バイナリフォーマット（BIFS）等のストリーム）、第2の要素は、MP4登録機関ObjectTypeIndication（OTI）の16進表現です。 【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の値の1つが（MPEG-4オーディオを識別する）40です。この値は、第3の要素が[MP4A（修正を含む）で定義されているオーディオObjectTypeIndication（OTI）を識別し、10進数で表現。
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の値の1つが（MPEG-4パート2ビデオを識別する）20です。この値は、[MP4V]（修正を含む）で定義されるように第三の要素は、ビデオProfileLevelIndicationを識別する、10進数として表現。
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]、このような「avc1」として[AVC-フォーマット]で定義されたサンプルエントリ（「AVC2」、「SVC1」の具体的一つからコーデックを示すコードである場合、 'MVC1'、及び 'MVC2'） - スケーラブルビデオ（SVC）をコード、または正式な構文で 'avcoti' というマルチビュービデオ）（MVC符号化、第二要素（）、AVC（H.264）を示します[AVC]で指定（サブセット）シーケンスパラメータセット、ネットワーク抽象レイヤ（NAL）ユニット内の次の3バイトの16進表現です。
(1) profile_idc,
（1）profile_idc、
(2) the byte containing the constraint_set flags (currently constraint_set0_flag through constraint_set5_flag, and the reserved_zero_2bits), and
（2）constraint_setフラグ（現在constraint_set5_flagを通してconstraint_set0_flag、及びreserved_zero_2bits）を含むバイト、及び
(3) level_idc.
（3）level_idc。
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）が必要です。ノートはまたreserved_zero_2bitsは[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プロファイル、レベル、および互換性指標値を含んでいてもよいように、2つの構成レコードが報告され、両方のことをお勧めします。したがって、報告されたコーデックは、それぞれの「avcoti」情報を構成するコンフィギュレーションレコードの1つの値を用いて、二回サンプル記述コード（例えば、「avc1」）を含むであろう。
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-簡単：= / IDイソIDエンコード：= / ID-イソID-ISO：= ISO-GEN / ISO-MPEGA /イソmpegv / ISO-AVC ISO-GEN：= CPID *（要素/ encoded-ニレ）; <要素> <コーデック-シンプル>で使用します。 <コーデック-ファンシー>と共に使用<符号化され、ELM>。 ; BNFの許すことに注意してください「」 <要素>内。そして、<エンコード-ELM>が、 ""予約されています。階層区切り文字のISO-MPEGA：= MP4A "" [OTI "" AUD-OTI] ISO-mpegv： "" = mp4v [OTI "" VID-PLI]イソAVC：= avc1 / AVC2 / SVC1 / MVC1 / MVC2の[ "" avcoti] CPID：= 4（オクテット簡単/オクテット空想）。 <オクテットシンプルな> <コーデック-シンプル>で使用します。 <オクテットファンシー> <コーデック-ファンシー> MP4Aと共に使用：=％x6d.70.34.61。 'MP4A' OTI：= 2（DIGIT / "A" / "B" / "C" / "D" / "E" / "F"）。 avc1省略大手 "0X"：=％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"）。省略 "0X" を主要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ファミリーのファイル形式の名前空間の場合は、ここで定義されるように行われる必要があることすべてが、このドキュメントを参照して、「コーデック」パラメータを指定するには、メディアタイプの登録を更新することで、十分です。既存のメディアタイプの場合、パラメータがオプションであるためには、一般的に賢明です。新しいメディアタイプのため、パラメータは必要に応じて、オプションまたは必要になることがあります。
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家族のファイル形式の場合は、新しい文書が追加の詳細を指定することで、この1を更新することができます。
For non-ISO family file formats, a new document MAY update this one by specifying the name space for the media type(s).
非ISO家族のファイル形式については、新しい文書は、メディアタイプ（S）のための名前空間を指定することで、この1を更新することができます。
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)
コンテンツタイプ：ビデオ/ 3GPP2。コーデック= "sevc、S263"（EVRCオーディオプラスH.263ビデオ）のContent-Type：オーディオ/ 3GPP;コーデック= SAMR（AMRオーディオ）のContent-Type：ビデオ/ 3GPP;コーデック= "S263、SAMR"（H.263ビデオプラスAMRオーディオ）のContent-Type：オーディオ/ 3GPP2。コーデック= mp4a.E1（13Kオーディオ）のContent-Type：ビデオ/ 3GPP2。コーデック= "mp4v.20.9、mp4a.E1"（MPEG-4ビジュアルシンプルプロファイルレベル0プラス13K音声）のContent-Type：ビデオ/ MP4;コーデック= "avc1.640028"（H.264 / AVCビデオ、ハイプロファイル、レベル40、例えば、DVBの720pの50HzのHDTV）のContent-Type：ビデオ/ MP4;コーデック= "svc1.56401E、avc1.4D401E"（メインプロファイルAVCベースレイヤを有するSVCビデオ、スケーラブルハイプロファイル、レベル30、例えば、DVB 25 HzのSDTV）のContent-Type：ビデオ/ MP4。コーデック（ブルーレイに採用され、例えばハイプロファイルベース層とMVCビデオ、ステレオハイプロファイル、レベル42、、、）=「mvc1.800030、avc1.640030」
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).
注：OTI値を20（[MP4RA]における「0x20には」）「関連修正（単数または複数）を含み、正誤表（a）は、実際のオブジェクトタイプが[MP4V]で定義され、[MP4V]で指定されるようDecoderSpecificInfoに搬送されていると言います、附属書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.
そのような追加機能が含まれている場合、コンテンツ・機能[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.
一部のコーデックは、プロファイル（ビットストリームを符号化することができ、その中、それらの機能のサブセット）の多様性を持っているのと同じように、いくつかのメディアファイルもプロファイリングすることができ、それらが準拠するプロファイルの1つの以上のプロファイル識別子に関連付けられます。これらのプロファイルは、その上、これらのコーデックのプロファイル、存在することができるコーデック、ファイルフォーマット自体の特徴を示す、とすることができます。ファイルの全体的なファイルプロファイル（単数または複数）を知っている受信システムに有利であり得ます。確かに、これらの状況下では、それらがプロファイルによって暗示されている場合はコーデック自分自身を知ることが必要ではないかもしれません。
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.
「プロファイル」パラメータは、全体的なコンテナフォーマットのプロファイル（複数可）に報告します。コンテナフォーマットのプロファイルは、コンテナフォーマット自体の機能も含まれ得るもののコーデックではないだけに制限を有していてもよく、そしてそれは確かにそれらのコーデックのプロファイルに制限を有することができます。こうしたコーデック固有のプロファイルが報告されている場合、このレポートは、「コーデック」パラメータの一部です：「プロファイル」パラメータが含まれるメディアのレポートは、直接任意のプロファイル、しかし、しません。完全なコンテナに適用する「プロファイル」パラメータレポートのみプロファイル（複数可）。
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.
「プロファイル」パラメータの使用が与えられたフォーマットのために定義されている場合、その定義は、検査によって知ることができるもの、それは超えて情報を伝える、または異なっていないこと、すなわち、それが直接身体の部分に情報を反映していることを示す必要があります体の一部。不一致がこの仕様によって許可されていませんが、体の部分は、実際のプロファイルの決定的です。ここで指定されたパラメータは有益です。
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.)
そのようなファイルタイプまたはセグメント型ボックスとしてMP4登録機関[MP4RA]に登録され、このパラメータは、互換ブランドを含む最初のボックスを持つファイル（また、原子構造として知られている）ボックス構造に適用されます。原則的に、これは、ISOベースメディアファイルフォーマットに基づいて、家族内のファイル[ISO14496-12]とApple、Inc.が所有するQuickTimeファイルフォーマット、（ブランドはコーデックやファイル形式の機能を使用しているに関する制限への適合を示すことができますが含まれてこのようなように長さ/ファイルのサイズ、およびなどの定量的限界に、付着）。
This includes the media types:
これは、メディアタイプが含まれています。
Parameter name: profiles
パラメータ名：プロファイル
Parameter value: A single value, or a comma-separated list of values identifying the profiles(s) to which the file claims conformance.
パラメーター値：単一の値、またはファイルが適合を主張プロファイル（S）への特定の値のカンマ区切りリスト。
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]が使用される：アスタリスク（「*」）パラメータ名の末尾に配置されている（代わりに「プロファイル」の「プロフィール*」となる）、パラメータ値は通常、「（二単一引用符で始まります「『）文字（いずれも文字セットや言語が指定されていることを示す）、及び符号化を必要とする各オクテットは、パーセント記号（として表され、』 2つの16進数字が続く％」）。 [RFC2231]フォームを使用する場合は、パーセント記号、アスタリスク、および単一引用符は特別な意味を持っているので、自身がパーセント符号化しなければならない、ということに注意してください。
Examples of Generic Syntax:
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.
「プロファイル」パラメータは、ファイルが適合を主張するために、1つのまたは複数のプロファイルを表すオプションのパラメータです。 「コーデック」パラメータは、上述したように、それは、同一の符号化規則を用いて、いずれかの「プロファイル」または「プロフィール*」として生じ得ます。値は「コーデック」パラメータ、プロファイル識別子のカンマ区切りのリストについては、です。
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 format requires that it be repeated in the compatible-brands, but this requirement is relaxed here for compactness.)
ISOベースメディアファイルフォーマットISO / IEC 14496-12 [ISO14496-12]とQuickTimeムービーファイルを、「プロファイル」パラメータのMUSTリストに基づいて、MP4の登録機関[MP4RA]で登録されたブランド、特にファイルを運ぶ任意のファイル形式の場合ファイルタイプボックス（「FTYP」）またはセグメントタイプボックス（「styp」）に記載されているように、互換性のある、ブランド、続いて正確に主要なブランド、。主要なブランドは、最初でなければならない、と互換性のある、ブランドのリストから除去することができます。 （ファイル形式は、それが互換性のある-ブランドで繰り返されるが、この要件はコンパクトさのためにここに緩和されている必要があります。）
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).
例では、ファイルが「ISOM」によって識別されるベースファイルフォーマットのバージョンと互換性があることを、主要なブランド、好ましい使用であるMPEG-4バージョン1いることを示す、=「MP41、ISOM、qvXt」プロファイルかもしれない、そしてまた、仕様/プロファイルと互換性があることを「qvXt」（すなわち、とすることができるものは何でも）。
profiles := pro-simple / pro-fancy pro-simple := "profiles" "=" unencodedv pro-fancy := "profiles*" "=" encodedv
プロフィール：=プロシンプル/プロファンシープロシンプル：=「プロファイル」「=」unencodedvプロ空想：=「プロファイル*」「=」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は、それによって、セクション3に記載されているように「コーデック」及び/又は「プロファイル」パラメータは、（次のメディアタイプのためのオプションであることを示し、「MIMEメディアタイプ」レジストリ内でこの文書を参照して、[RFC4281]への参照を交換していると4）：
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.
「コーデック」パラメータ自体は、それが使用しているメディアタイプのいずれかのセキュリティ上の考慮事項を変更しません。各オーディオとビデオのメディアタイプに関係なく、「コーデック」パラメータの使用、引き続き適用されたセキュリティ上の考慮事項の独自のセットを持っています。
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.
間違った「コーデック」パラメータは、メディアコンテンツがそれをレンダリングできない場合、またはそれを受け取ることができるデバイスに送信されないメディアコンテンツを引き起こす可能性があるデバイスによって受信されることがあります。間違った「コーデック」パラメータは、サービス拒否攻撃のいくつかのタイプのため、可能です。輸送中のメディアデータを変えることができる攻撃者は、むしろコンテンツの単に「コーデック」パラメータよりも、メディアフォーマットそのもの、あるいはコンテンツタイプヘッダを変更することにより、より多くの害を引き起こす可能性があるのでしかし、これは、事故によって生じた可能性が最も高いですタイプ・ヘッダ。
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.
受信機は、フェッチし、必要なコーデックをインストールすることで、サポートされていないコーデックを示し、「コーデック」パラメータに反応する程度まで、そのような反応は、システムの通常の有効性およびセキュリティチェックおよび手順を慎重に従う行う必要があります。
1. Improved the introduction and other supporting and explanatory text;
1.導入およびその他のサポートや説明文を改善しました。
3. clarified the MIME types to which the parameters apply, and clarified the consequent IANA actions;
3.パラメータが適用されるMIMEタイプを明らかにし、その結果としてIANAのアクションを明らかに。
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.ダウンロードの可能なトリガするためのセキュリティの考慮事項を追加しました。
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は非常に高く評価され、ヘルプの多くを、提供します。メアリー・バーンズとブルース・リリーは詳細かつ有益なコメントを提供しました。サム・ハートマン、ラスHousley、およびバートWijnenによるレビューやコメントは大歓迎されました。クリス・ニューマンは、慎重に検討し、BNFを改善しました。
Christian Timmerer helped with the MPEG-21 material, and Thomas Schierl and Yago Sanchez helped with SVC and MVC.
クリスチャンTimmererは、MPEG-21材料を手伝ってくれました、そしてトーマスSchierlとYAGOサンチェスは、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-フォーマット]第3世代パートナーシッププロジェクト、「技術仕様グループサービスおよびシステムアスペクト;透明なエンド・ツー・エンドのパケットがストリーミングサービス（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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年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]カスターニョ、R.とD.シンガー、RFC 3839、2004年7月、 "第3世代パートナーシッププロジェクト（3GPP）のマルチメディアファイルのMIMEタイプの登録"。
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs Parameter for "Bucket" Media Types", RFC 4281, November 2005.
[RFC4281] Gellens、R.、歌手、D.、およびP. Frojdh、バケット "メディアの種類 " RFC 4281、2005年11月" のためのザ・コーデックパラメータ"。
[RFC4337] Y Lim and D. Singer, "MIME Type Registration for MPEG-4", RFC 4337, March 2006.
[RFC4337] Y・リムとD.歌手、 "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_html/specs/ C.S0050-0_v1.0_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]シモンセン、K.、 "文字ニーモニックと文字セット"、RFC 1345、1992年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 3625、2003年9月。
Authors' Addresses
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 US
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121米国
EMail: rg+ietf@qualcomm.com
メールアドレス：rg+ietf@qualcomm.com
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 US
デビッド・シンガーアップル社1無限ループクパチーノ、CA 95014米国
Phone: +1 408 996 1010 EMail: singer@apple.com
電話：+1 408 996 1010 Eメール：singer@apple.com
Per Frojdh Ericsson AB Ericsson Research Stockholm SE-164 80 Sweden
パーFrojdhエリクソンABエリクソンリサーチストックホルムSE-164 80スウェーデン
Phone: +46 10 7190000 EMail: Per.Frojdh@ericsson.com
電話：+46 10 7190000 Eメール：Per.Frojdh@ericsson.com