[要約] RFC 6381は、メディアタイプの「Codecs」と「Profiles」パラメータに関する仕様であり、メディアバケットのコーデックとプロファイルを指定するための方法を提供します。目的は、メディアの互換性と相互運用性を向上させることです。
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.
このドキュメントは、さまざまなMIMEタイプまたはタイプ/サブタイプの組み合わせで使用される「コーデック」と「プロファイル」の2つのパラメーターを指定して、内部に含まれるメディア形式またはプロファイルが採用しているコーデックの明確な仕様を可能にします。全体的なコンテナ形式。このドキュメントは、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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の元の動機の1つは、メッセージパーツの特定のメディアタイプを識別する機能です。ただし、さまざまな要因により、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-Formats]で指定されています。
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].
o Audio/3GPPには、[3GPP-Formats]で指定されているように、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 Audio/3GPP2には、AMR、AAC、13K（[RFC3625]による）、強化された可変レートコーデック（EVRC）、選択可能なモードボコーダー（SMV）、または可変マルチレートワイドバンド（VMR-WB）を含むことができます。フォーマット]。
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-Formats]。
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-を含めることができます。[3GPP2-Formats]で指定されているWB。
o audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 or registered at the MP4 registration authority [MP4RA].
o Audio/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にはAudio/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-Generic。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] .
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、「要件レベルを示すために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ファミリーファイル」と呼ばれるISOベースメディアファイル形式[ISO14496-12]に基づくファミリのファイル。
2. The QuickTime file format, owned by Apple, Inc.
2. Apple、Inc。が所有するQuickTimeファイル形式
This includes the media types:
これにはメディアタイプが含まれます。
1. audio/3gpp, video/3gpp [RFC3839]
1. Audio/3GPP、ビデオ/3GPP [RFC3839]
2. audio/3gpp2, video/3gpp2 [RFC4393]
2. Audio/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.
Type 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つの単一の引用（ "'"）文字（文字セットも言語も指定されていないことを示します）、およびエンコードを必要とする各オクテットは、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
[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].
実装は、「後の」を除くトークン間にコメントや折りたたみホワイトスペース（CFW）を追加してはなりません。トークンは[rfc2045]で定義されており、<ext-octet>および<属性-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>
; 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)
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ムービーファイル形式の場合、「コーデック」パラメーター値の最初の要素は、MP4登録機関[MP4RA]によって登録されているサンプル説明エントリ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ベースメディアファイル形式のすべてではありませんが、トラックのサンプルエントリの数が1つに制限されます）。
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バイナリ形式などのシステムストリーム（BIF））、2番目の要素は、[MP4RA]および[MP41]（修正を含む）で指定されている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つは40です（MPEG-4オーディオを識別）。この値については、3番目の要素は、[MP4A]（修正を含む）で定義されているAudio ObjectTypeindication（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値の1つは20です（MPEG-4パート2ビデオを識別）。この値については、3番目の要素は、[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の完全な文字列は「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-Formats]で定義されたサンプルエントリの1つ（「AVC1」、「AVC2」、「SVC1」など、 'MVC1'、および 'MVC2'） - AVC（H.264）、スケーラブルビデオコーディング（SVC）、またはマルチビュービデオコーディング（MVC）を示す2番目の要素（フォーマルシントックスの「Avcoti」と呼ばれる）[AVC]で指定された（Subset）シーケンスパラメーターセットネットワーク抽象化レイヤー（NAL）ユニットの（サブセット）シーケンスパラメーターセットネットワーク抽象化レイヤー（NAL）ユニットの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）。また、保存された_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-Formats]、セクション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構成レコードの両方が含まれる場合があります。そのような状況では、2つの構成レコードが異なるAVCプロファイル、レベル、および互換性のインジケーター値を含めることができるため、両方とも報告することをお勧めします。したがって、報告されたコーデックには、サンプル説明コード（「AVC1」など）が2回含まれ、構成レコードの1つからの値がそれぞれに「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
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ファミリファイル形式の場合、新しいドキュメントは追加の詳細を指定することでこれを更新する場合があります。
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)
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"）は、「関連する修正（s）とコリゲンダム（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.
このような追加機能が含まれている場合、コンテンツフィーチュア[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
一部のコーデックにはさまざまなプロファイル（ビットストリームをコーディングできる機能のサブセット）があるように、一部のメディアファイルをプロファイルし、それらが適合するプロファイルの1つ以上のプロファイル識別子に関連付けます。これらのプロファイル
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.
「プロファイル」パラメーターは、全体的なコンテナ形式のプロファイルに関するレポートです。コンテナ形式のプロファイルには、コンテナ形式自体の機能だけでなく、どのコーデックが含まれている可能性があるかについても制限があり、実際にそれらのコーデックのプロファイルに制限がある場合があります。ただし、「プロファイル」パラメーターは、含まれるメディアのプロファイルを直接報告しません。このようなコーデック固有のプロファイルが報告されている場合、このレポートは「コーデック」パラメーターの一部です。「プロファイル」パラメーターは、完全なコンテナに適用されるプロファイルのみを報告します。
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:
これにはメディアタイプが含まれます。
1. audio/3gpp, video/3gpp [RFC3839]
1. Audio/3GPP、ビデオ/3GPP [RFC3839]
2. audio/3gpp2, video/3gpp2 [RFC4393]
2. Audio/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
パラメーター名：プロファイル
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]が使用されます。アスタリスク（ "*"）がパラメーター名の最後（「プロファイル」の代わりに「プロファイル*」になる）に配置されます。パラメーター値は通常、2つの単一の引用（ "'"）文字（文字セットも言語も指定されていないことを示します）、およびエンコードを必要とする各オクテットは、2つの16進数桁と続くパーセント記号（「％」）として表されます。[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.
「プロファイル」パラメーターは、ファイルが適合性を主張する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
MP4登録局[MP4RA]に登録されているブランド、特にISOベースメディアファイル形式ISO/IEC 14496-12 [ISO14496-12]およびQuickTime映画ファイルに基づいたファイルを含むファイル形式については、「プロファイル」パラメーターはリストしなければなりません。Filetypeボックス（ '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).
例は、プロファイル= "MP41、ISOM、QVXT"である可能性があります。これは、MPEG-4バージョン1がメジャーブランドで優先使用であり、ファイルが「ISOM」によって識別されたベースファイル形式のバージョンと互換性があることを示しています。また、仕様/プロファイル「QVXT」（それが何であれ）と互換性があること。
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は、[RFC4281]への参照を「MIMEメディアタイプ」レジストリのこのドキュメントへの参照に置き換えました。これにより、「コーデック」および/または「プロファイル」パラメーターが次のメディアタイプでオプションであることを示しています（セクション3およびセクション3およびセクションにリストされています。4）：
1. audio/3gpp, video/3gpp [RFC3839]
1. Audio/3GPP、ビデオ/3GPP [RFC3839]
2. audio/3gpp2, video/3gpp2 [RFC4393]
2. Audio/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.
「コーデック」パラメーター自体は、使用されているメディアタイプのセキュリティに関する考慮事項を変更しません。各オーディオおよびビデオメディアタイプには、「コーデック」パラメーターの使用に関係なく、適用され続ける独自のセキュリティに関する考慮事項があります。
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. 紹介とその他のサポートおよび説明テキストを改善しました。
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. 「プロファイル」パラメーターを追加しました。
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によるレビューとコメントは大歓迎でした。クリス・ニューマンはBNFを慎重にレビューし、改善しました。
Christian Timmerer helped with the MPEG-21 material, and Thomas Schierl and Yago Sanchez helped with SVC and MVC.
クリスチャン・ティマーはMPEG-21の材料を手伝い、トーマス・シエルとヤゴ・サンチェスは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-Formats]第3世代パートナーシッププロジェクト、「技術仕様グループサービスとシステムの側面、透明なエンドツーエンドパケットスイッチ型ストリーミングサービス（PSS）; 3GPPファイル形式（3GP）（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-Formats] "情報技術 - オーディオ視聴者オブジェクトのコーディング - パート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、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年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 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] Castagno、R。およびD. Singer、「第3世代パートナーシッププロジェクト（3GPP）マルチメディアファイルのMIMEタイプ登録」、RFC 3839、2004年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、「「Bucket」メディアタイプのコーデックパラメーター」、RFC 4281、2005年11月。
[RFC4337] Y Lim and D. Singer, "MIME Type Registration for MPEG-4", RFC 4337, March 2006.
[RFC4337] Y LIMおよび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-Formats]第3世代パートナーシッププロジェクト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：Audio"、ISO/IEC 14496-3：2009。
[MP4V] "Information technology--Coding of audio-visual objects -- Part 2: Visual", ISO/IEC 14496-2:2004.
[MP4V] "情報技術 - オーディオビジュアルオブジェクトのコーディング - パート2：Visual"、ISO/IEC 14496-2：2004。
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, June 1992.
[RFC1345] Simonsen、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
ランドールゲレンズクアルコムIncorporated 5775モアハウスドライブサンディエゴ、カリフォルニア92121米国
EMail: rg+ietf@qualcomm.com
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 US
David Singer Apple、Inc。1 Infinite Loop Cupertino、CA 95014 US
Phone: +1 408 996 1010
EMail: singer@apple.com
Per Frojdh Ericsson AB Ericsson Research Stockholm SE-164 80 Sweden
Frojdh Ericsson Ab Ericsson Research Stockholm SE-164 80スウェーデン
Phone: +46 10 7190000
EMail: Per.Frojdh@ericsson.com