Network Working Group J. van der Meer
Request for Comments: 3640 Philips Electronics
Category: Standards Track D. Mackie
Apple Computer
V. Swaminathan
Sun Microsystems Inc.
D. Singer
Apple Computer
P. Gentric
Philips Electronics
November 2003
RTP Payload Format for Transport of MPEG-4 Elementary Streams
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.
モーションピクチャーエキスパートグループ（MPEG）委員会（ISO / IEC JTC1 / SC29 WG11）は、MPEG-4規格を生成ISOにおけるワーキンググループです。 MPEGは、エレメンタリストリームにオーディオビジュアル情報などのコンテンツを圧縮するためのツールを規定します。この仕様は、任意の非多重MPEG-4エレメンタリストリームの輸送のための単純な、しかし、一般的なRTPペイロードフォーマットを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Carriage of MPEG-4 Elementary Streams Over RTP . . . . . . . . 4
2.1. Signaling by MIME Format Parameters . . . . . . . . . . 4
2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . 5
2.3. Concatenation of Access Units . . . . . . . . . . . . . 5
2.4. Fragmentation of Access Units . . . . . . . . . . . . . 6
2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Time Stamp Information . . . . . . . . . . . . . . . . . 7
2.7. State Indication of MPEG-4 System Streams . . . . . . . 8
2.8. Random Access Indication . . . . . . . . . . . . . . . . 8
2.9. Carriage of Auxiliary Information . . . . . . . . . . . 8
2.10. MIME Format Parameters and Configuring Conditional Field 8
2.11. Global Structure of Payload Format . . . . . . . . . . . 9
2.12. Modes to Transport MPEG-4 Streams . . . . . . . . . . . 9
2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . 10
3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Usage of RTP Header Fields and RTCP . . . . . . . . . . 10
3.2. RTP Payload Structure . . . . . . . . . . . . . . . . . 11
3.2.1. The AU Header Section . . . . . . . . . . . . . 11
3.2.1.1. The AU-header . . . . . . . . . . . . 12
3.2.2. The Auxiliary Section . . . . . . . . . . . . . 14
3.2.3. The Access Unit Data Section . . . . . . . . . . 15
3.2.3.1. Fragmentation. . . . . . . . . . . . . 16
3.2.3.2. Interleaving . . . . . . . . . . . . . 16
3.2.3.3. Constraints for Interleaving . . . . . 17
3.2.3.4. Crucial and Non-Crucial AUs with
MPEG-4 System Data . . . . . . . . . . 20
3.3. Usage of this Specification. . . . . . . . . . . . . . . 21
3.3.1. General. . . . . . . . . . . . . . . . . . . . . 21
3.3.2. The Generic Mode . . . . . . . . . . . . . . . . 22
3.3.3. Constant Bit Rate CELP . . . . . . . . . . . . . 22
3.3.4. Variable Bit Rate CELP . . . . . . . . . . . . . 23
3.3.5. Low Bit Rate AAC . . . . . . . . . . . . . . . . 24
3.3.6. High Bit Rate AAC. . . . . . . . . . . . . . . . 25
3.3.7. Additional Modes . . . . . . . . . . . . . . . . 26
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27
4.1. MIME Type Registration . . . . . . . . . . . . . . . . . 27
4.2. Registration of Mode Definitions with IANA . . . . . . . 33
4.3. Concatenation of Parameters. . . . . . . . . . . . . . . 33
4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1. The a=fmtp Keyword . . . . . . . . . . . . . . . 34
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 34
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
APPENDIX: Usage of this Payload Format. . . . . . . . . . . . . . 36
Appendix A. Interleave Analysis . . . . . . . . . . . . . . . . . 36
A. Examples of Delay Analysis with Interleave. . . . . . . . . . 36
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36
A.2. De-interleaving and Error Concealment . . . . . . . . . 36
A.3. Simple Group Interleave . . . . . . . . . . . . . . . . 36
A.3.1. Introduction . . . . . . . . . . . . . . . . . . 36
A.3.2. Determining the De-interleave Buffer Size . . . 37
A.3.3. Determining the Maximum Displacement . . . . . . 37
A.4. More Subtle Group Interleave . . . . . . . . . . . . . . 38
A.4.1. Introduction . . . . . . . . . . . . . . . . . . 38
A.4.2. Determining the De-interleave Buffer Size. . . . 38
A.4.3. Determining the Maximum Displacement . . . . . . 39
A.5. Continuous Interleave . . . . . . . . . . . . . . . . . 39
A.5.1. Introduction . . . . . . . . . . . . . . . . . . 39
A.5.2. Determining the De-interleave Buffer Size . . . 40
A.5.3. Determining the Maximum Displacement . . . . . . 40
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Normative References . . . . . . . . . . . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 43
The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29 that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4 standards [1]. The MPEG-4 standard specifies compression of audio-visual data into, for example an audio or video elementary stream. In the MPEG-4 standard, these streams take the form of audio-visual objects that may be arranged into an audio-visual scene by means of a scene description. Each MPEG-4 elementary stream consists of a sequence of Access Units; examples of an Access Unit (AU) are an audio frame and a video picture.
MPEG委員会は、最近では、MPEG-1、MPEG-2を指定し、ISO / IEC JTC1 SC29におけるワーキンググループ11（WG11）は、MPEG-4規格[1]。 MPEG-4規格は、例えば、オーディオまたはビデオエレメンタリストリーム、にオーディオビジュアルデータの圧縮を指定します。 MPEG-4規格では、これらのストリームは、シーン記述を用いてオーディオビジュアルシーンに配置することができるオーディオビジュアルオブジェクトの形をとります。各MPEG-4エレメンタリストリームは、アクセス単位の配列からなります。アクセスユニット（AU）の例は、オーディオ・フレームとビデオ画像です。
This specification defines a general and configurable payload structure to transport MPEG-4 elementary streams, in particular MPEG-4 audio (including speech) streams, MPEG-4 video streams and also MPEG-4 systems streams, such as BIFS (BInary Format for Scenes), OCI (Object Content Information), OD (Object Descriptor) and IPMP (Intellectual Property Management and Protection) streams. The RTP payload defined in this document is simple to implement and reasonably efficient. It allows for optional interleaving of Access Units (such as audio frames) to increase error resiliency in packet loss.
この仕様は、MPEG-4エレメンタリストリームを輸送する一般設定ペイロードの構造を定義する、特に（音声を含む）、MPEG-4オーディオは、MPEG-4ビデオストリームをストリーミングし、また、BIFSシーンの（バイナリ形式としてMPEG-4システムストリーム、 ）、OCI（コンテンツ情報をオブジェクト）、OD（オブジェクト記述）とIPMP（知的財産管理および保護）ストリーム。この文書で定義されたRTPペイロードは実装が簡単かつ合理的に効率的です。これは、パケット損失のエラー回復力を増加させる（例えば、オーディオフレームのような）アクセスユニットの任意のインターリービングを可能にします。
Some types of MPEG-4 elementary streams include "crucial" information whose loss cannot be tolerated. However, RTP does not provide reliable transmission, so receipt of that crucial information is not assured. Section 3.2.3.4 specifies how stream state is conveyed so that the receiver can detect the loss of crucial information and cease decoding until the next random access point has been received. Applications transmitting streams that include crucial information, such as OD commands, BIFS commands, or programmatic content such as MPEG-J (Java) and ECMAScript, should include random access points, at a suitable periodicity depending upon the probability of loss, in order to reduce stream corruption to an acceptable level. An example is the carousel mechanism as defined by MPEG in ISO/IEC 14496-1 [1].
MPEG-4エレメンタリストリームの種類によっては、その損失許容できない「重要な」情報を含みます。ただし、RTPは、信頼性の高い伝送を提供していませんので、その重要な情報の受信が保証されません。セクション3.2.3.4は、受信機は、重要な情報の損失を検出し、次のランダムアクセスポイントが受信されるまで復号を停止することができるように、ストリーム状態が搬送される方法を指定します。例えば、このようなMPEG-J（ジャワ）およびECMAScriptのようなODコマンド、BIFSコマンド、またはプログラムコンテンツなどの重要な情報を含むストリームを、送信アプリケーションをするためには、損失の確率に応じて適切な周期で、ランダムアクセスポイントを含むべきです許容可能なレベルにまで、ストリームの破損を減らします。 [1] ISO / IEC 14496-1にMPEGによって定義されるような例では、カルーセル機構です。
Such applications may also employ additional protocols or services to reduce the probability of loss. At the RTP layer, these measures include payload formats and profiles for retransmission or forward error correction (such as in RFC 2733 [10]), that must be employed
このようなアプリケーションは、損失の可能性を減らすために、追加のプロトコルまたはサービスを使用することができます。 RTP層で、これらの対策は、それを使用しなければならない（例えば、[10] RFC 2733のように）再送信又は前方誤り訂正のためのペイロード・フォーマットおよびプロファイルを含みます
with due consideration to congestion control. Another solution that may be appropriate for some applications is to carry RTP over TCP (such as in RFC 2326 [8], section 10.12). At the network layer, resource allocation or preferential service may be available to reduce the probability of loss. For a general description of methods to repair streaming media, see RFC 2354 [9].
輻輳制御に配慮しました。いくつかの用途のために適切であり得る別の解決策は、（RFC 2326 [8]、セクション10.12のように）TCP上のRTPを運ぶことです。ネットワーク層では、リソース割り当てや優先サービスは、損失の確率を低減するために利用可能であってもよいです。ストリーミングメディアを修復する方法の一般的な説明については、RFC 2354 [9]を参照してください。
Though the RTP payload format defined in this document is capable of transporting any MPEG-4 stream, other, more specific, formats may exist, such as RFC 3016 [12] for transport of MPEG-4 video (ISO/IEC 14496 [1] part 2).
この文書で定義されたRTPペイロードフォーマットは、任意のMPEG-4ストリームを搬送することが可能であるが、他の、より具体的なフォーマットはMPEG-4ビデオ（ISO / IEC 14496の輸送のためにそのようなRFC 3016のように、[12]が存在することができる[1]パート2）。
Configuration of the payload is provided to accommodate the transportation of any MPEG-4 stream at any possible bit rate. However, for a specific MPEG-4 elementary stream typically only very few configurations are needed. So as to allow for the design of simplified, but dedicated receivers, this specification requires that specific modes be defined for transport of MPEG-4 streams. This document defines modes for MPEG-4 CELP and AAC streams, as well as a generic mode that can be used to transport any MPEG-4 stream. In the future, new RFCs are expected to specify additional modes for the transportation of MPEG-4 streams.
ペイロードの構成は、任意の可能なビットレートで、任意のMPEG-4ストリームの輸送を収容するために設けられています。しかし、特定のMPEG-4エレメンタリ・ストリームのために一般的にごく少数の構成が必要とされています。簡略化したが、専用の受信機の設計を可能にするように、本明細書は、特定のモードがMPEG-4ストリームのトランスポートのために定義されることを必要とします。この文書では、MPEG-4 CELP及びAACストリームのモード、ならびに任意のMPEG-4ストリームを輸送するために使用することができる一般的なモードを定義します。将来的には、新しいのRFCは、MPEG-4ストリームの輸送のための追加のモードを指定することが期待されます。
The RTP payload format defined in this document specifies carriage of system-related information that is often equivalent to the information that may be contained in the MPEG-4 Sync Layer (SL) as defined in MPEG-4 Systems [1]. This document does not prescribe how to transcode or map information from the SL to fields defined in the RTP payload format. Such processing, if any, is left to the discretion of the application. However, to anticipate the need for the transportation of any additional system-related information in the future, an auxiliary field can be configured that may carry any such data.
MPEG-4システム[1]で定義されるように本書で定義されたRTPペイロードフォーマットは、多くの場合、MPEG-4の同期層（SL）に含まれてもよい情報と等価であるシステム関連情報のキャリッジを指定します。この文書では、トランスコードまたはRTPペイロード形式で定義されたフィールドにSLからの情報をマッピングする方法を規定していません。このような処理は、もしあれば、アプリケーションの裁量に委ねられます。しかし、将来の任意の追加のシステム関連情報の輸送のための必要性を予測するために、補助フィールドは、そのようなデータを搬送することができるそのように構成することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[4]。
With this payload format, a single MPEG-4 elementary stream can be transported. Information on the type of MPEG-4 stream carried in the payload is conveyed by MIME format parameters, as in an SDP [5] message or by other means (see section 4). These MIME format parameters specify the configuration of the payload. To allow for simplified and dedicated receivers, a MIME format parameter is available to signal a specific mode of using this payload. A mode definition MAY include the type of MPEG-4 elementary stream, as well as the applied configuration, so as to avoid the need for receivers to parse all MIME format parameters. The applied mode MUST be signaled.
このペイロード形式で、単一のMPEG-4エレメンタリストリームを搬送することができます。ペイロードで運ばれたMPEG-4ストリームのタイプに関する情報は、SDP [5]メッセージのように、または他の手段（セクション4を参照）によって、MIME形式のパラメータによって搬送されます。これらのMIME形式のパラメータは、ペイロードの構成を指定します。簡略化及び専用受信を可能にするために、MIME形式のパラメータは、このペイロードを使用して特定のモードをシグナリングするために利用可能です。受信機は、すべてのMIME形式のパラメータを解析するための必要性を回避するように、モード定義は、MPEG-4エレメンタリストリームの種類、ならびに適用される構成を含んでいてもよいです。適用モードは合図しなければなりません。
For carriage of compressed audio-visual data, MPEG defines Access Units. An MPEG Access Unit (AU) is the smallest data entity to which timing information is attributed. In the case of audio, an Access Unit may represent an audio frame and in the case of video, a picture. MPEG Access Units are octet-aligned by definition. If, for example, an audio frame is not octet-aligned, up to 7 zero-padding bits MUST be inserted at the end of the frame to achieve the octet-aligned Access Units, as required by the MPEG-4 specification. MPEG-4 decoders MUST be able to decode AUs in which such padding is applied.
圧縮されたオーディオビジュアルデータのキャリッジのために、MPEGは、アクセス単位を定義します。 MPEGアクセスユニット（AU）は、タイミング情報帰属された最小のデータエンティティです。オーディオの場合には、アクセスユニットは、オーディオフレームとビデオの場合には、画像を表すことができます。 MPEGアクセス単位はオクテット整列定義です。例えば、オーディオフレームをオクテット整列されていない、場合MPEG-4仕様によって要求されるように、7ゼロパディングビットまでの、オクテット整列アクセス単位を達成するために、フレームの端部に挿入されなければなりません。 MPEG-4デコーダは、パディングが適用されるAUを復号化できなければなりません。
Consistent with the MPEG-4 specification, this document requires that each MPEG-4 part 2 video Access Unit include all the coded data of a picture, any video stream headers that may precede the coded picture data, and any video stream stuffing that may follow it, up to but not including the startcode indicating the start of a new video stream or the next Access Unit.
MPEG-4仕様と一致して、この文書は、各MPEG-4パート2ビデオアクセスユニットは、すべての画像の符号化データ、符号化された画像データに先行することができる任意のビデオストリームのヘッダ、および続くことができる任意のビデオストリームスタッフィングを含むことが必要それは、新しいビデオストリームまたは次のアクセスユニットの開始を示すSTARTCODE含めまでではありません。
Frequently it is possible to carry multiple Access Units in one RTP packet. This is particularly useful for audio; for example, when AAC is used for encoding a stereo signal at 64 kbits/sec, AAC frames contain on average, approximately 200 octets. On a LAN with a 1500 octet MTU, this would allow an average of 7 complete AAC frames to be carried per RTP packet.
しばしば、1つのRTPパケットに複数のアクセス単位を実行することが可能です。これは、オーディオのために特に有用です。 AACは、64人のキロビット/秒でステレオ信号を符号化するために使用される場合、例えば、AACフレームは、平均して約200オクテットを含みます。 1500オクテットMTUとLANで、これは、7つの完全なAACフレームの平均は、RTPパケットごとに実施することが可能となります。
Access Units may have a fixed size in octets, but a variable size is also possible. To facilitate parsing in the case of multiple concatenated AUs in one RTP packet, the size of each AU is made known to the receiver. When concatenating in the case of a constant AU size, this size is communicated "out of band" through a MIME format parameter. When concatenating in case of variable size AUs, the RTP payload carries "in band" an AU size field for each contained AU.
アクセス単位はオクテットで固定サイズを持っているかもしれないが、可変サイズも可能です。 1つのRTPパケットに複数の連結AUの場合には解析を容易にするために、各AUのサイズは、受信機に知らされます。一定のAUサイズの場合に連結する場合、このサイズは、MIME形式のパラメータを介して「帯域外」通信されます。可変サイズのAUの場合に連結する場合、RTPペイロードは、「帯域内」それぞれについて、AUサイズフィールドは、Auを含有運びます。
In combination with the RTP payload length, the size information allows the RTP payload to be split by the receiver back into the individual AUs.
RTPペイロード長との組み合わせで、サイズ情報は、RTPペイロードがバック個々のAUに受信機によって分割されることを可能にします。
To simplify the implementation of RTP receivers, it is required that when multiple AUs are carried in an RTP packet, each AU MUST be complete, i.e., the number of AUs in an RTP packet MUST be integral.
RTP受信機の実装を簡単にするために、それは複数のAUは、RTPパケットで運ばれる場合、各AUが完了していなければならないことが要求され、即ち、RTPパケット内のAUの数は一体でなければなりません。
In addition, an AU MUST NOT be repeated in other RTP packets; hence repetition of an AU is only possible when using a duplicate RTP packet.
また、AUは他のRTPパケットで繰り返されてはなりません。重複したRTPパケットを使用している場合ので、AUの繰り返しにのみ可能です。
MPEG allows for very large Access Units. Since most IP networks have significantly smaller MTU sizes, this payload format allows for the fragmentation of an Access Unit over multiple RTP packets. Hence, when an IP packet is lost after IP-level fragmentation, only an AU fragment may get lost instead of the entire AU. To simplify the implementation of RTP receivers, an RTP packet SHALL either carry one or more complete Access Units or a single fragment of one AU, i.e., packets MUST NOT contain fragments of multiple Access Units.
MPEGは、非常に大規模なアクセス単位が可能になります。ほとんどのIPネットワークはかなり小さいMTUサイズを持っているので、このペイロード形式は、複数のRTPパケットを超えるアクセスユニットの断片化が可能になります。 IPパケットはIPレベルの断片化後に失われた場合従って、唯一AU断片ではなく全体のAu迷子できます。 RTP受信機の実装を簡素化するために、RTPパケットは、1つまたは複数の完全なアクセス単位または1 AUの単一のフラグメントを運ぶものとのいずれか、すなわち、パケットが複数のアクセス単位の断片を含んではなりません。
When an RTP packet carries a contiguous sequence of Access Units, the loss of such a packet can result in a "decoding gap" for the user. One method of alleviating this problem is to allow for the Access Units to be interleaved in the RTP packets. For a modest cost in latency and implementation complexity, significant error resiliency to packet loss can be achieved.
RTPパケットはアクセスユニットの連続配列を有する場合、そのようなパケットの損失は、ユーザのための「復号ギャップ」をもたらすことができます。この問題を緩和する一つの方法は、RTPパケットでインターリーブされるアクセスユニットを可能にすることです。レイテンシと実装の複雑さの適度なコストのために、パケット損失に重大なエラー耐性を実現することができます。
To support optional interleaving of Access Units, this payload format allows for index information to be sent for each Access Unit. After informing receivers about buffer resources to allocate for de-interleaving, the RTP sender is free to choose the interleaving pattern without propagating this information a priori to the receiver(s). Indeed, the sender could dynamically adjust the interleaving pattern based on the Access Unit size, error rates, etc. The RTP receiver does not need to know the interleaving pattern used; it only needs to extract the index information of the Access Unit and insert the Access Unit into the appropriate sequence in the decoding or rendering queue. An example of interleaving is given below.
インデックス情報は、各アクセスユニットのために送信するためのアクセスユニットの任意のインターリービングをサポートするために、このペイロードフォーマットが可能になります。デインターリーブに割り当てるためのバッファリソースに関する受信機に通知した後に、RTP送信機は、受信機（単数または複数）にこの情報を事前に伝播することなく、インターリーブパターンを選択することが自由です。確かに、送信者は動的にRTP受信機が使用インターリーブパターンを知る必要はありませんアクセスユニットのサイズ、エラー率などに基づいてインターリーブパターンを調整することができます。それだけのアクセスユニットのインデックス情報を抽出し、デコードやレンダリングキューに適切なシーケンスにアクセスユニットを挿入する必要があります。インターリービングの例を以下に示します。
For example, if we assume that an RTP packet contains 3 AUs, and that the AUs are numbered 0, 1, 2, 3, 4, and so forth, and if an interleaving group length of 9 is chosen, then RTP packet(i) contains the following AU(n):
例えば、我々は、RTPパケットが3つのAUを含んでいると仮定すると、とのAUは、0、1、2、3、4と番号付けされ、等、及び9のインタリーブグループ長が選択される場合、RTPパケットは、（I ）は、次のAU（n）は含まれています：
RTP packet(0): AU(0), AU(3), AU(6) RTP packet(1): AU(1), AU(4), AU(7) RTP packet(2): AU(2), AU(5), AU(8) RTP packet(3): AU(9), AU(12), AU(15) RTP packet(4): AU(10), AU(13), AU(16) Etc.
RTPパケット（0）（0）〜（3）〜（6）のRTPパケット（1）：（1）では、AT（4）、AU（7）RTPパケット（2）：（2）〜 AU（9）、（12）乃至（15）のRTPパケット（4）：IN（10）に（13）、（16）、IN（5）（8）RTPパケット（3）で等
The RTP time stamp MUST carry the sampling instant of the first AU (fragment) in the RTP packet. When multiple AUs are carried within an RTP packet, the time stamps of subsequent AUs can be calculated if the frame period of each AU is known. For audio and video, this is possible if the frame rate is constant. However, in some cases it is not possible to make such a calculation (for example, for variable frame rate video, or for MPEG-4 BIFS streams carrying composition information). To support such cases, this payload format can be configured to carry a time stamp in the RTP payload for each contained Access Unit. A time stamp MAY be conveyed in the RTP payload only for non-first AUs in the RTP packet, and SHALL NOT be conveyed for the first AU (fragment), as the time stamp for the first AU in the RTP packet is carried by the RTP time stamp.
RTPタイムスタンプは、RTPパケットの最初のAU（フラグメント）のサンプリングの瞬間を運ばなければなりません。複数のAUは、RTPパケット内で運ばれる場合、各AUのフレーム期間が既知である場合、後続のAUのタイムスタンプを計算することができます。オーディオとビデオの場合、これはフレームレートが一定であれば可能です。しかし、場合によっては、（例えば、可変フレームレートビデオのため、または組成情報を運ぶMPEG-4 BIFSストリームのための）このような計算を行うことは不可能です。このような場合をサポートするために、このペイロードフォーマットは、それぞれに含まれるアクセスユニットのためのRTPペイロードにタイムスタンプを運ぶように構成することができます。タイムスタンプは、RTPパケットにおける非最初のAUのためのRTPペイロードで搬送されてもよく、によって運ばれるRTPパケット内の最初のAUのタイムスタンプとして、最初のAU（フラグメント）のために搬送することがないものRTPタイムスタンプ。
MPEG-4 defines two types of time stamps: the composition time stamp (CTS) and the decoding time stamp (DTS). The CTS represents the sampling instant of an AU, and hence the CTS is equivalent to the RTP time stamp. The DTS may be used in MPEG-4 video streams that use bi-directional coding, i.e., when pictures are predicted in both forward and backward direction by using either a reference picture in the past, or a reference picture in the future. The DTS cannot be carried in the RTP header. In some cases, the DTS can be derived from the RTP time stamp using frame rate information; this requires deep parsing in the video stream, which may be considered objectionable. If the video frame rate is variable, the required information may not even be present in the video stream. For both reasons, the capability has been defined to optionally carry the DTS in the RTP payload for each contained Access Unit.
組成タイムスタンプ（CTS）と復号タイムスタンプ（DTS）：MPEG-4は、タイムスタンプの二つのタイプを定義します。 CTSは、AUのサンプリングの瞬間を表し、従ってCTSはRTPタイムスタンプに相当します。 DTSは、双方向符号化を使用してMPEG-4ビデオストリームに使用することができる、すなわち、ピクチャは過去の参照ピクチャ、又は将来の参照ピクチャのいずれかを使用して、両方の前後方向に予測される場合。 DTSは、RTPヘッダで搬送することができません。いくつかのケースでは、DTSは、フレームレート情報を使用して、RTPタイムスタンプから導出することができます。これは不快と考えることができるビデオ・ストリームの深い解析を必要とします。ビデオフレームレートが可変である場合、必要な情報があっても、ビデオストリーム中に存在しないかもしれません。両方の理由から、能力がそれぞれ含まれるアクセスユニットのためのRTPペイロードにDTSを運ぶ任意に定義されています。
To keep the coding of time stamps efficient, each time stamp contained in the RTP payload is coded as a difference. For the CTS, the offset from the RTP time stamps is provided, and for the DTS, the offset from the CTS.
効率的なタイムスタンプの符号化を維持するために、RTPペイロードに含まれる各タイムスタンプは、差分として符号化されます。 CTSは、RTPタイムスタンプからオフセット設けられており、DTSのために、CTSからのオフセット。
ISO/IEC 14496-1 defines states for MPEG-4 system streams. So as to convey state information when transporting MPEG-4 system streams, this payload format allows for the optional carriage in the RTP payload of the stream state for each contained Access Unit. Stream states are used to signal "crucial" AUs that carry information whose loss cannot be tolerated and are also useful when repeating AUs according to the carousel mechanism defined in ISO/IEC 14496-1.
ISO / IEC 14496-1は、MPEG-4システムストリームのための状態を定義します。だから、MPEG-4システムストリームを搬送するときの状態情報を伝達するように、このペイロードフォーマットは、それぞれ含まれるアクセスユニットのストリーム状態のRTPペイロード内の任意のキャリッジを可能にします。ストリーム状態が損失許容できない情報を携帯し、ISO / IEC 14496-1で定義されたカルーセルメカニズムに従ってAUを繰り返す際にも有用である「重要」AUを知らせるために使用されます。
Random access to the content of MPEG-4 elementary streams may be possible at some but not all Access Units. To signal Access Units where random access is possible, a random access point flag can optionally be carried in the RTP payload for each contained Access Unit. Carriage of random access points is particularly useful for MPEG-4 system streams in combination with the stream state.
MPEG-4エレメンタリ・ストリームの内容へのランダムアクセスは、いくつかのすべてではないアクセス単位で可能かもしれません。ランダムアクセスが可能なアクセス単位を通知するために、ランダムアクセスポイントフラグは、必要に応じて、それぞれに含まれるアクセスユニットのためのRTPペイロードに行うことができます。ランダムアクセスポイントのキャリッジは、ストリームの状態と組み合わせたMPEG-4システムストリームのために特に有用です。
This payload format defines a specific field to carry auxiliary data. The auxiliary data field is preceded by a field that specifies the length of the auxiliary data, so as to facilitate the skipping of data without parsing it. The coding of the auxiliary data is not defined in this document; instead, the format, meaning and signaling of auxiliary information is expected to be specified in one or more future RFCs. Auxiliary information MUST NOT be transmitted until its format, meaning and signaling have been specified and its use has been signaled. Receivers that have knowledge of the auxiliary data MAY decode the auxiliary data, but receivers without knowledge of such data MUST skip the auxiliary data field.
このペイロード形式は、補助データを搬送するために特定のフィールドを定義します。補助データ・フィールドは、それを解析することなく、データのスキップを容易にするように、補助データの長さを指定するフィールドが先行します。補助データの符号化は、この文書で定義されていません。代わりに、補助情報の形式、意味およびシグナリングは一つ以上の将来のRFCsで指定されることが期待されます。その形式、意味やシグナリングが指定されていると、その使用が合図されるまで補助情報を送信してはなりません。補助データの知識を持っている受信機は、補助データを復号することができるが、そのようなデータの知識のない受信機は、補助データフィールドをスキップしなければなりません。
To support the features described in the previous sections, several fields are defined for carriage in the RTP payload. However, their use strongly depends on the type of MPEG-4 elementary stream that is carried. Sometimes a specific field is needed with a certain length, while in other cases such a field is not needed. To be efficient in either case, the fields to support these features are configurable by means of MIME format parameters. In general, a MIME format parameter defines the presence and length of the associated field. A length of zero indicates absence of the field. As a consequence, parsing of the payload requires knowledge of MIME format parameters. The MIME format parameters are conveyed to the receiver via SDP [5] messages, as specified in section 4.4.1, or through other means.
前のセクションで説明する機能をサポートするために、いくつかのフィールドは、RTPペイロード内のキャリッジのために定義されています。しかし、それらの使用は強く運ばれるMPEG-4エレメンタリストリームの種類によって異なります。他のケースでは、そのようなフィールドが必要とされていない間、時々、特定のフィールドは、一定の長さで必要とされています。いずれの場合にも有効であることが、これらの機能をサポートするフィールドは、MIME形式のパラメータによって構成されています。一般に、MIME形式のパラメータは、対応するフィールドの存在と長さを定義します。ゼロの長さフィールドが存在しないことを示しています。その結果、ペイロードの解析は、MIME形式のパラメータの知識を必要とします。 MIME形式のパラメータは、[5]メッセージ、セクション4.4.1で指定されるように、または他の手段を介してSDPを介して受信機に搬送されます。
The RTP payload following the RTP header, contains three octet-aligned data sections, of which the first two MAY be empty, see Figure 1.
RTPヘッダに続くRTPペイロードは、最初の二つは、図1を参照して、空にすることができる3つのオクテット整列データセクションを含んでいます。
+---------+-----------+-----------+---------------+
| RTP | AU Header | Auxiliary | Access Unit |
| Header | Section | Section | Data Section |
+---------+-----------+-----------+---------------+
<----------RTP Packet Payload----------->
Figure 1: Data sections within an RTP packet
図1：RTPパケット内のデータセクション
The first data section is the AU (Access Unit) Header Section, that contains one or more AU-headers; however, each AU-header MAY be empty, in which case the entire AU Header Section is empty. The second section is the Auxiliary Section, containing auxiliary data; this section MAY also be configured empty. The third section is the Access Unit Data Section, containing either a single fragment of one Access Unit or one or more complete Access Units. The Access Unit Data Section MUST NOT be empty.
最初のデータ・セクションは、一つ以上のAU-ヘッダが含まAU（アクセスユニット）ヘッダセクション、です。しかし、各AU-ヘッダ全体AUヘッダセクションが空である場合には、空であってもよいです。第2のセクションは、補助データを含む、補助部です。このセクションでは、空構成されるかもしれません。第3のセクションは、1つのアクセスユニットまたは1つ以上の完全なアクセスユニットの単一断片のいずれかを含む、アクセスユニットデータセクションです。アクセスユニットデータセクションは空にすることはできません。
While it is possible to build fully configurable receivers capable of receiving any MPEG-4 stream, this specification also allows for the design of simplified, but dedicated receivers, that are for example, capable of receiving only one type of MPEG-4 stream. This is achieved by requiring that specific modes be defined in order to use this specification. Each mode may define constraints for transport of one or more types of MPEG-4 streams, for instance on the payload configuration.
それは、任意のMPEG-4ストリームを受信することができる完全に設定可能受信機を構築することが可能であるが、本明細書はまた、簡略化の設計を可能にするが、MPEG-4ストリームの一種類のみを受信することができる、例えばある専用の受信機。これは、特定のモードがこの仕様を使用するために定義されることを要求することによって達成されます。各モードは、ペイロードの構成に、例えば、MPEG-4ストリームの1つまたは複数のタイプの輸送のための制約を定義することができます。
The applied mode MUST be signaled. Signaling the mode is particularly important for receivers that are only capable of decoding one or more specific modes. Such receivers need to determine whether the applied mode is supported, so as to avoid problems with processing of payloads that are beyond the capabilities of the receiver.
適用モードは合図しなければなりません。モードシグナリングは、1つの以上の特定のモードを復号化することができるだけである受信機のために特に重要です。そのような受信機は、受信機の能力を超えているペイロードの処理の問題を回避するために、適用モードがサポートされているかどうかを決定する必要があります。
In this document several modes are defined for the transportation of MPEG-4 CELP and AAC streams, as well as a generic mode that can be used for any MPEG-4 stream. In the future, new RFCs may specify other modes of using this specification. However, each mode MUST be in full compliance with this specification (see section 3.3.7).
本書では、いくつかのモードは、MPEG-4 CELP及びAACストリームの輸送、ならびに任意のMPEG-4ストリームのために使用することができる一般的なモードのために定義されています。将来的には、新しいRFCがこの仕様を使用して他のモードを指定することもできます。しかし、各モードは、本明細書に完全に準拠する必要があります（セクション3.3.7を参照）。
This payload can be configured as nearly identical to the payload format defined in RFC 3016 [12] for the MPEG-4 video configurations recommended in RFC 3016. Hence, receivers that comply with RFC 3016 can decode such RTP payload, provided that additional packets containing video decoder configuration (VO, VOL, VOSH) are inserted in the stream, as required by RFC 3016 [12]. Conversely, receivers that comply with the specification in this document SHOULD be able to decode payloads, names and parameters defined for MPEG-4 video in RFC 3016 [12]. In this respect, it is strongly RECOMMENDED that the implementation provide the ability to ignore "in band" video decoder configuration packets that may be found in streams conforming to the RFC 3016 video payload.
このペイロードは、したがってRFC 3016で推奨MPEG-4ビデオの構成については、RFC 3016に準拠する受信機は、RTPペイロードを復号することができる[12] RFC 3016で定義されたペイロードフォーマットへとほぼ同じように構成することができる、追加のパケットを含むことを条件としますRFC 3016 [12]によって必要とされるビデオデコーダの構成（VO、VOL、VOSH）は、ストリーム内に挿入されています。逆に、この文書に記載されている仕様に準拠する受信機は、RFC 3016 [12]でMPEG-4ビデオ用に定義されたペイロード、名前とパラメータを復号化することができるべきです。この点において、強く実装は、「帯域内」RFC 3016、ビデオペイロードに準拠ストリームに見出すことができるビデオデコーダ構成パケットを無視する能力を提供することが推奨されます。
Note the "out of band" availability of the video decoder configuration is optional in RFC 3016 [12]. To achieve maximum interoperability with the RTP payload format defined in this document, applications that use RFC 3016 to transport MPEG-4 video (part 2) are recommended to make the video decoder configuration available as a MIME parameter.
ビデオデコーダの構成の「帯域外」可用性はRFC 3016に任意であることに注意してください[12]。この文書で定義されたRTPペイロードフォーマットと最大の相互運用性を達成するために、MPEG-4ビデオ（その2）を輸送するためにRFC 3016を使用するアプリケーションは、MIMEパラメータとしてビデオデコーダの構成が利用できるようにすることが推奨されます。
Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using SDP).
ペイロードタイプ（PT）：このパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。なお、このペイロードフォーマットが使用される、またはアウトオブバンド（例えば、SDPを使用して）動的に通知され、その下RTPプロファイルで指定されています。
Marker (M) bit: The M bit is set to 1 to indicate that the RTP packet payload contains either the final fragment of a fragmented Access Unit or one or more complete Access Units.
マーカ（M）ビット：Mビットは、RTPパケットペイロードがフラグメント化アクセスユニットまたは1つ以上の完全なアクセスユニットの最後の断片のいずれかを含むことを示すために1に設定されています。
Extension (X) bit: Defined by the RTP profile used.
拡張（X）ビット：使用RTPプロファイルによって定義されています。
Sequence Number: The RTP sequence number SHOULD be generated by the sender in the usual manner with a constant random offset.
シーケンス番号：RTPシーケンス番号は一定のオフセットランダムに通常の方法で送信者によって生成されるべきです。
Timestamp: Indicates the sampling instant of the first AU contained in the RTP payload. This sampling instant is equivalent to the CTS in the MPEG-4 time domain. When using SDP, the clock rate of the RTP time stamp MUST be expressed using the "rtpmap" attribute. If an MPEG-4 audio stream is transported, the rate SHOULD be set to the same value as the sampling rate of the audio stream. If an MPEG-4 video stream is transported, it is RECOMMENDED that the rate be set to 90 kHz.
タイムスタンプ：RTPペイロードに含まれる最初のAUのサンプリングの瞬間を示します。このサンプリング時点は、MPEG-4、時間領域におけるCTSと同等です。 SDPを使用する場合は、RTPタイムスタンプのクロックレートは、「rtpmap」属性を使用して表現されなければなりません。 MPEG-4オーディオストリームが搬送される場合、レートは、オーディオストリームのサンプリングレートと同じ値に設定する必要があります。 MPEG-4ビデオストリームが搬送される場合には、速度は90 kHzに設定することをお勧めします。
In all cases, the sender SHALL make sure that RTP time stamps are identical only if the RTP time stamp refers to fragments of the same Access Unit.
すべての場合において、送信者は、RTPタイムスタンプは、同じアクセスユニットの断片を指す場合にのみ、RTPタイムスタンプが同一であることを確認しなければなりません。
According to RFC 3550 [2] (section 5.1), it is RECOMMENDED that RTP time stamps start at a random value for security reasons. This is not an issue for synchronization of multiple RTP streams. However, when streams from multiple sources are to be synchronized (for example one stream from local storage, another from an RTP streaming server), synchronization may become impossible if the receiver only knows the original time stamp relationships. In such cases the time stamp relationship required for obtaining synchronization may be provided by out of band means. The format of such information, as well as methods to convey such information, are beyond the scope of this specification.
RFC 3550 [2]（セクション5.1）によれば、RTPタイムスタンプは、セキュリティ上の理由からランダムな値で開始することが推奨されます。これは、複数のRTPストリームの同期のための問題ではありません。複数のソースからのストリーム（ローカルストレージから例えば一つのストリーム、RTPストリーミングサーバから別の）同期する場合、受信機が唯一のオリジナルのタイムスタンプとの関係を知っている場合は、同期が不可能になることができます。このような場合に同期を得るために必要なタイムスタンプの関係は、バンド手段のうちによって提供されてもよいです。そのような情報のフォーマット、ならびにそのような情報を伝達する方法が、本明細書の範囲外です。
SSRC: set as described in RFC 3550 [2].
SSRC：RFC 3550に記載されるように設定された[2]。
CC and CSRC fields are used as described in RFC 3550 [2].
RFC 3550に記載されるようにCCとCSRCフィールドが使用されている[2]。
RTCP SHOULD be used as defined in RFC 3550 [2]. Note that time stamps in RTCP Sender Reports may be used to synchronize multiple MPEG-4 elementary streams and also to synchronize MPEG-4 streams with non-MPEG-4 streams, in case the delivery of these streams uses RTP.
RFC 3550で定義されるようにRTCPが使用されるべきである[2]。場合にこれらのストリームの配信は、RTPを使用し、RTCPセンダレポートにスタンプは、複数のMPEG-4エレメンタリストリームを同期させるために、また非MPEG-4ストリームとMPEG-4ストリームを同期させるために使用することができるその時に注意してください。
When present, the AU Header Section consists of the AU-headers-length field, followed by a number of AU-headers, see Figure 2.
存在する場合、AUヘッダセクションAU-ヘッダの数、続いてAU-ヘッダ長フィールド、からなり、図2を参照します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+
|AU-headers-length|AU-header|AU-header| |AU-header|padding|
| | (1) | (2) | | (n) | bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+
Figure 2: The AU Header Section
図2：AUヘッダーセクション
The AU-headers are configured using MIME format parameters and MAY be empty. If the AU-header is configured empty, the AU-headers-length field SHALL NOT be present and consequently the AU Header Section is empty. If the AU-header is not configured empty, then the AU-headers-length is a two octet field that specifies the length in bits of the immediately following AU-headers, excluding the padding bits.
AU-ヘッダはMIME形式のパラメータを使用して構成され、空であってもよいです。 AU-ヘッダが空に設定されている場合、AU-ヘッダ長フィールドは存在してはならない、その結果、AUヘッダセクションは空です。 AU-ヘッダーが空で構成されていない場合は、AU-ヘッダ長は、パディングビットを除いた直後AU-ヘッダのビットの長さを指定する2つのオクテットフィールドです。
Each AU-header is associated with a single Access Unit (fragment) contained in the Access Unit Data Section in the same RTP packet.
各AU-ヘッダが同じRTPパケット内のアクセス単位データセクションに含まれる単一のアクセスユニット（断片）に関連しています。
For each contained Access Unit (fragment), there is exactly one AU-header. Within the AU Header Section, the AU-headers are bit-wise concatenated in the order in which the Access Units are contained in the Access Unit Data Section. Hence, the n-th AU-header refers to the n-th AU (fragment). If the concatenated AU-headers consume a non-integer number of octets, up to 7 zero-padding bits MUST be inserted at the end in order to achieve octet-alignment of the AU Header Section.
それぞれのアクセスユニット（断片）を含有するため、正確に一つのAU-ヘッダがあります。 AUヘッダーセクション内で、AU-ヘッダは、ビット単位のアクセス単位は、アクセスユニットデータセクションに含まれている順に連結されています。したがって、n番目のAU-ヘッダは、n番目のAU（断片）を指します。連結AU-ヘッダがオクテットの非整数番号を消費する場合、最大7ゼロパディングビットは、AUのヘッダセクションのオクテット整列を達成するために端部に挿入されなければなりません。
Each AU-header may contain the fields given in Figure 3. The length in bits of the fields, with the exception of the CTS-flag, the DTS-flag and the RAP-flag fields, is defined by MIME format parameters; see section 4.1. If a MIME format parameter has the default value of zero, then the associated field is not present. The number of bits for fields that are present and that represent the value of a parameter MUST be chosen large enough to correctly encode the largest value of that parameter during the session.
各AU-ヘッダは、図3のフィールドのビットの長さで指定されたフィールドを含んでいてもよい、CTS-フラグ、DTSフラグおよびRAP-フラグフィールドを除いて、MIME形式のパラメータによって定義されます。セクション4.1を参照してください。 MIME形式のパラメータがゼロのデフォルト値がある場合、対応するフィールドは存在しません。存在し、各フィールドのビット数は、パラメータの値が正しくセッション中にそのパラメータの最大値をエンコードするのに十分に大きく選択されなければならない表します。
If present, the fields MUST occur in the mutual order given in Figure 3. In the general case, a receiver can only discover the size of an AU-header by parsing it since the presence of the CTS-delta and DTS-delta fields is signaled by the value of the CTS-flag and DTS-flag, respectively.
存在する場合、フィールドは一般的なケースでは、図3に示す相互の順序で発生する必要があり、受信機は、CTSデルタ及びDTSデルタフィールドが存在することであるので、それを解析してAU-ヘッダのサイズを発見することができるだけそれぞれ、CTS-フラグ及びDTSフラグの値によって合図。
+---------------------------------------+
| AU-size |
+---------------------------------------+
| AU-Index / AU-Index-delta |
+---------------------------------------+
| CTS-flag |
+---------------------------------------+
| CTS-delta |
+---------------------------------------+
| DTS-flag |
+---------------------------------------+
| DTS-delta |
+---------------------------------------+
| RAP-flag |
+---------------------------------------+
| Stream-state |
+---------------------------------------+
Figure 3: The fields in the AU-header. If used, the AU-Index field only occurs in the first AU-header within an AU Header Section; in any other AU-header, the AU-Index-delta field occurs instead.
図3：AU-ヘッダ内のフィールド。使用した場合、AU-Indexフィールドは、AUのヘッダセクション内の最初のAU-ヘッダで発生します。他のAU-ヘッダに、AU-インデックスデルタフィールドが代わりに発生します。
AU-size: Indicates the size in octets of the associated Access Unit in the Access Unit Data Section in the same RTP packet. When the AU-size is associated with an AU fragment, the AU size indicates the size of the entire AU and not the size of the fragment. In this case, the size of the fragment is known from the size of the AU data section. This can be exploited to determine whether a packet contains an entire AU or a fragment, which is particularly useful after losing a packet carrying the last fragment of an AU.
AU-サイズ：同じRTPパケット内のアクセスユニットデータセクション内の関連するアクセスユニットのオクテットでサイズを示します。 AUサイズがAUフラグメントに関連付けられている場合、AUサイズが全体AUのサイズはなく、断片の大きさを示しています。この場合、断片のサイズは、全てのデータ部のサイズから公知です。これは、パケット全体AUまたはAUの最後の断片を運ぶパケットを失った後に特に有用であるフラグメントを含んでいるかどうかを決定するために利用することができます。
AU-Index: Indicates the serial number of the associated Access Unit (fragment). For each (in decoding order) consecutive AU or AU fragment, the serial number is incremented by 1. When present, the AU-Index field occurs in the first AU-header in the AU Header Section, but MUST NOT occur in any subsequent (non-first) AU-header in that Section. To encode the serial number in any such non-first AU-header, the AU-Index-delta field is used.
AU-インデックス：関連するアクセスユニット（フラグメント）のシリアル番号を示します。 、AU-Indexフィールドは、AUのヘッダセクションの最初のAU-ヘッダに発生した場合に存在する（復号順で）各連続AUまたはAU断片ため、シリアル番号が1だけインクリメントされるが、（それ以降に発生してはいけませんそのセクションの）非最初のAU-ヘッダ。このような非最初のAU-ヘッダにシリアル番号を符号化するために、AU-インデックスデルタフィールドが使用されます。
AU-Index-delta: The AU-Index-delta field is an unsigned integer that specifies the serial number of the associated AU as the difference with respect to the serial number of the previous Access Unit. Hence, for the n-th (n>1) AU, the serial number is found from:
AU-索引デルタ：AU-インデックスデルタフィールドは、前のアクセスユニットのシリアル番号との差分として関連AUのシリアル番号を指定する符号なし整数です。したがって、n番目（N> 1）AUのために、シリアル番号は、以下から見出されます。
AU-Index(n) = AU-Index(n-1) + AU-Index-delta(n) + 1
AU-率（n）（N）= AU-率（n-1）+ AU-索引デルタ+ 1
If the AU-Index field is present in the first AU-header in the AU Header Section, then the AU-Index-delta field MUST be present in any subsequent (non-first) AU-header. When the AU-Index-delta is coded with the value 0, it indicates that the Access Units are consecutive in decoding order. An AU-Index-delta value larger than 0 signals that interleaving is applied.
AU-Indexフィールドは、AUのヘッダセクションの最初のAU-ヘッダ内に存在する場合、AU-インデックスデルタフィールドは、後続の（非最初）AU-ヘッダに存在していなければなりません。 AU-指数デルタは値0でコード化された場合、アクセスユニットは、復号化順序で連続していることを示しています。インターリービングが適用される0信号よりも大きいAU-指数デルタ値。
CTS-flag: Indicates whether the CTS-delta field is present. A value of 1 indicates that the field is present, a value of 0 indicates that it is not present.
CTS-フラグ：CTSデルタフィールドが存在しているかどうかを示します。 1の値は、0の値は、それが存在しないことを示し、フィールドが存在することを示します。
The CTS-flag field MUST be present in each AU-header if the length of the CTS-delta field is signaled to be larger than zero. In that case, the CTS-flag field MUST have the value 0 in the first AU-header and MAY have the value 1 in all non-first AU-headers. The CTS-flag field SHOULD be 0 for any non-first fragment of an Access Unit.
CTSデルタフィールドの長さがゼロよりも大きくなるように信号伝達される場合にCTS-フラグフィールドは、各AU-ヘッダに存在していなければなりません。その場合には、CTS-フラグフィールドは、第AU-ヘッダに値0を有していなければならず、すべての非最初のAU-ヘッダに値1があるかもしれません。 CTS-フラグフィールドは、アクセスユニットの任意の非最初のフラグメントに対して0でなければなりません。
CTS-delta: Encodes the CTS by specifying the value of CTS as a 2's complement offset (delta) from the time stamp in the RTP header of this RTP packet. The CTS MUST use the same clock rate as the time stamp in the RTP header.
CTS-デルタ：このRTPパケットのRTPヘッダ内のタイムスタンプからオフセット2の補数としてCTSの値（デルタ）を指定してCTSをエンコード。 CTSは、RTPヘッダ内のタイムスタンプと同じクロックレートを使用しなければなりません。
DTS-flag: Indicates whether the DTS-delta field is present. A value of 1 indicates that DTS-delta is present, a value of 0 indicates that it is not present.
DTS-フラグ：DTSデルタフィールドが存在しているかどうかを示します。 1の値は、0の値は、それが存在しないことを示す、DTSデルタが存在することを示します。
The DTS-flag field MUST be present in each AU-header if the length of the DTS-delta field is signaled to be larger than zero. The DTS-flag field MUST have the same value for all fragments of an Access Unit.
DTSデルタフィールドの長さがゼロよりも大きくなるように信号伝達される場合、DTSフラグフィールドは、各AU-ヘッダに存在していなければなりません。 DTS-フラグフィールドは、アクセスユニットの全てのフラグメントに対して同じ値を持たなければなりません。
DTS-delta: Specifies the value of the DTS as a 2's complement offset (delta) from the CTS. The DTS MUST use the same clock rate as the time stamp in the RTP header. The DTS-delta field MUST have the same value for all fragments of an Access Unit.
DTS-デルタ：2の補数オフセットとしてCTSから（デルタ）DTSの値を指定します。 DTSは、RTPヘッダ内のタイムスタンプと同じクロックレートを使用しなければなりません。 DTSデルタフィールドには、アクセスユニットの全てのフラグメントに対して同じ値を持たなければなりません。
RAP-flag: When set to 1, indicates that the associated Access Unit provides a random access point to the content of the stream. If an Access Unit is fragmented, the RAP flag, if present, MUST be set to 0 for each non-first fragment of the AU.
RAPフラグ：1に設定すると、関連するアクセスユニットがストリームのコンテンツへのランダムアクセスポイントを提供することを示しています。アクセスユニットが断片化されている場合、RAPフラグが、存在する場合、AUの各非最初のフラグメントに対して0に設定しなければなりません。
Stream-state: Specifies the state of the stream for an AU of an MPEG-4 system stream; each state is identified by a value of a modulo counter. In ISO/IEC 14496-1, MPEG-4 system streams use the AU_SequenceNumber to signal stream states. When the stream state changes, the value of the stream-state MUST be incremented by one.
ストリーム状態：MPEG-4システムストリームのAUのためのストリームの状態を指定します。各状態は、モジュロカウンタの値によって識別されます。 ISO / IEC 14496-1では、MPEG-4システムストリームは、ストリームの状態を知らせるためにAU_SequenceNumberを使用します。ストリーム状態変更は、ストリーム状態の値を1だけインクリメントしなければならない場合。
Note: no relation is required between stream-states of different streams.
注：関係が異なるストリームのストリーム状態の間で必要とされません。
The Auxiliary Section consists of the auxiliary-data-size field followed by the auxiliary-data field. Receivers MAY (but are not required to) parse the auxiliary-data field; to facilitate skipping of the auxiliary-data field by receivers, the auxiliary-data-size field indicates the length in bits of the auxiliary-data. If the concatenation of the auxiliary-data-size and the auxiliary-data fields consume a non-integer number of octets, up to 7 zero padding bits MUST be inserted immediately after the auxiliary data in order to achieve octet-alignment. See Figure 4.
補助部は、補助データフィールドに続く補助データサイズフィールドから成ります。レシーバMAY補助データ・フィールドを解析する（しかしをする必要はありません）。受信機による補助データフィールドのスキップ容易にするために、補助データサイズフィールドは、補助データのビット長を示しています。補助データサイズ及び補助データフィールドの連結は、7ゼロパディングビットまでオクテットの非整数番号を、消費する場合オクテット整列を達成するために、補助データの直後に挿入しなければなりません。図4を参照してください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+
| auxiliary-data-size | auxiliary-data |padding bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+
Figure 4: The fields in the Auxiliary Section
図4：補助セクションのフィールド
The length in bits of the auxiliary-data-size field is configurable by a MIME format parameter; see section 4.1. The default length of zero indicates that the entire Auxiliary Section is absent.
補助データ・サイズフィールドのビット長は、MIME形式のパラメータで構成可能です。セクション4.1を参照してください。ゼロのデフォルトの長さは、全体の補助部が存在しないことを示しています。
auxiliary-data-size: specifies the length in bits of the immediately following auxiliary-data field;
補助データサイズは、：直後の補助データフィールドのビットの長さを指定します。
auxiliary-data: the auxiliary-data field contains data of a format not defined by this specification.
補助データ：補助データ・フィールドは、この仕様で定義されていない形式のデータを含みます。
The Access Unit Data Section contains an integer number of complete Access Units or a single fragment of one AU. The Access Unit Data Section is never empty. If data of more than one Access Unit is present, then the AUs are concatenated into a contiguous string of octets. See Figure 5. The AUs inside the Access Unit Data Section MUST be in decoding order, though not necessarily contiguous in the case of interleaving.
アクセスユニットデータセクションは、完全なアクセス単位の整数または1 AUの単一のフラグメントが含まれています。アクセスユニットデータセクションは空になることはありません。複数のアクセスユニットのデータが存在する場合、AUSがオクテットの連続した文字列に連結されています。 、インターリービングの場合に必ずしも連続していないかのアクセスユニットのデータセクション内のAUがデコーディング順序である必要があり、図5を参照してください。
The size and number of Access Units SHOULD be adjusted such that the resulting RTP packet is not larger than the path MTU. To handle larger packets, this payload format relies on lower layers for fragmentation, which may result in reduced performance.
アクセスユニットの大きさと数は、得られるRTPパケットが経路MTUよりも大きくないように調整されるべきです。大きなパケットを処理するために、このペイロード形式は性能低下につながる可能性がある、断片化のために下位層に依存しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(1) |
+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AU(2) |
+-+-+-+-+-+-+-+-+ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AU(n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(n) continued|
|-+-+-+-+-+-+-+-+
Figure 5: Access Unit Data Section; each AU is octet-aligned.
図5：アクセスユニットデータセクション。各AUは、オクテット整列です。
When multiple Access Units are carried, the size of each AU MUST be made available to the receiver. If the AU size is variable, then the size of each AU MUST be indicated in the AU-size field of the corresponding AU-header. However, if the AU size is constant for a stream, this mechanism SHOULD NOT be used; instead, the fixed size SHOULD be signaled by the MIME format parameter "constantSize"; see section 4.1.
複数のアクセスユニットが搬送される際に、各AUのサイズは、受信機に利用可能にしなければなりません。 AUのサイズが可変である場合には、各AUのサイズは、対応するAU-ヘッダのAUサイズフィールドに示されなければなりません。 AUのサイズはストリームについて一定である場合には、このメカニズムを使用すべきではありません。代わりに、固定されたサイズは、MIME形式のパラメータ「constantSize」によって合図されるべきです。セクション4.1を参照してください。
The absence of both AU-size in the AU-header and the constantSize MIME format parameter indicates the carriage of a single AU (fragment), i.e., that a single Access Unit (fragment) is transported in each RTP packet for that stream.
AU-ヘッダとconstantSize MIME形式パラメータのAUサイズの両方の不在は、単一のアクセスユニット（フラグメント）は、そのストリームの各RTPパケットに輸送されること、すなわち、単一のAU（断片）のキャリッジを示します。
A packet SHALL carry either one or more complete Access Units, or a single fragment of an Access Unit. Fragments of the same Access Unit have the same time stamp but different RTP sequence numbers. The marker bit in the RTP header is 1 on the last fragment of an Access Unit, and 0 on all other fragments.
パケットは、1つ以上の完全なアクセス単位、またはアクセスユニットの単一フラグメントのいずれかを運ぶものとします。同じアクセスユニットのフラグメントは、同じタイムスタンプが異なるRTPシーケンス番号を持っています。 RTPヘッダ内のマーカビットは、アクセスユニットの最後のフラグメントに1であり、そして他のすべてのフラグメントで0。
Unless prohibited by the signaled mode, a sender MAY interleave Access Units. Receivers that are capable of receiving modes that support interleaving MUST be able to decode interleaved Access Units.
合図モードで禁止されていない限り、送信者がアクセス単位をインターリーブするかもしれません。インタリービングをサポートするモードを受信することが可能な受信機は、インターリーブアクセスユニットを復号できなければなりません。
When a sender interleaves Access Units, it needs to provide sufficient information to enable a receiver to unambiguously reconstruct the original order, even in the case of out-of-order packets, packet loss or duplication. The information that senders need to provide depends on whether or not the Access Units have a constant time duration. Access Units have a constant time duration, if:
送信者がアクセスユニットをインターリーブするとき、それは明確にもアウトオブオーダーパケット、パケット損失または重複した場合に、元の順序を復元するために受信機を有効にするのに十分な情報を提供する必要があります。送信者が必要な情報は、アクセス単位は、一定の時間間隔を持っているか否かに依存します。場合は、アクセスユニットは、一定の時間幅を持っています：
TS(i+1) - TS(i) = constant
TS（I + 1） - TS（I）=定数
for any i, where:
i indicates the index of the AU in the original order, and
TS(i) denotes the time stamp of AU(i)
The MIME parameter "constantDuration" SHOULD be used to signal that Access Units have a constant time duration; see section 4.1.
MIMEパラメータ「constantDuration」は、そのアクセス単位は、一定の時間間隔を持って通知するために使用されるべきです。セクション4.1を参照してください。
If the "constantDuration" parameter is present, the receiver can reconstruct the original Access Unit timing based solely on the RTP timestamp and AU-Index-delta. Accordingly, when transmitting Access Units of constant duration, the AU-Index, if present, MUST be set to the value 0. Receivers of constant duration Access Units MUST use the RTP timestamp to determine the index of the first AU in the RTP packet. The AU-Index-delta header and the signaled "constantDuration" are used to reconstruct AU timing.
「constantDuration」パラメータが存在する場合、受信機は、単にRTPタイムスタンプとAU-インデックス・デルタに基づいて、元のアクセスユニットのタイミングを再構築することができます。一定期間のアクセスユニットを送信する際に、AU-指数は、存在する場合、RTPパケットの最初のAUのインデックスを決定するために、RTPタイムスタンプを使用しなければならない値に一定期間アクセスユニット0レシーバを設定しなければなりません。 AU-索引デルタヘッダおよびシグナリング「constantDurationは」AUタイミングを再構成するために使用されます。
If the "constantDuration" parameter is not present, then senders MAY signal AUs of constant duration by coding the AU-Index with zero in each RTP packet. In the absence of the constantDuration parameter receivers MUST conclude that the AUs have constant duration if the AU-index is zero in two consecutive RTP packets.
「constantDuration」パラメータが存在しない場合、送信者は、各RTPパケットにゼロとAU-インデックスを符号化し、一定期間のAUをシグナリングすることができます。 constantDurationパラメータの非存在下で受信機は、AU-指数は、2つの連続するRTPパケットにゼロである場合のAUが一定の持続時間を有すると結論しなければなりません。
When transmitting Access Units of variable duration, then the "constantDuration" parameter MUST NOT be present, and the transmitter MUST use the AU-Index to encode the index information required for re-ordering, and the receiver MUST use that value to determine the index of each AU in the RTP packet. The number of bits of the AU-Index field MUST be chosen so that valid index information is provided at the applied interleaving scheme, without causing problems due to roll-over of the AU-Index field. In addition, the CTS-delta MUST be coded in the AU header for each non-first AU in the RTP packet, so that receivers can place the AUs correctly in time.
可変持続時間のアクセスユニットを送信する場合、次いで「constantDuration」パラメータが存在してはならない、および送信機は、再順序付けするために必要なインデックス情報を符号化するためにAU-インデックスを使用しなければなりません、そして、受信機は、インデックスを決定するためにその値を使用する必要がありますRTPパケット内の各AUの。有効なインデックス情報がAU-Indexフィールドのオーバーロールに起因する問題を引き起こすことなく、適用されたインターリーブ方式で提供されるように、AU-Indexフィールドのビット数を選択しなければなりません。受信機は、時間に正確AUを置くことができるように、また、CTSデルタは、RTPパケット内の各非最初のAUのためのAUのヘッダで符号化されなければなりません。
When interleaving is applied, a de-interleave buffer is needed in receivers to put the Access Units in their correct logical consecutive decoding order. This requires the computation of the time stamp for each Access Unit. In case of a constant time duration per Access Unit, the time stamp of the i-th access unit in an RTP packet with RTP time stamp T is calculated as follows:
インターリーブが適用されると、デインタリーブバッファは、その正しい論理の連続したデコード順にアクセス単位を置くために受信機で必要とされます。これは、各アクセスユニットのタイムスタンプの計算を必要とします。アクセスユニット、次のように計算されるRTPタイムスタンプTのRTPパケット内のi番目のアクセスユニットのタイムスタンプごとに一定の持続時間の場合：
Timestamp[0] = T Timestamp[i, i > 0] = T +(Sum(for k=1 to i of (AU-Index-delta[k] + 1))) * access-unit-duration
タイムスタンプ[0] = Tタイムスタンプ[I、I> 0] = T + *アクセス単位の持続時間（SUM（K = 1（AU-指数デルタ[K] + 1））のIへ）
When AU-Index-delta is always 0, this reduces to T + i * (access-unit-duration). This is the non-interleaved case, where the frames are consecutive in decoding order. Note that the AU-Index field (present for the first Access Unit) is indeed not needed in this calculation.
AU-インデックスデルタは常に0である場合には、これは私が（アクセスユニット・期間を）* T +に減少します。これは、フレームが復号化順に連続している非インタリーブの場合、です。 AU-Indexフィールド（最初のアクセスユニットのための本は）確かに、この計算で必要とされないことに注意してください。
The size of the packets should be suitably chosen to be appropriate to both the path MTU and the capacity of the receiver's de-interleave buffer. The maximum packet size for a session SHOULD be chosen to not exceed the path MTU.
パケットのサイズは、適切にパスMTUと受信機のデインターリーブバッファの容量の両方に適切であるように選択されるべきです。セッションの最大パケットサイズは、パスMTUを超えないように選択されるべきです。
To allow receivers to allocate sufficient resources for de-interleaving, senders MUST provide the information to receivers as specified in this section.
このセクションで指定されるように受信機は、デインターリーブのために十分なリソースを割り当てることができるように、送信者は、受信機に情報を提供しなければなりません。
AUs enter the decoder in decoding order. The de-interleave buffer is used to re-order a stream of interleaved AUs back into decoding order. When interleaving is applied, the decoding of "early" AUs has to be postponed until all AUs that precede it in decoding order are present. Therefore, these "early" AUs are stored in the de-interleave buffer. As an example in Figure 6, the interleaving pattern from section 2.5 is considered.
AUは、復号順でデコーダに入ります。デインタリーブバッファは、バック復号順にインターリーブAUのストリームを再順序付けするために使用されます。適用されるインターリーブすると、のデコードは「早期」のAUは、復号順でその前に存在している全てのAUまで延期する必要があります。したがって、これらの「早期」のAUがデインタリーブバッファに格納されています。図6の一例として、セクション2.5からのインターリーブパターンが考えられます。
+--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|.. +--+--+--+--+--+--+--+--+--+--+--+- Storage of "early" AUs 3 3 3 3 3 3 6 6 6 6 6 6 4 4 4 7 7 7 12 12
+ - + - + - + - + - + - + - + - + - + - + - + - インターリーブのAU | 0 | 3 | 6 | 1 | 4 | 7 | 2 | 5 | 8 | 9 | 12 | ... + - + - + - + - + - + - + - + - + - + - + - + - 3 3 3 "早期" のAUのストレージ3 3 3 6 6 6 6 6 6 4 4 4 7 7 7 12 12
Figure 6: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
図6：インターリーブされたAUあたりのデインタリーブバッファにおける「早期」のAUのストレージ。
AU(3) is to be delivered to the decoder after AU(0), AU(1) and AU(2); of these AUs, AU(2) arrives from the network last and hence AU(3) needs to be stored until AU(2) is present in the pattern. Similarly, AU(6) is to be stored until AU(5) is present, while AU(4) and AU(7) are to be stored until AU(2) and AU(5) are present, respectively. Note that the fullness of the de-interleave buffer varies in time. In Figure 6, the de-interleave buffer contains at most 4, but often less AUs.
AU（3）AUの後にデコーダに配信される（0）、AU（1）及びAU（2）。これらの中のAU、AU（2）ネットワークから到着最後ひいてはAU（3）AUまで保存する必要がある（2）のパターンで存在します。 AUは、（4）、AU（7）（5）は、それぞれ存在するAU（2）及びAUまで保存すべきであるがAU（5）は、存在するまで同様に、AU（6）が格納されます。デインタリーブバッファの占有量が時間的に変化することに留意されたいです。図6に、デインタリーブバッファは最も4に含まれ、しばしば以下のAU。
So as to give a rough indication of the resources needed in the receiver for de-interleaving, the maximum displacement in time of an AU is defined. For any AU(j) in the pattern, each AU(i) with i<j that is not yet present can be determined. The maximum displacement in time of an AU is the maximum difference between the time stamp of an AU in the pattern and the time stamp of the earliest AU that is not yet present. In other words, when considering a sequence of interleaved AUs, then:
デインターリーブするための受信機で必要なリソースの目安を与えるように、AUの時間における最大変位が定義されます。 I <まだ存在していないjを決定することができるとともに、パターン内の任意のAU（j）は、各AU（I）のために。 AUの時間における最大変位は、パターン内のAUのタイムスタンプと、まだ存在していない最も早いAUのタイムスタンプとの間の最大差です。つまり、インターリーブされたAUのシーケンスを考慮する際、次のようになります。
Maximum displacement = max{TS(i) - TS(j)}
最大変位=最大{TS（I） - TS（J）}
for any i and any j>i, where:
i and j indicate the index of the AU in the interleaving
pattern, and
TS denotes the time stamp of the AU.
As an example in Figure 7, the interleaving pattern from section 2.5 is considered. For each AU in the pattern, the index is given of the earliest of any earlier AUs not yet present. Hence for each AU(n) in the interleaving pattern the smallest index k (with k<n) of not yet delivered AUs is indicated. A "-" indicates that all previous AUs are present. If the AU period is constant, the maximum displacement equals 5 AU periods, as found for AU(6) and AU(7).
図7の例のように、セクション2.5からのインターリーブパターンが考えられます。パターンの各AUのために、インデックスがまだ存在していない以前のAUの最も早いについて説明します。したがって、各AU（n）のためのインタリーブパターンで、まだ配信されないAUの（kは<n）の最小インデックスkが示されています。 A「 - 」以前のすべてのAUが存在していることを示しています。 AUの期間が一定であればAU（6）及びAU（7）について見出されるよう、最大変位は、5つのAU期間に等しいです。
+--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|.. +--+--+--+--+--+--+--+--+--+--+--+-
+ - + - + - + - + - + - + - + - + - + - + - + - インターリーブされたのAU | 0 | 3 | 6 | 1 | 4 | 7 | 2 | 5 | 8 | 9 | 12 | ... + - + - + - + - + - + - + - + - + - + - + - + -
Earliest not yet present AU - 1 1 - 2 2 - - - - 10
最早、まだ存在していないAU - 1月1日から2月2日まで - - - - 10
Figure 7: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
図7：各AUについてインターリーブパターン、まだ存在していない以前のAUの最も初期に
When interleaving, senders MUST signal the maximum displacement in time during the session via the MIME format parameter "maxDisplacement"; see section 4.1.
インターリーブ場合、送信者は、MIME形式のパラメータ「maxDisplacement」を介して、セッション中の時間内に最大変位を通知しなければなりません。セクション4.1を参照してください。
An estimate of the size of the de-interleave buffer is found by multiplying the maximum displacement by the maximum bit rate:
デインターリーブバッファの大きさの推定値は、最大ビットレートにより最大変位を乗算することによって見出されます。
size(de-interleave buffer) = {(maxDisplacement) * Rate(max)} / (RTP clock frequency),
サイズ（デインターリーブバッファ）= {（maxDisplacement）*レート（MAX）} /（RTPクロック周波数）
where:
Rate(max) is the maximum bit-rate of the transported stream.
Note that receivers can derive Rate(max) from the MIME format parameters streamType, profile-level-id, and config.
受信機は、MIMEフォーマットパラメータstreamType、プロファイルレベルID、および構成からレート（max）を導き出すことができることに留意されたいです。
However, this calculation estimates the size of the de-interleave buffer and the required size may differ from the calculated value. If this calculation under-estimates the size of the de-interleave buffer, then senders, when interleaving, MUST signal a size of the de-interleave buffer via the MIME format parameter "de-interleaveBufferSize"; see section 4.1. If the calculation over-estimates the size of the de-interleave buffer, then senders, when interleaving, MAY signal a size of the de-interleave buffer via the MIME format parameter "de-interleaveBufferSize".
しかし、この計算は、計算された値と異なる場合があり、デインタリーブバッファおよび必要なサイズの大きさを推定します。アンダー推定デインターリーブバッファのサイズこの計算場合、送信者は、インターリーブ場合、MIME形式のパラメータ「脱interleaveBufferSize」を介してデインターリーブバッファのサイズを通知しなければなりません。セクション4.1を参照してください。過推定計算デインターリーブバッファのサイズ場合インターリーブとき、次に送信者は、MIME形式のパラメータ「脱interleaveBufferSize」を介してデインターリーブバッファのサイズをシグナリングすることができます。
The signaled size of the de-interleave buffer MUST be large enough to contain all "early" AUs at any point in time during the session. That is:
デインタリーブバッファの合図サイズは、セッション中の任意の時点で、すべての「早期」のAUを含むのに十分な大きさでなければなりません。あれは：
minimum de-interleave buffer size = max [sum {if TS(i) > TS(j) then AU-size(i) else 0}]
最小デインタリーブバッファサイズ=最大[和{もしTS（I）> TS（J）次にAUサイズ（I）他0}]
for any j and any i<j, where:
i and j indicate the index of an AU in the interleaving
pattern,
TS(i) denotes the time stamp of AU(i), and
AU-size(i) denotes the size of AU(i) in number of octets.
If the "de-interleaveBufferSize" parameter is present, then the applied buffer for de-interleaving in a receiver MUST have a size that is at least equal to the signaled size of the de-interleave buffer, else a size that is at least equal to the calculated size of the de-interleave buffer.
「脱interleaveBufferSize」パラメータが存在する場合、受信機においてデインターリーブするための適用バッファは、少なくとも同等であるデインターリーブバッファのシグナリングサイズに少なくとも等しいサイズ、他の大きさがなければなりませんデインターリーブバッファの計算されたサイズです。
No matter what interleaving scheme is used, the scheme must be analyzed to calculate the applicable maxDisplacement value, as well as the required size of the de-interleave buffer. Senders SHOULD signal values that are not larger than the strictly required values; if larger values are signaled, the receiver will buffer excessively.
どんなに使用されているものをインターリーブ方式で、スキームが適用maxDisplacement値だけでなく、デインターリーブバッファの必要なサイズを計算するために分析しないする必要があります。送信者は、厳密に必要な値よりも大きくない値を通知すべきです。大きな値が通知された場合、受信機は、過度にバッファリングします。
Note that for low bit-rate material, the applied interleaving may make packets shorter than the MTU size.
低ビットレート材に、適用されたインターリービングがMTUサイズより短いパケットを行うことができることに留意されたいです。
Some Access Units with MPEG-4 system data, called "crucial" AUs, carry information whose loss cannot be tolerated, either in the presentation or in the decoder. At each crucial AU in an MPEG-4 system stream, the stream state changes. The stream-state MAY remain constant at non-crucial AUs. In ISO/IEC 14496-1, MPEG-4 system streams use the AU_SequenceNumber to signal stream states.
「重要」のAUと呼ばれるMPEG-4システムデータを有するいくつかのアクセスユニットは、その損失プレゼンテーション又はデコーダのいずれかで、許容できない情報を運びます。 MPEG-4システムストリーム内の各重要なAUに、流れ状態の変化。ストリーム状態は非決定的なのAUで一定のままであってもよいです。 ISO / IEC 14496-1では、MPEG-4システムストリームは、ストリームの状態を知らせるためにAU_SequenceNumberを使用します。
Example: Given three AUs, AU1 = "Insertion of node X", AU2 = "Set position of node X", AU3 = "Set position of node X". AU1 is crucial, since if it is lost, AU2 cannot be executed. However, AU2 is not crucial, since AU3 can be executed even if AU2 is lost.
例：考える3のAU、AU1 =「ノードXの挿入」、AU2、AU3は=「ノードXの設定位置」=「ノードXの設定位置」。それが失われた場合、AU2は実行できないので、AU1は、非常に重要です。 AU3はAU2が失われても実行することができるので、AU2は、重要ではありません。
When a crucial AU is (possibly) lost, the stream is corrupted. For example, when an AU is lost and the stream state has changed at the next received AU, then it is possible that the lost AU was crucial. Once corrupted, the stream remains corrupted until the next random access point. Note that loss of non-crucial AUs does not corrupt the stream. When a decoder starts receiving a stream, the decoder MUST consider the stream corrupted until an AU is received that provides a random access point.
重要なAUは、（おそらく）が失われた場合、ストリームが破損しています。例えば、AUが失われ、ストリーム状態が次の受信AUに変化した場合、失われたAUが重要であった可能性があります。破損したら、流れは次のランダムアクセスポイントまで破損したままです。非決定的なのAUの損失が破損していないストリームを行います注意してください。デコーダがストリームの受信を開始すると、デコーダは、AUがランダムアクセスポイントを提供する受信されるまで破損したストリームを考慮しなければなりません。
An AU that provides a random access point, as signaled by the RAP-flag, may or may not be crucial. Non-crucial RAP AUs provide a "repeated" random access point for use by decoders that recently joined the stream or that need to re-start decoding after a stream corruption. Non-crucial RAP AUs MUST include all updates since the last crucial RAP AU.
ランダムアクセスポイントを提供AUは、RAP-フラグで合図として、または重要であってもなくてもよいです。非決定的なRAPのAUは最近、ストリームまたは再起動ストリームの破損後にデコードするために、その必要性を参加デコーダで使用するための「繰り返し」ランダム・アクセス・ポイントを提供します。非決定的なRAPのAUは、最後の決定的なRAP AUので、すべての更新を含まなければなりません。
Upon receiving AUs, decoders are to react as follows:
AUを受信すると、デコーダは、次のように反応させることです。
a) if the RAP-flag is set to 1 and the stream-state changes, then the AU is a crucial RAP AU, and the AU MUST be decoded.
RAP-フラグが1とストリーム状態変更に設定されている場合A）、次いで、AUが重要RAP AUで、AUは、復号化されなければなりません。
b) if the RAP-flag is set to 1 and the stream state does not change, then the AU is a non-crucial RAP AU, and the receiver SHOULD decode it if the stream is corrupted. Otherwise, the decoder MUST ignore the AU.
B）RAPフラグが1に設定され、ストリーム状態が変化しない場合には、AUは、非決定的なRAP AUであり、ストリームが破損している場合、受信機はそれを復号化すべきです。それ以外の場合は、デコーダは、AUを無視しなければなりません。
c) if the RAP-flag is set to 0, then the AU MUST be decoded, unless the stream is corrupted, in which case the AU MUST be ignored.
RAP-フラグが0に設定されている場合、ストリームが破損されていない限り、C）、次いで、AUは、AUを無視しなければならない場合には、復号化されなければなりません。
Usage of this specification requires definition of a mode. A mode defines how to use this specification, as deemed appropriate. Senders MUST signal the applied mode via the MIME format parameter "mode", as specified in section 4.1. This specification defines a generic mode that can be used for any MPEG-4 stream, as well as specific modes for the transportation of MPEG-4 CELP and MPEG-4 AAC streams, defined in ISO/IEC 14496-3 [1].
この仕様書の使用法は、モードの定義が必要。モードは、適切と思われるように、この仕様を使用する方法を定義します。セクション4.1で指定された送信者は、MIMEフォーマットパラメータ「モード」を介して印加されるモードを通知しなければなりません。この仕様は、ISO / IEC 14496-3で定義されたMPEG-4 CELPおよびMPEG-4 AACストリームの輸送のための任意のMPEG-4ストリームのために使用することができる一般的なモード、ならびに特定のモードを定義する[1]。
When use of this payload format is signaled using SDP [5], an "rtpmap" attribute is part of that signaling. The same requirements apply for the rtpmap attribute in any mode compliant to this specification. The general form of an rtpmap attribute is:
このペイロードフォーマットの使用は、SDPを使用して通知されたときに[5]、「rtpmap」属性は、シグナリングの一部です。同じ要件は、この仕様に準拠する任意のモードで、rtpmap属性に適用されます。 rtpmap属性の一般的な形式は次のとおりです。
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
A = rtpmap：<ペイロードタイプ> <コード名> / <クロックレート> / <符号化パラメータ>]
For audio streams, <encoding parameters> specifies the number of audio channels: 2 for stereo material (see RFC 2327 [5]) and 1 for mono. Provided no additional parameters are needed, this parameter may be omitted for mono material, hence its default value is 1.
オーディオストリームは、<符号化パラメータ>は、音声チャネルの数を指定：2ステレオ材料と1モノため（[5] RFC 2327を参照します）。追加のパラメータが必要とされない設け、このパラメータは、そのデフォルト値は1であるため、モノラル材料のために省略されてもよいです。
The generic mode can be used for any MPEG-4 stream. In this mode, no mode-specific constraints are applied; hence, in the generic mode, the full flexibility of this specification can be exploited. The generic mode is signaled by mode=generic.
一般的なモードは、任意のMPEG-4ストリームのために使用することができます。このモードでは、モード固有の制約が適用されません。したがって、一般的なモードでは、この仕様の完全な柔軟性を活用することができます。一般的なモードは、モード=ジェネリックによって通知されます。
An example is given below for the transportation of a BIFS-Anim stream. In this example carriage of multiple BIFS-Anim Access Units is allowed in one RTP packet. The AU-header contains the AU-size field, the CTS-flag and, if the CTS flag is set to 1, the CTS-delta field. The number of bits of the AU-size and the CTS-delta fields are 10 and 16, respectively. The AU-header also contains the RAP-flag and the Stream-state of 4 bits. This results in an AU-header with a total size of two or four octets per BIFS-Anim AU. The RTP time stamp uses a 1 kHz clock. Note that the media type name is video, because the BIFS-Anim stream is part of an audio-visual presentation. For conventions on media type names, see section 4.1.
例はBIFS-Animの流れの輸送のために以下に与えられます。この例では、キャリッジ複数BIFS-Animののアクセスユニットは、1つのRTPパケットに許可されます。 CTSフラグが1に設定されている場合AU-ヘッダは、AUサイズフィールド、CTS-フラグが含まれており、CTSデルタフィールド。 AUサイズ及びCTSデルタフィールドのビット数は、それぞれ10と16です。 AU-ヘッダは、RAP-フラグと、4ビットのストリーム状態を含んでいます。これは、BIFS-AnimのAU当たり2つのまたは4つのオクテットの合計サイズとAU-ヘッダをもたらします。 RTPタイムスタンプは、1 kHzのクロックを使用しています。 BIFS-Animのストリームはオーディオビジュアルプレゼンテーションの一部であるため、メディアタイプ名は、映像であることに注意してください。メディアタイプ名の規則については、セクション4.1を参照してください。
In detail:
詳細に：
m=video 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/1000
a=fmtp:96 streamtype=3; profile-level-id=1807; mode=generic;
objectType=2; config=0842237F24001FB400094002C0; sizeLength=10;
CTSDeltaLength=16; randomAccessIndication=1;
streamStateIndication=4
Note: The a=fmtp line has been wrapped to fit the page, it comprises a single line in the SDP file.
注：A =のfmtpラインがページに収まるようにラップされている、それはSDPファイル内の1行を含みます。
The hexadecimal value of the "config" parameter is the BIFSConfiguration() as defined in ISO/IEC 14496-1. The BIFSConfiguration() specifies that the BIFS stream is a BIFS-Anim stream. For the description of MIME parameters, see section 4.1.
ISO / IEC 14496-1で定義されている「設定」パラメータの16進数の値はBIFSConfiguration（）です。 BIFSConfiguration（）はBIFSストリームがBIFS-Animのストリームであることを指定します。 MIMEパラメータの説明については、4.1節を参照してください。
This mode is signaled by mode=CELP-cbr. In this mode, one or more complete CELP frames of fixed size can be transported in one RTP packet; interleaving MUST NOT be used with this mode. The RTP payload consists of one or more concatenated CELP frames, each of equal size. CELP frames MUST NOT be fragmented when using this mode. Both the AU Header Section and the Auxiliary Section MUST be empty.
このモードは、モード= CELP-CBRによって通知されます。このモードでは、固定サイズの一つ以上の完全なCELPフレームが1つのRTPパケットに搬送することができます。インターリーブは、このモードを使用してはいけません。 RTPペイロードは、一つ以上の連結CELPフレーム、等しいサイズのそれぞれから成ります。このモードを使用するときにCELPフレームが断片化してはいけません。 AUヘッダーセクションおよび補助部の両方が空である必要があります。
The MIME format parameter constantSize MUST be provided to specify the length of each CELP frame.
MIME形式パラメータconstantSize各CELPフレームの長さを指定するために提供されなければなりません。
For example:
例えば：
m=audio 49230 RTP/AVP 96 a=rtpmap:96 mpeg4-generic/16000/1 a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-cbr; config= 440E00; constantSize=27; constantDuration=240
M =オーディオ49230 RTP / AVP 96 = rtpmap：96 MPEG4-ジェネリック/ 1分の16000 =のfmtp：96 streamtype = 5。プロファイルレベルID = 14。モード= CELP-CBR。コンフィグ= 440E00。 constantSize = 27; constantDuration = 240
Note: The a=fmtp line has been wrapped to fit the page, it comprises a single line in the SDP file.
注：A =のfmtpラインがページに収まるようにラップされている、それはSDPファイル内の1行を含みます。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig()as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono CELP stream with a sampling rate of 16 kHz at a fixed bitrate of 14.4 kb/s and 6 sub-frames per CELP frame. For the description of MIME parameters, see section 4.1.
ISO / IEC 14496-3で定義されている「設定」パラメータの16進数の値はAudioSpecificConfig（）です。 AudioSpecificConfig（）は14.4キロバイト/ sおよびCELPフレーム当り6サブフレームの固定ビットレートで16キロヘルツのサンプリングレートを有するモノCELPストリームを指定します。 MIMEパラメータの説明については、4.1節を参照してください。
This mode is signaled by mode=CELP-vbr. With this mode, one or more complete CELP frames of variable size can be transported in one RTP packet with OPTIONAL interleaving. In this mode, the largest possible value for AU-size is greater than the maximum CELP frame size. Because CELP frames are very small, there is no support for fragmentation of CELP frames. Hence, CELP frames MUST NOT be fragmented when using this mode.
このモードは、モード= CELP-VBRで通知されます。このモードでは、可変サイズの1つまたはそれ以上の完全なCELPフレームを任意のインタリーブと1つのRTPパケットで輸送することができます。このモードでは、AUサイズのために可能な最大値は、最大CELPフレームサイズよりも大きいです。 CELPフレームが非常に小さいため、CELPフレームの断片化はサポートされていません。このモードを使用するときしたがって、CELPフレームが断片化してはいけません。
In this mode, the RTP payload consists of the AU Header Section, followed by one or more concatenated CELP frames. The Auxiliary Section MUST be empty. For each CELP frame contained in the payload, there MUST be a one octet AU-header in the AU Header Section to provide:
このモードでは、RTPペイロードは、一つ以上の連結CELPフレームが続く、AUヘッダセクションから構成されています。補助部は空でなければなりません。ペイロードに含まれる各CELPフレームのために、提供するAUヘッダ部分に1つのオクテットAU-ヘッダが存在していなければなりません。
a) the size of each CELP frame in the payload and
a）は、ペイロード内の各CELPフレームのサイズと
b) index information for computing the sequence (and hence timing) of each CELP frame.
各CELPフレームのシーケンスを計算する（したがって、タイミングのためにB）のインデックス情報）。
Transport of CELP frames requires that the AU-size field be coded with 6 bits. Therefore, in this mode 6 bits are allocated to the AU-size field, and 2 bits to the AU-Index(-delta) field. Each AU-Index field MUST be coded with the value 0. In the AU Header Section, the concatenated AU-headers are preceded by the 16-bit AU-headers-length field, as specified in section 3.2.1.
CELPフレームの輸送は、AUサイズフィールドは6ビットで符号化されることを必要とします。したがって、このモードでは6ビットAUサイズフィールドに割り当てられ、及びAU-インデックス（ - デルタ）フィールドに2ビット。各AU-IndexフィールドはAUヘッダセクションにおいて値0で符号化されなければならないセクション3.2.1で指定されるように、連結AU-ヘッダは、16ビットのAU-ヘッダ長フィールドが先行します。
In addition to the required MIME format parameters, the following parameters MUST be present: sizeLength, indexLength, and indexDeltaLength. CELP frames always have a fixed duration per Access Unit; when interleaving in this mode, this specific duration
必要なMIME形式のパラメータに加えて、以下のパラメータが存在しなければならない：sizeLength、indexLength、及びindexDeltaLength。 CELPフレームは常にアクセスユニットごとに固定された持続時間を有します。このモードではインターリーブ、この特定の期間
MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
MIME形式パラメータconstantDurationによってシグナリングされなければなりません。インターリーブ場合に加えて、パラメータmaxDisplacementが存在しなければなりません。
For example:
例えば：
m=audio 49230 RTP/AVP 96 a=rtpmap:96 mpeg4-generic/16000/1 a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-vbr; config= 440F20; sizeLength=6; indexLength=2; indexDeltaLength=2; constantDuration=160; maxDisplacement=5
M =オーディオ49230 RTP / AVP 96 = rtpmap：96 MPEG4-ジェネリック/ 1分の16000 =のfmtp：96 streamtype = 5。プロファイルレベルID = 14。モード= CELP-VBR。コンフィグ= 440F20。 sizeLength = 6。 indexLength = 2。 indexDeltaLength = 2。 constantDuration = 160。 maxDisplacement = 5
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注意：A =のfmtpラインがページに収まるようにラップされています。それは、SDPファイル内の1行を含みます。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig() as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono CELP stream with a sampling rate of 16 kHz, at a bitrate that varies between 13.9 and 16.2 kb/s and with 4 sub-frames per CELP frame. For the description of MIME parameters, see section 4.1.
ISO / IEC 14496-3で定義されている「設定」パラメータの16進数の値はAudioSpecificConfig（）です。 AudioSpecificConfig（）は、13.9と16.2キロバイト/秒との間、およびCELPフレーム当たり4つのサブフレームに応じて変化するビットレートで、16キロヘルツのサンプリングレートを有するモノCELPストリームを指定します。 MIMEパラメータの説明については、4.1節を参照してください。
This mode is signaled by mode=AAC-lbr. This mode supports the transportation of one or more complete AAC frames of variable size. In this mode, the AAC frames are allowed to be interleaved and hence receivers MUST support de-interleaving. The maximum size of an AAC frame in this mode is 63 octets. AAC frames MUST NOT be fragmented when using this mode. Hence, when using this mode, encoders MUST ensure that the size of each AAC frame is at most 63 octets.
このモードは、モード= AAC-LBRによって通知されます。このモードは、可変サイズの1つまたはそれ以上の完全なAACフレームの輸送をサポートしています。このモードでは、AACフレームがインターリーブされるように許可され、したがって、受信機は、デインターリーブをサポートしなければなりません。このモードではAACフレームの最大サイズは63オクテットです。このモードを使用するときにAACフレームが断片化してはいけません。このモードを使用する場合したがって、エンコーダは、各AACフレームのサイズは、ほとんど63個のオクテットであることを保証しなければなりません。
The payload configuration in this mode is the same as in the variable bit-rate CELP mode as defined in 3.3.4. The RTP payload consists of the AU Header Section, followed by concatenated AAC frames. The Auxiliary Section MUST be empty. For each AAC frame contained in the payload, the one octet AU-header MUST provide:
このモードでは、ペイロードの構成は、3.3.4で定義されるように、可変ビットレートCELPモードと同じです。 RTPペイロードは連結AACフレームに続いて、AUヘッダセクションから構成されています。補助部は空でなければなりません。ペイロードに含まれる各AACフレームについて、1つのオクテットAU-ヘッダが指定する必要があります。
a) the size of each AAC frame in the payload and
a）は、ペイロード内の各AACフレームのサイズと
b) index information for computing the sequence (and hence timing) of each AAC frame.
各AACフレームのシーケンスを計算する（したがって、タイミングのためにB）のインデックス情報）。
In the AU-header Section, the concatenated AU-headers MUST be preceded by the 16-bit AU-headers-length field, as specified in section 3.2.1.
セクション3.2.1で指定されるようにAU-ヘッダ部分に、連結AU-ヘッダは、16ビットのAU-ヘッダ長フィールドが先行されなければなりません。
In addition to the required MIME format parameters, the following parameters MUST be present: sizeLength, indexLength, and indexDeltaLength. AAC frames always have a fixed duration per Access Unit; when interleaving in this mode, this specific duration MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
必要なMIME形式のパラメータに加えて、以下のパラメータが存在しなければならない：sizeLength、indexLength、及びindexDeltaLength。 AACフレームは常にアクセスユニットごとの固定期間を有します。このモードでインターリーブ場合、この特定期間は、MIMEフォーマットパラメータconstantDurationによってシグナリングされなければなりません。インターリーブ場合に加えて、パラメータmaxDisplacementが存在しなければなりません。
For example:
例えば：
m=audio 49230 RTP/AVP 96 a=rtpmap:96 mpeg4-generic/22050/1 a=fmtp:96 streamtype=5; profile-level-id=14; mode=AAC-lbr; config= 1388; sizeLength=6; indexLength=2; indexDeltaLength=2; constantDuration=1024; maxDisplacement=5
M =オーディオ49230 RTP / AVP 96 = rtpmap：96 MPEG4-ジェネリック/ 1分の22050 =のfmtp：96 streamtype = 5。プロファイルレベルID = 14。モード= AAC-LBR。設定= 1388; sizeLength = 6。 indexLength = 2。 indexDeltaLength = 2。 constantDuration = 1024; maxDisplacement = 5
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注意：A =のfmtpラインがページに収まるようにラップされています。それは、SDPファイル内の1行を含みます。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig(), as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a mono AAC stream with a sampling rate of 22.05 kHz. For the description of MIME parameters, see section 4.1.
ISO / IEC 14496-3で定義されている「設定」パラメータの16進数の値は、AudioSpecificConfig（）です。 AudioSpecificConfigは（）22.05キロヘルツのサンプリングレートを有するモノAACストリームを指定します。 MIMEパラメータの説明については、4.1節を参照してください。
This mode is signaled by mode=AAC-hbr. This mode supports the transportation of variable size AAC frames. In one RTP packet, either one or more complete AAC frames are carried, or a single fragment of an AAC frame is carried. In this mode, the AAC frames are allowed to be interleaved and hence receivers MUST support de-interleaving. The maximum size of an AAC frame in this mode is 8191 octets.
このモードは、モード= AAC-のHBrによって通知されます。このモードは、可変サイズのAACフレームの輸送をサポートしています。 1つのRTPパケットに、一つまたはそれ以上の完全なAACフレームが運ばれる、又はAACフレームの単一断片が行われます。このモードでは、AACフレームがインターリーブされるように許可され、したがって、受信機は、デインターリーブをサポートしなければなりません。このモードではAACフレームの最大サイズは8191オクテットです。
In this mode, the RTP payload consists of the AU Header Section, followed by either one AAC frame, several concatenated AAC frames or one fragmented AAC frame. The Auxiliary Section MUST be empty. For each AAC frame contained in the payload, there MUST be an AU-header in the AU Header Section to provide:
このモードでは、RTPペイロードはいずれかAACフレームは、いくつかの連結AACフレームまたは1つの断片化AACフレームに続いて、AUヘッダセクションから構成されています。補助部は空でなければなりません。ペイロードに含まれる各AACフレームについて、提供するAUのヘッダセクションにAU-ヘッダが存在していなければなりません。
a) the size of each AAC frame in the payload and
a）は、ペイロード内の各AACフレームのサイズと
b) index information for computing the sequence (and hence timing) of each AAC frame.
各AACフレームのシーケンスを計算する（したがって、タイミングのためにB）のインデックス情報）。
To code the maximum size of an AAC frame requires 13 bits. Therefore, in this configuration 13 bits are allocated to the AU-size, and 3 bits to the AU-Index(-delta) field. Thus, each AU-header has a size of 2 octets. Each AU-Index field MUST be coded with the value 0. In the AU Header Section, the concatenated AU-headers MUST be preceded by the 16-bit AU-headers-length field, as specified in section 3.2.1.
AACフレームの最大サイズを符号化するためには13ビットを必要とします。したがって、この構成では13ビットがAUサイズに割り当てられ、及びAU-インデックス（ - デルタ）フィールドの3ビット。したがって、各AU-ヘッダは2つのオクテットのサイズを有しています。各AU-IndexフィールドはAUヘッダセクションにおいて値0で符号化されなければならないセクション3.2.1で指定されるように、連結AU-ヘッダは、16ビットのAU-ヘッダ長フィールドが先行されなければなりません。
In addition to the required MIME format parameters, the following parameters MUST be present: sizeLength, indexLength, and indexDeltaLength. AAC frames always have a fixed duration per Access Unit; when interleaving in this mode, this specific duration MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
必要なMIME形式のパラメータに加えて、以下のパラメータが存在しなければならない：sizeLength、indexLength、及びindexDeltaLength。 AACフレームは常にアクセスユニットごとの固定期間を有します。このモードでインターリーブ場合、この特定期間は、MIMEフォーマットパラメータconstantDurationによってシグナリングされなければなりません。インターリーブ場合に加えて、パラメータmaxDisplacementが存在しなければなりません。
For example:
例えば：
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/6
a=fmtp:96 streamtype=5; profile-level-id=16; mode=AAC-hbr;
config=11B0; sizeLength=13; indexLength=3;
indexDeltaLength=3; constantDuration=1024
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注意：A =のfmtpラインがページに収まるようにラップされています。それは、SDPファイル内の1行を含みます。
The hexadecimal value of the "config" parameter is the AudioSpecificConfig(), as defined in ISO/IEC 14496-3. AudioSpecificConfig() specifies a 5.1 channel AAC stream with a sampling rate of 48 kHz. For the description of MIME parameters, see section 4.1.
ISO / IEC 14496-3で定義されている「設定」パラメータの16進数の値は、AudioSpecificConfig（）です。 AudioSpecificConfig（）は、48 kHzのサンプリングレートと5.1チャンネルAACストリームを指定します。 MIMEパラメータの説明については、4.1節を参照してください。
This specification only defines the modes specified in sections 3.3.2 through 3.3.6. Additional modes are expected to be defined in future RFCs. Each additional mode MUST be in full compliance with this specification.
この仕様は、セクション3.3.6を介して3.3.2で指定されたモードを定義します。追加のモードが、将来のRFCで定義されることが期待されます。各追加モードでは、この仕様に完全に準拠していなければなりません。
Any new mode MUST be defined such that an implementation including all the features of this specification can decode the payload format corresponding to this new mode. For this reason, a mode MUST NOT specify new default values for MIME parameters. In particular, MIME parameters that configure the RTP payload MUST be present (unless they have the default value), even if its presence is redundant in case the mode assigns a fixed value to a parameter. A mode may additionally define that some MIME parameters are required instead of optional, that some MIME parameters have fixed values (or ranges), and that there are rules restricting its usage.
任意の新しいモードは、本明細書のすべての特徴を含む実装では、この新しいモードに対応するペイロード・フォーマットを復号することができるように定義されなければなりません。このため、モードは、MIMEパラメータの新しいデフォルト値を指定してはなりません。 （これらはデフォルト値を持っていない限り）、特に、RTPペイロードを構成するMIMEパラメータは、モードパラメータに固定値を割り当てる場合には、その存在が冗長であっても、存在しなければなりません。モードは、さらにいくつかのMIMEパラメータがいくつかのMIMEパラメータが値（または範囲）を固定し、その使用を制限するルールがあることをしていること、代わりに任意の必要とされることを定義することができます。
This section describes the MIME types and names associated with this payload format. Section 4.1 registers the MIME types, as per RFC 2048 [3].
このセクションでは、このペイロード形式に関連付けられているMIMEタイプと名前を示します。セクション4.1は、RFC 2048に従って、MIMEタイプを登録する[3]。
This format may require additional information about the mapping to be made available to the receiver. This is done using parameters described in the next section.
このフォーマットは、受信機に利用できるようにマッピングに関する追加情報を必要とするかもしれません。これは次のセクションで説明したパラメータを使用して行われます。
MIME media type name: "video" or "audio" or "application"
MIMEメディアタイプ名：「ビデオ」または「オーディオ」または「アプリケーション」
"video" MUST be used for MPEG-4 Visual streams (ISO/IEC 14496-2) or MPEG-4 Systems streams (ISO/IEC 14496-1) that convey information needed for an audio/visual presentation.
"ビデオ" は、オーディオ/ビジュアルプレゼンテーションに必要な情報を伝えるMPEG-4ビジュアルストリーム（ISO / IEC 14496-2）またはMPEG-4システムストリーム（ISO / IEC 14496-1）のために使用されなければなりません。
"audio" MUST be used for MPEG-4 Audio streams (ISO/IEC 14496-3) or MPEG-4 Systems streams that convey information needed for an audio only presentation.
「オーディオ」は、MPEG-4オーディオストリーム（ISO / IEC 14496-3）又はオーディオのみのプレゼンテーションのために必要な情報を伝達MPEG-4システム・ストリームのために使用されなければなりません。
"application" MUST be used for MPEG-4 Systems streams (ISO/IEC 14496-1) that serve purposes other than audio/visual presentation, e.g., in some cases when MPEG-J (Java) streams are transmitted.
MPEG-J（Java）のストリームが送信される場合、「アプリケーション」とは、いくつかのケースでは、例えば、オーディオ/ビジュアルプレゼンテーション以外の目的を果たすMPEG-4システムストリーム（ISO / IEC 14496-1）のために使用されなければなりません。
Depending on the required payload configuration, MIME format parameters may need to be available to the receiver. This is done using the parameters described in the next section. There are required and optional parameters.
必要なペイロードの構成に応じて、MIME形式のパラメータは、受信機に利用可能である必要があるかもしれません。これは次のセクションで説明したパラメータを使用して行われます。必須およびオプションのパラメータがあります。
Optional parameters are of two types: general parameters and configuration parameters. The configuration parameters are used to configure the fields in the AU Header section and in the auxiliary section. The absence of any configuration parameter is equivalent to the associated field set to its default value, which is always zero. The absence of all configuration parameters results in a default "basic" configuration with an empty AU-header section and an empty auxiliary section in each RTP packet.
一般的なパラメータと設定パラメータ：オプションのパラメータは2つのタイプがあります。構成パラメータは、AUヘッダセクションおよび補助セクションのフィールドを設定するために使用されます。任意の構成パラメータが存在しない場合は常にゼロであり、そのデフォルト値に設定関連するフィールドに相当します。すべての設定パラメータが存在しない場合は、空のAU-ヘッダ部と各RTPパケットに空の補助部とデフォルトの「基本的な」構成になります。
MIME subtype name: mpeg4-generic
MIMEサブタイプ名：mpeg4-ジェネリック
Required parameters:
必須パラメータ：
MIME format parameters are not case dependent; for clarity however, both upper and lower case are used in the names of the parameters described in this specification.
MIME形式のパラメータが依存小文字されていません。明確にするためしかし、大文字と小文字の両方は、本明細書に記載のパラメータの名前に使用されています。
streamType: The integer value that indicates the type of MPEG-4 stream that is carried; its coding corresponds to the values of the streamType, as defined in Table 9 (streamType Values) in ISO/IEC 14496-1.
streamType：運ばれるMPEG-4ストリームのタイプを示す整数値。 ISO / IEC 14496-1の表9（streamType値）で定義され、その符号化は、streamTypeの値に相当します。
profile-level-id: A decimal representation of the MPEG-4 Profile Level indication. This parameter MUST be used in the capability exchange or session set-up procedure to indicate the MPEG-4 Profile and Level combination of which the relevant MPEG-4 media codec is capable.
プロファイルレベルID：MPEG-4プロファイル・レベル表示の10進表現。このパラメータは、関連するMPEG-4メディアコーデックが可能となっているMPEG-4プロファイルとレベルの組み合わせを示すために、能力交換、またはセッション設定手順で使用されなければなりません。
For MPEG-4 Audio streams, this parameter is the decimal value from Table 5 (audioProfileLevelIndication Values) in ISO/IEC 14496- 1, indicating which MPEG-4 Audio tool subsets are required to decode the audio stream.
MPEG-4オーディオストリームの場合、このパラメータは、MPEG-4オーディオツールのサブセットがオーディオストリームをデコードするために必要とされるかを示す、ISO / IEC 14496- 1における表5（audioProfileLevelIndication値）から10進値です。
For MPEG-4 Visual streams, this parameter is the decimal value from Table G-1 (FLC table for profile and level indication) of ISO/IEC 14496-2 [1], indicating which MPEG-4 Visual tool subsets are required to decode the visual stream.
MPEG-4映像ストリームの場合、このパラメータは、ISO / IEC 14496-2の表G-1（プロファイル及びレベル指示のためのFLCテーブル）から進値である[1]、MPEG-4ビジュアルツールのサブセットを復号するために必要とされるかを示しますビジュアルストリーム。
For BIFS streams, this parameter is the decimal value obtained from (SPLI + 256*GPLI), where: SPLI is the decimal value from Table 4 in ISO/IEC 14496-1 with the applied sceneProfileLevelIndication; GPLI is the decimal value from Table 7 in ISO/IEC 14496-1 with the applied graphicsProfileLevelIndication.
BIFSストリームの場合、このパラメータは（SPLI + 256 * GPLI）から得られた進値である：SPLIが適用sceneProfileLevelIndicationとISO / IEC 14496-1表4から10進値です。 GPLI適用graphicsProfileLevelIndicationとISO / IEC 14496-1表7から進値です。
For MPEG-J streams, this parameter is the decimal value from table 13 (MPEGJProfileLevelIndication) in ISO/IEC 14496-1, indicating the profile and level of the MPEG-J stream.
MPEG-Jストリームの場合、このパラメータは、MPEG-Jストリームのプロファイルとレベルを示す、ISO / IEC 14496-1の表13（MPEGJProfileLevelIndication）から進値です。
For OD streams, this parameter is the decimal value from table 3 (ODProfileLevelIndication) in ISO/IEC 14496-1, indicating the profile and level of the OD stream.
ODストリームの場合、このパラメータは、ODストリームのプロファイルとレベルを示す、ISO / IEC 14496-1の表3（ODProfileLevelIndication）から進値です。
For IPMP streams, this parameter has either the decimal value 0, indicating an unspecified profile and level, or a value larger than zero, indicating an MPEG-4 IPMP profile and level as defined in a future MPEG-4 specification.
IPMPストリームの場合、このパラメータは、将来のMPEG-4仕様で定義されているMPEG-4 IPMPプロファイルとレベルを示す不特定のプロファイル及びレベル、またはゼロよりも大きい値を示し、十進値0のいずれかを有しています。
For Clock Reference streams and Object Content Info streams, this parameter has the decimal value zero, indicating that profile and level information is conveyed through the OD framework.
クロック・リファレンスストリーム及び情報ストリームコンテンツオブジェクトの場合、このパラメータは、プロファイル及びレベル情報はODフレームワークを搬送されることを示す、十進値ゼロを有します。
config: A hexadecimal representation of an octet string that expresses the media payload configuration. Configuration data is mapped onto the hexadecimal octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, if necessary to achieve octet-alignment, up to 7 zero-valued padding bits shall follow the configuration data.
設定：メディアペイロードの構成を表すオクテット文字列の16進表現。構成データは、MSB-1番目の基底における進数のオクテット列にマッピングされます。コンフィギュレーション・データの最初のビットは、最初のオクテットのMSBに配置さSHALL。最後のオクテットで、オクテット整列を達成するために必要に応じて、7ゼロ値パディングビットまでのコンフィギュレーションデータに従わなければなりません。
For MPEG-4 Audio streams, config is the audio object type specific decoder configuration data AudioSpecificConfig(), as defined in ISO/IEC 14496-3. For Structured Audio, the AudioSpecificConfig() may be conveyed by other means, not defined by this specification. If the AudioSpecificConfig() is conveyed by other means for Structured Audio, then the config MUST be a quoted empty hexadecimal octet string, as follows: config="".
ISO / IEC 14496-3で定義されているMPEG-4オーディオストリームのために、設定は、）オーディオオブジェクトタイプ固有のデコーダの構成データAudioSpecificConfig（あります。構造化オーディオため、AudioSpecificConfig（）この仕様で定義されていない、他の手段によって搬送されてもよいです。 AudioSpecificConfig（）が構造化オーディオ用の他の手段によって搬送された場合、次のように設定は、引用空進オクテット文字列である必要があります。config =「」。
Note that a future mode of using this RTP payload format for Structured Audio may define such other means.
構造化オーディオ用このRTPペイロードフォーマットを使用して、将来のモードは、このような他の手段を定義してもよいことに留意されたいです。
For MPEG-4 Visual streams, config is the MPEG-4 Visual configuration information as defined in subclause 6.2.1, Start codes of ISO/IEC 14496-2. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first-half-vbv-occupancy and latter-half-vbv-occupancy, if it exists, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC 14496-2).
MPEG-4映像ストリームの場合、設定は箇条6.2.1で定義されているMPEG-4映像の構成情報は、ISO / IEC 14496-2のコードを開始します。に変化してもよい。このパラメータによって示される設定情報が存在する場合、第一半VBV占有と後半-VBV占有を除いて、対応するMPEG-4映像ストリームの構成情報と同じでなければなりません、 MPEG-4映像ストリーム内の繰り返し設定情報（ISO / IEC 14496-2の6.2.1スタートコードを参照）。
For BIFS streams, this is the BIFSConfig() information as defined in ISO/IEC 14496-1. Version 1 of BIFSConfig is defined in section 9.3.5.2, and version 2 is defined in section 9.3.5.3. The MIME format parameter objectType signals the version of BIFSConfig.
BIFSストリームの場合、これは、ISO / IEC 14496-1で定義されてBIFSConfig（）情報です。 BIFSConfigのバージョン1は、セクション9.3.5.2で定義され、バージョン2は、セクション9.3.5.3で定義されています。 MIME形式のパラメータのobjectTypeはBIFSConfigのバージョンを知らせます。
For IPMP streams, this is either a quoted empty hexadecimal octet string, indicating the absence of any decoder configuration information (config=""), or the IPMPConfiguration() as will be defined in a future MPEG-4 IPMP specification.
IPMPストリームの場合、これは将来のMPEG-4 IPMP仕様で定義されるように）、任意のデコーダ設定情報（設定=「」）が存在しないことを示す引用空進オクテットストリング、またはIPMPConfiguration（いずれかです。
For Object Content Info (OCI) streams, this is the OCIDecoderConfiguration() information of the OCI stream, as defined in section 8.4.2.4 in ISO/IEC 14496-1.
ISO / IEC 14496-1でセクション8.4.2.4で定義されている情報（OCI）はストリームオブジェクトの内容については、これは、OCIストリームのOCIDecoderConfiguration（）の情報です。
For OD streams, Clock Reference streams and MPEG-J streams, this is a quoted empty hexadecimal octet string (config=""), as no information on the decoder configuration is required.
ODストリームのために、クロック・リファレンスストリームとMPEG-Jストリームデコーダの構成についての情報が必要とされないように、これは、引用符で囲まれた空進オクテットストリング（設定=「」）です。
mode: The mode in which this specification is used. The following modes can be signaled:
モード：この仕様書が使用されているモード。次のモードが合図することができます。
mode=generic, mode=CELP-cbr, mode=CELP-vbr, mode=AAC-lbr and mode=AAC-hbr.
モード=ジェネリック、モード= CELP-CBR、モード= CELP-VBR、モード= AAC-LBRとモード= AAC-HBrを。
Other modes are expected to be defined in future RFCs. See also section 3.3.7 and 4.2 of RFC 3640.
他のモードは、将来のRFCで定義されることが期待されます。 RFC 3640のセクション3.3.7と4.2をも参照してください。
Optional general parameters:
オプションの一般的なパラメータ：
objectType: The decimal value from Table 8 in ISO/IEC 14496-1, indicating the value of the objectTypeIndication of the transported stream. For BIFS streams, this parameter MUST be present to signal the version of BIFSConfiguration(). Note that objectTypeIndication may signal a non-MPEG-4 stream and that the RTP payload format defined in this document may not be suitable for carrying a stream that is not defined by MPEG-4. The objectType parameter SHOULD NOT be set to a value that signals a stream that cannot be carried by this payload format.
objectTypeに：ISO / IEC 14496-1表8から小数値、搬送ストリームのobjectTypeIndicationの値を示します。 BIFSストリームのために、このパラメータはBIFSConfigurationのバージョンをシグナリングするために存在する必要があります（）。 objectTypeIndication非MPEG-4ストリームをシグナリングすることができること、および本文書で定義されたRTPペイロードフォーマットはMPEG-4で定義されていないストリームを搬送するのに適しないかもしれないことに留意されたいです。 objectTypeにパラメーターは、このペイロード形式により実施することができないストリームを信号の値に設定しないでください。
constantSize: The constant size in octets of each Access Unit for this stream. The constantSize and the sizeLength parameters MUST NOT be simultaneously present.
constantSize：このストリームの各アクセスユニットのオクテットで一定のサイズ。 constantSizeとsizeLengthパラメータが同時に存在してはなりません。
constantDuration: The constant duration of each Access Unit for this stream, measured with the same units as the RTP time stamp.
constantDuration：RTPタイムスタンプと同じ単位で測定し、このストリームのための各アクセスユニットの一定期間、。
maxDisplacement: The decimal representation of the maximum displacement in time of an interleaved AU, as defined in section 3.2.3.3, expressed in units of the RTP time stamp clock.
maxDisplacement：インターリーブAUの時間における最大変位の10進表現、セクション3.2.3.3で定義されるように、RTPタイムスタンプクロックの単位で表されます。
This parameter MUST be present when interleaving is applied.
インターリービングが適用されるとき、このパラメータが存在しなければなりません。
de-interleaveBufferSize: The decimal representation in number of octets of the size of the de-interleave buffer, described in section 3.2.3.3. When interleaving, this parameter MUST be present if the calculation of the de-interleave buffer size given in 3.2.3.3 and based on maxDisplacement and rate(max) under-estimates the size of the de-interleave buffer. If this calculation does not under-estimate the size of the de-interleave buffer, then the de-interleaveBufferSize parameter SHOULD NOT be present.
デinterleaveBufferSize：セクション3.2.3.3に記載のデインタリーブバッファのサイズのオクテット数の10進表現。インターリーブ場合、このパラメータが存在しなければならない場合、デインタリーブバッファのサイズ推定下デインターリーブバッファサイズ3.2.3.3に与えられ、maxDisplacementと速度（MAX）に基づいての計算。この計算は、デインタリーブバッファのサイズを過小推定していない場合は、デinterleaveBufferSizeパラメータが存在してはなりません。
Optional configuration parameters:
オプションの設定パラメータ：
sizeLength: The number of bits on which the AU-size field is encoded in the AU-header. The sizeLength and the constantSize parameters MUST NOT be simultaneously present.
sizeLength：AUサイズフィールドはAU-ヘッダで符号化されたビットの数。 sizeLengthとconstantSizeパラメータが同時に存在してはなりません。
indexLength: The number of bits on which the AU-Index is encoded in the first AU-header. The default value of zero indicates the absence of the AU-Index field in each first AU-header.
indexLength：AU-インデックス第AU-ヘッダで符号化されたビットの数。ゼロのデフォルト値は、各第AU-ヘッダにおけるAU-Indexフィールドが存在しないことを示しています。
indexDeltaLength: The number of bits on which the AU-Index-delta field is encoded in any non-first AU-header. The default value of zero indicates the absence of the AU-Index-delta field in each non-first AU-header.
indexDeltaLength：AU-インデックスデルタフィールドは、任意の非最初のAU-ヘッダで符号化されたビットの数。ゼロのデフォルト値は、各非最初のAU-ヘッダにおけるAU-インデックスデルタフィールドが存在しないことを示しています。
CTSDeltaLength: The number of bits on which the CTS-delta field is encoded in the AU-header.
CTSDeltaLength：CTSデルタフィールドはAU-ヘッダで符号化されたビットの数。
DTSDeltaLength: The number of bits on which the DTS-delta field is encoded in the AU-header.
DTSDeltaLength：DTSデルタフィールドはAU-ヘッダで符号化されたビットの数。
randomAccessIndication: A decimal value of zero or one, indicating whether the RAP-flag is present in the AU-header. The decimal value of one indicates presence of the RAP-flag, the default value zero indicates its absence.
randomAccessIndication：ゼロまたは1つの10進値、RAP-フラグはAU-ヘッダ内に存在するかどうかを示します。一方の小数点値は、デフォルト値ゼロが存在しないことを示し、RAPフラグの存在を示します。
streamStateIndication: The number of bits on which the Stream-state field is encoded in the AU-header. This parameter MAY be present when transporting MPEG-4 system streams, and SHALL NOT be present for MPEG-4 audio and MPEG-4 video streams.
streamStateIndication：ストリーム状態フィールドはAU-ヘッダで符号化されたビットの数。このパラメータは、MPEG-4システムストリームを転送するときに存在していてもよく、およびMPEG-4オーディオおよびMPEG-4ビデオストリームのために存在してはなりません。
auxiliaryDataSizeLength: The number of bits that is used to encode the auxiliary-data-size field.
auxiliaryDataSizeLength：補助データ・サイズ・フィールドを符号化するために使用されるビットの数。
Applications MAY use more parameters, in addition to those defined above. Each additional parameter MUST be registered with IANA to ensure that there is not a clash of names. Each additional parameter MUST be accompanied by a specification in the form of an RFC, MPEG standard, or other permanent and readily available reference (the "Specification Required" policy defined in RFC 2434 [6]). Receivers MUST tolerate the presence of such additional parameters, but these parameters SHALL NOT impact the decoding of receivers that comply with this specification.
アプリケーションは、上記で定義されたものに加えて、より多くのパラメータを使用するかもしれません。各追加のパラメータは、名前の衝突がないことを保証するために、IANAに登録しなければなりません。各追加のパラメータは、RFC、MPEG規格、または他の永久的かつ容易に利用可能な参照の形で指定を伴わなければならない（RFC 2434で定義された「仕様が必要で」ポリシー[6]）。受信機は、このような追加のパラメータが存在することを許容しなければならないが、これらのパラメータは、この仕様に準拠する受信機の復号化に影響を与えないもの。
Encoding considerations: This MIME subtype is defined for RTP transport only. System bitstreams MUST be generated according to MPEG-4 Systems specifications (ISO/IEC 14496-1). Video bitstreams MUST be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). Audio bitstreams MUST be generated according to MPEG-4 Audio specifications (ISO/IEC 14496-3). The RTP packets MUST be packetized according to the RTP payload format defined in RFC 3640.
エンコードの考慮事項：このMIMEサブタイプのみRTP輸送のために定義されています。システムビットストリームは、MPEG-4システム規格（ISO / IEC 14496-1）に従って生成されなければなりません。ビデオビットストリームは、MPEG-4ビジュアル規格（ISO / IEC 14496-2）に従って生成されなければなりません。オーディオビットストリームは、MPEG-4オーディオ規格（ISO / IEC 14496-3）に従って生成されなければなりません。 RTPパケットは、RFC 3640で定義されたRTPペイロードフォーマットに従ってパケット化されなければなりません。
Security considerations: As defined in section 5 of RFC 3640.
セキュリティの考慮事項：RFC 3640のセクション5で定義されているように。
Interoperability considerations: MPEG-4 provides a large and rich set of tools for the coding of visual objects. For effective implementation of the standard, subsets of the MPEG-4 tool sets have been provided for use in specific applications. These subsets, called 'Profiles', limit the size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more 'Levels' are set for each Profile. A Profile@Level combination allows:
相互運用性に関する注意事項：MPEG-4ビジュアルオブジェクトの符号化のためのツールの大規模かつ豊富なセットを提供します。標準の効果的な実施のために、MPEG-4ツールセットのサブセットは、特定の用途での使用のために提供されています。 「プロファイル」と呼ばれるこれらのサブセットは、デコーダを実装するのに必要とされるツールセットのサイズを制限します。計算の複雑さを制限するためには、一つ以上の「レベルは」プロファイルごとに設定されています。プロファイル@レベルの組み合わせができます。
. a codec builder to implement only the subset of the standard
he needs, while maintaining interworking with other MPEG-4
devices that implement the same combination, and
. checking whether MPEG-4 devices comply with the standard ('conformance testing').
。 MPEG-4のデバイスは、標準的な（「適合性試験」）に準拠しているかどうかチェックします。
A stream SHALL be compliant with the MPEG-4 Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver is achieved by specifying the parameter "profile-level-id" in MIME content. In the capability exchange/announcement procedure, this parameter may mutually be set to the same value.
ストリームは、パラメータ「プロファイルレベルID」で指定されたMPEG-4プロファイル@レベルに準拠しなければなりません。送信者と受信者間の相互運用性は、MIMEコンテンツのパラメータ「プロファイルレベルID」を指定することによって達成されます。能力交換/アナウンス手順では、このパラメータは、互いに同じ値に設定してもよいです。
Published specification: The specifications for MPEG-4 streams are presented in ISO/IEC 14496-1, 14496-2, and 14496-3. The RTP payload format is described in RFC 3640.
公開された仕様：MPEG-4ストリームの仕様は、ISO / IEC 14496-1、14496-2および14496-3に示されています。 RTPペイロードフォーマットは、RFC 3640に記載されています。
Applications which use this media type: Multimedia streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：マルチメディアストリーミングおよび会議ツール。
Additional information: none
追加情報：なし
Magic number(s): none
マジックナンバー（S）：なし
File extension(s): None. A file format with the extension .mp4 has been defined for MPEG-4 content but is not directly correlated with this MIME type for which the sole purpose is RTP transport.
ファイルの拡張子（秒）：なし。拡張子のMP4のファイルフォーマットはMPEG-4コンテンツのために定義されているが、直接唯一の目的は、RTPトランスポートされたこのMIMEタイプと相関していません。
Macintosh File Type Code(s): none
Macintoshのファイルタイプコード（S）：なし
Person & email address to contact for further information: Authors of RFC 3640, IETF Audio/Video Transport working group.
人と詳細のために連絡する電子メールアドレス：RFC 3640の作者、IETFオーディオ/ビデオ輸送ワーキンググループ。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Authors of RFC 3640, IETF Audio/Video Transport working group.
著者/変更コントローラ：RFC 3640の作者、IETFオーディオ/ビデオ輸送ワーキンググループ。
This specification can be used in a number of modes. The mode of operation is signaled using the "mode" MIME parameter, with the initial set of values specified in section 4.1. New modes may be defined at any time, as described in section 3.3.7. These modes MUST be registered with IANA, to ensure that there is not a clash of names.
この仕様は、いくつかのモードで使用することができます。動作のモードは、セクション4.1で指定された値の初期セットと、「モード」MIMEパラメータを使用してシグナリングされます。セクション3.3.7に記載したように、新たなモードは、いつでも定義することができます。これらのモードは、名前の衝突がないことを確認するために、IANAに登録しなければなりません。
A new mode registration MUST be accompanied by a specification in the form of an RFC, MPEG standard, or other permanent and readily available reference (the "Specification Required" policy defined in RFC 2434 [6]).
新しいモード登録RFCの形で指定を伴わなければならない、MPEG規格、または他の永久的かつ容易に利用可能な基準（RFC 2434で定義された「仕様が必要で」ポリシー[6]）。
Multiple parameters SHOULD be expressed as a MIME media type string, in the form of a semicolon-separated list of parameter=value pairs (for parameter usage examples see sections 3.3.2 up to 3.3.6).
複数のパラメータのパラメータのセミコロンで区切られたリストの形式で、MIMEメディアタイプ文字列として表現されてください=値ペア（パラメータの使用例については、3.3.6までのセクション3.3.2を参照します）。
It is assumed that one typical way to transport the above-described parameters associated with this payload format is via an SDP message [5] for example transported to the client in reply to an RTSP DESCRIBE [8] or via SAP [11]. In that case, the (a=fmtp) keyword MUST be used as described in RFC 2327 [5], section 6, the syntax then being:
[11] [8]またはSAPを介しDESCRIBE [5]例えばRTSPに対する応答としてクライアントに搬送このペイロードフォーマットに関連付けられた上記パラメータを搬送する一つの典型的な方法は、SDPメッセージを介してであることが想定されます。その場合にはRFC 2327に記載されているように、（A =のfmtp）キーワードが使用されなければならない[5]、セクション6、構文次にです。
a=fmtp:<format> <parameter name>=<value>[; <parameter name>=<value>]
=のfmtp：<フォーマット> <パラメータ名> = <値>。 <パラメータ名> = <値>]
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [2]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data so there is no conflict between the two operations. The packet processing complexity of this payload type (i.e., excluding media data processing) does not exhibit any significant non-uniformity in the receiver side to cause a denial-of-service threat.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[2]で説明したセキュリティ上の考慮の対象となっています。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。このペイロードフォーマットに使用されるデータ圧縮は、エンドツーエンド印加されるので、二つの操作の間に競合がないので、暗号化は、圧縮されたデータに対して実行することができます。 （すなわち、メディアデータの処理を除く）、このペイロードタイプのパケット処理の複雑さは、サービス拒否の脅威を引き起こすために、受信機側で有意な不均一性を示しません。
However, it is possible to inject non-compliant MPEG streams (Audio, Video, and Systems) so that the receiver/decoder's buffers are overloaded, which might compromise the functionality of the receiver or even crash it. This is especially true for end-to-end systems like MPEG, where the buffer models are precisely defined.
しかし、受信機の機能を損なう、あるいはそれをクラッシュする可能性がありますされ、受信機/デコーダのバッファがオーバーロードされるように非対応のMPEGストリーム（オーディオ、ビデオ、およびシステム）を注入することができます。これは、バッファ・モデルが正確に定義されているMPEGなどのエンドツーエンドシステムに特に当てはまります。
MPEG-4 Systems support stream types including commands that are executed on the terminal, like OD commands, BIFS commands, etc. and programmatic content like MPEG-J (Java(TM) Byte Code) and MPEG-4 scripts. It is possible to use one or more of the above in a manner non-compliant to MPEG to crash the receiver or make it temporarily unavailable. Senders that transport MPEG-4 content SHOULD ensure that such content is MPEG compliant, as defined in the compliance part of IEC/ISO 14496 [1]. Receivers that support MPEG-4 content should prevent malfunctioning of the receiver in case of non MPEG compliant content.
ODコマンド、BIFSコマンド、等とMPEG-J（Java（登録商標）バイトコード）のようなプログラムコンテンツ及びMPEG-4スクリプトのような端末上で実行されるコマンドを含む、MPEG-4システムサポートストリームタイプ。受信機をクラッシュしたり、それが一時的に使用不可にするためにMPEGに準拠していない方法で、上記の一つ以上を使用することが可能です。輸送MPEG-4コンテンツは、そのようなコンテンツを確保すべきであることを送信者は、IEC / ISO 14496のコンプライアンス部に定義されているように、MPEGに準拠している[1]。 MPEG-4コンテンツをサポートする受信機は、非MPEG準拠のコンテンツの場合には、受信機の誤動作を防止するべきです。
Authentication mechanisms can be used to validate the sender and the data to prevent security problems due to non-compliant malignant MPEG-4 streams.
認証メカニズムは、送信者と非対応悪性のMPEG-4ストリームに起因するセキュリティ上の問題を防止するためにデータを検証するために使用することができます。
In ISO/IEC 14496-1, a security model is defined for MPEG-4 Systems streams carrying MPEG-J access units that comprise Java(TM) classes and objects. MPEG-J defines a set of Java APIs and a secure execution model. MPEG-J content can call this set of APIs and Java(TM) methods from a set of Java packages supported in the receiver within the defined security model. According to this security model, downloaded byte code is forbidden to load libraries, define native methods, start programs, read or write files, or read system properties. Receivers can implement intelligent filters to validate the buffer requirements or parametric (OD, BIFS, etc.) or programmatic (MPEG-J, MPEG-4 scripts) commands in the streams. However, this can increase the complexity significantly.
ISO / IEC 14496-1では、セキュリティモデルは、Java（TM）クラスとオブジェクトを含むMPEG-Jアクセスユニットを運ぶMPEG-4システムストリームのために定義されています。 MPEG-Jは、Java APIおよびセキュアな実行モデルのセットを定義します。 MPEG-Jコンテンツは、このAPIのセットと定義されたセキュリティモデル内の受信機でサポートされているJavaパッケージのセットからのJava（TM）メソッドを呼び出すことができます。このセキュリティモデルによれば、ダウンロードされたバイトコードは、ライブラリをロードするネイティブメソッドを定義し、プログラムを起動し、ファイルの読み書き、またはシステムプロパティを読み取ることが禁じられています。受信機はバッファ要件またはパラメトリック（OD、BIFSなど）またはプログラム（MPEG-J、MPEG-4スクリプト）ストリーム内のコマンドを検証するインテリジェントフィルタを実装することができます。しかし、これはかなり複雑さを増すことができます。
Implementors of MPEG-4 streaming over RTP who also implement MPEG-4 scripts (subset of ECMAScript) MUST ensure that the action of such scripts is limited solely to the domain of the single presentation in which they reside (thus disallowing session to session communication, access to local resources and storage, etc). Though loading static network-located resources (such as media) into the presentation should be permitted, network access by scripts MUST be restricted to such a (media) download.
また、MPEG-4スクリプト（ECMAスクリプトのサブセット）を実装RTPオーバーMPEG-4ストリーミングの実装は、そのようなスクリプトの動作は、このようにセッションに通信セッションを許可しない（単にそれらが存在する単一のプレゼンテーションのドメインに限定されることを保証しなければなりませんローカルリソースやストレージへのアクセスなど）。プレゼンテーションに（そのような媒体など）静的なネットワーク-位置リソースをロードすることは、スクリプトによるネットワークアクセスを許可する必要がありますが、そのような（メディア）のダウンロードに制限されなければなりません。
This document evolved into RFC 3640 after several revisions. Thanks to contributions from people in the ISMA forum, the IETF AVT Working Group and the 4-on-IP ad-hoc group within MPEG. The authors wish to thank all people involved, particularly Andrea Basso, Stephen Casner, M. Reha Civanlar, Carsten Herpel, John Lazaro, Zvi Lifshitz, Young-kwon Lim, Alex MacAulay, Bill May, Colin Perkins, Dorairaj V and Stephan Wenger for their valuable comments and support.
この文書では、いくつかの改正後RFC 3640へと進化しました。 ISMAフォーラムの人々からの貢献のおかげで、IETF AVT作業部会及びMPEG内で4オンIPアドホックグループ。著者は、関係するすべての人々、特にアンドレア・バッソ、スティーブンCasner、M.レハCivanlar、カールステンHerpel、ジョン・ラザロ、のZviリフシッツ、ヤング・クォン・リム、アレックス・マコーレー、ビル・メイ、コリンパーキンス、Dorairaj Vとステファン・ベンゲル監督に感謝したいです彼らの貴重なコメントとサポート。
APPENDIX: Usage of this Payload Format
付録：このペイロードフォーマットの使用方法
Appendix A. Interleave Analysis
付録A.インターリーブ分析
A. Examples of Delay Analysis with Interleave
インターリーブと遅延解析のA.例
A.1. Introduction
A.1。前書き
Interleaving issues are discussed in this appendix. Some general notes are provided on de-interleaving and error concealment, while a number of interleaving patterns are examined, in particular for determining the size of the de-interleave buffer and the maximum displacement of access units in time. In these examples, the maximum displacement is cited in terms of an access unit count, for ease of reading. In actual streams, it is signaled in units of the RTP time stamp clock.
インターリーブの問題は、この付録で説明されています。インターリーブパターンの数を調べている間、いくつかの一般的なノートは、デインターリーブバッファのサイズと時間でアクセスユニットの最大変位を決定するために、特に、デインターリーブおよびエラー隠蔽に設けられています。これらの例では、最大変位は、読みやすくするために、アクセスユニットカウントの観点に引用されています。実際のストリームでは、RTPタイムスタンプクロックの単位でシグナリングされます。
A.2. De-interleaving and Error Concealment
A.2。デインターリーブとエラー隠蔽
This appendix does not describe any details on de-interleaving and error concealment, as the control of the AU decoding and error concealment process has little to do with interleaving. If the next AU to be decoded is present and there is sufficient storage available for the decoded AU, then decode it immediately. If not, wait. When the decoding deadline is reached (i.e., the time when decoding must begin in order to be completed by the time the AU is to be presented), or if the decoder is some hardware that presents a constant delay between initiation of decoding of an AU and presentation of that AU, then decoding must begin at that deadline time.
AUのデコードとエラー隠蔽プロセスの制御はインターリーブとはほとんどを持っているとして、この付録では、デインターリーブとエラー隠蔽上の任意の詳細を説明していません。デコードされる次のAUが存在し、復号されたAUのために利用可能な十分なストレージがある場合は、すぐにそれをデコードします。ない場合は、待ちます。復号期限に達したとき（すなわち、順に開始しなければならないデコード時間は、AUが提示されるべき時間によって完成される）、またはデコーダは、AUの復号化の開始の間に一定の遅延を示し、いくつかのハードウェアがある場合そのAUの提示は、その後、復号化は、その期限の時点で開始しなければなりません。
If the next AU to be decoded is not present when the decoding deadline is reached, then that AU is lost so the receiver must take whatever error concealment measures are deemed appropriate. The play-out delay may need to be adjusted at that point (especially if other AUs have also missed their deadline recently). Or, if it was a momentary delay, and maintaining the latency is important, then the receiver should minimize the glitch and continue processing with the next AU.
デコード期限に達したときに復号される次のAUが存在しない場合は、AUがこのように失われたことを受信機には、隠蔽対策が適切であると考えているものは何でもエラー取る必要があります。プレイアウト遅延は、（他のAUも最近、期限を逃した場合は特に）、その時点で調整する必要があります。それは瞬間的な遅延で、レイテンシーを維持することが重要である場合や、受信機はグリッチを最小限にし、次のAUで処理を継続すべきです。
A.3. Simple Group Interleave
A.3。シンプルなグループインターリーブ
A.3.1. Introduction
A.3.1。前書き
An example of regular interleave is when packets are formed into groups. If the 'stride' of the interleave (the distance between interleaved AUs) is N, packet 0 could contain AU(0), AU(N), AU(2N), and so on; packet 1 could contain AU(1), AU(1+N), AU(1+2N), and so on. If there are M access units in a packet, then there are M*N access units in the group.
パケットがグループに形成されている場合、正規インターリーブの一例です。インターリーブの 'ストライド'（インターリーブのAUとの間の距離）がNである場合、パケット0はそう上のAu（0）、AU（N）、AU（2N）とを含むことができます。パケット1は、その上のAU（1）、AU（1 + N）、AU（1 + 2N）、などを含めることができます。 Mアクセスユニットがパケットである場合には、M×N個のアクセスユニットは、グループ内にあります。
An example with N=M=3 follows; note that this is the same example as given in section 2.5 and that a fixed time duration per Access Unit is assumed:
N = M = 3以下と例。セクション2.5およびアクセス単位当たりの固定された持続時間が想定されることを考えると、これは同じ例であることに注意。
Packet Time stamp Carried AUs AU-Index, AU-Index-delta P(0) T[0] 0, 3, 6 0, 2, 2 P(1) T[1] 1, 4, 7 0, 2, 2 P(2) T[2] 2, 5, 8 0, 2, 2 P(3) T[9] 9,12,15 0, 2, 2
パケットタイムスタンプのAU AU-インデックスを搭載AU-索引デルタP（0）T [0] 0、3、6 0、2、2 P（1）T [1]は1、4、7 0、2、2 P（2）T [2] 2、5、8 0、2、2 P（3）T [9] 9,12,15 0、2、2
In this example, the AU-Index is present in the first AU-header and coded with the value 0, as required for fixed duration AUs. The position of the first AU of each packet within the group is defined by the RTP time stamp, while the AU-Index-delta field indicates the position of subsequent AUs relative to the first AU in the packet. All AU-Index-delta fields are coded with the value N-1, equal to 2 in this example. Hence the RTP time stamp and the AU-Index-delta are used to reconstruct the original order. See also section 3.2.3.2.
固定期間のAUのために必要なように、この例では、AU-指数は、第AU-ヘッダに存在し、値0で符号化されます。 AU-インデックスデルタフィールドは、パケット内の最初のAUの後のAUの位置を示しているグループ内の各パケットの最初のAUの位置は、RTPタイムスタンプによって規定されます。全てAU-インデックスデルタフィールドは、この例では2に等しい値N-1で符号化されます。したがって、RTPタイムスタンプとAU-インデックス・デルタは、元の順序を再構築するために使用されています。また、セクション3.2.3.2を参照してください。
A.3.2. Determining the De-interleave Buffer Size
A.3.2。デ・インタリーブバッファサイズを決定します
For the regular pattern as in this example, Figure 6 in section 3.2.3.3 shows that the de-interleave buffer stores at most 4 AUs. A de-interleaveBufferSize value that is at least equal to the total number of octets of any 4 "early" AUs that are stored at the same time may be signaled.
この例のように規則的なパターンのために、セクション3.2.3.3にある図6は、デインターリーブバッファ店で最も4つのAUことを示しています。任意の4オクテットの総数に少なくとも等しいデinterleaveBufferSize値が「早期」に同時に格納されるのAUをシグナリングすることができます。
A.3.3. Determining the Maximum Displacement
A.3.3。最大変位を求めます
For the regular pattern as in this example, Figure 7 in section 3.3 shows that the maximum displacement in time equals 5 AU periods. Hence, the minimum maxDisplacement value that must be signaled is 5 AU periods. In case each AU has the same size, this maxDisplacement value over-estimates the de-interleave buffer size with one AU. However, note that in case of variable AU sizes, the total size of any 4 "early" AUs that must be stored at the same time may exceed maxDisplacement times the maximum bitrate, in which case the de-interleaveBufferSize must be signaled.
この例のように規則的なパターンのために、セクション3.3で図7は、時間の最大変位は5 AU期間に等しいことを示しています。したがって、シグナリングされなければならない最小maxDisplacement値が5つのAU期間です。ケースでは、各AUは、過剰見積もりこのmaxDisplacement値1 AUとデインタリーブバッファサイズを同じサイズを有します。しかしながら、可変AUサイズの場合には、任意の4の合計サイズが「早い」を同時に格納されなければならないのAUがmaxDisplacement時間デinterleaveBufferSizeがシグナリングされなければならない場合には、最大ビットレートを超えてもよいことに留意されたいです。
A.4. More Subtle Group Interleave
A.4。より微妙なグループインターリーブ
A.4.1. Introduction
A.4.1。前書き
Another example of forming packets with group interleave is given below. In this example, the packets are formed such that the loss of two subsequent RTP packets does not cause the loss of two subsequent AUs. Note that in this example, the RTP time stamps of packet 3 and packet 4 are earlier than the RTP time stamps of packets 1 and 2, respectively; a fixed time duration per Access Unit is assumed.
グループインターリーブを持つパケットを形成する他の例を以下に示します。この例では、パケットが二つの連続するRTPパケットの損失は、2つの後続のAUの損失を生じないように形成されています。この例では、パケット3、パケット4のRTPタイムスタンプは、それぞれのパケット1及び2のRTPタイムスタンプより前であることに留意されたいです。アクセスユニットあたりの固定持続時間が想定されます。
Packet Time stamp Carried AUs AU-Index, AU-Index-delta 0 T[0] 0, 5 0, 4 1 T[2] 2, 7 0, 4 2 T[4] 4, 9 0, 4 3 T[1] 1, 6 0, 4 4 T[3] 3, 8 0, 4 5 T[10] 10, 15 0, 4 and so on ..
AU AU-インデックス、AU-インデックス・デルタ0 T [0]、5 0 4 1 T [2]、7 0、4 2 T [4] 4,9 0,4 3 T [運ばパケットのタイムスタンプ1] 1、6 0 4 4 T [3] 3、8 0、4 5 T [10] 10、15 0、4等..
In this example, the AU-Index is present in the first AU-header and coded with the value 0, as required for AUs with a fixed duration. To reconstruct the original order, the RTP time stamp and the AU-Index-delta (coded with the value 4) are used. See also section 3.2.3.2.
この例では、AU-インデックスは、第AU-ヘッダに存在し、固定された期間でのAUのために必要に応じて、値0で符号化されます。元の順序を復元するために、RTPタイムスタンプと（値4でコーディング）AU-インデックスデルタが使用されます。また、セクション3.2.3.2を参照してください。
A.4.2. Determining the De-interleave Buffer Size
A.4.2。デ・インタリーブバッファサイズを決定します
From Figure 8, it can be to determined that at most 5 "early" AUs are to be stored. If the AUs are of constant size, then this value equals 5 times the AU size. The minimum size of the de-interleave buffer equals the maximum total number of octets of the "early" AUs that are to be stored at the same time. This gives the minimum value of the de-interleaveBufferSize that may be signaled.
図8から、せいぜい5は「早期」のAUが格納されることが決定にすることができます。 AUは、一定のサイズのものである場合、この値は5回AUのサイズに等しいです。デインターリーブバッファの最小サイズは、同時に格納される「初期」AUのオクテットの最大総数に等しいです。これは、シグナリングすることができるデinterleaveBufferSizeの最小値を与えます。
+--+--+--+--+--+--+--+--+--+--+ Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8| +--+--+--+--+--+--+--+--+--+--+ - - 5 - 5 - 2 7 4 9 7 4 9 5 "Early" AUs 5 6 7 7 9 9
+ - + - + - + - + - + - + - + - + - + - +インターリーブのAU | 0 | 5 | 2 | 7 | 4 | 9 | 1 | 6 | 3 | 8 | + - + - + - + - + - + - + - + - + - + - + - - 5 - - 5 2 7 4 9 7 9 5 4 "初期" のAU 5 6 7 7 9 9
Figure 8: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
図8：インターリーブされたAUあたりのデインタリーブバッファにおける「早期」のAUのストレージ。
A.4.3. Determining the Maximum Displacement
A.4.3。最大変位を求めます
From Figure 9, it can be seen that the maximum displacement in time equals 8 AU periods. Hence the minimum maxDisplacement value to be signaled is 8 AU periods.
図9から、時間の最大変位は8つのAU期間に等しいことがわかります。よってシグナリングされる最小maxDisplacement値は8つのAU期間です。
+--+--+--+--+--+--+--+--+--+--+ Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8| +--+--+--+--+--+--+--+--+--+--+
+ - + - + - + - + - + - + - + - + - + - +インターリーブのAU | 0 | 5 | 2 | 7 | 4 | 9 | 1 | 6 | 3 | 8 | + - + - + - + - + - + - + - + - + - + - +
Earliest not yet present AU - 1 1 1 1 1 - 3 - -
最早、まだ存在していないAU - 1 1 1 1 1 - 3 - -
Figure 9: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
図9：各AUについてインターリーブパターン、まだ存在していない以前のAUの最も初期に
In case each AU has the same size, the found maxDisplacement value over-estimates the de-interleave buffer size with three AUs. However, in case of variable AU sizes, the total size of any 5 "early" AUs stored at the same time may exceed maxDisplacement times the maximum bitrate, in which case de-interleaveBufferSize must be signaled.
ケースでは、各AUは、同じサイズ、オーバー推定見出さmaxDisplacement値3 AUSとデインタリーブバッファサイズを有します。しかしながら、可変AUサイズの場合には、「初期」のAUが同時に格納されている5の合計サイズはmaxDisplacement回ケースデinterleaveBufferSizeがシグナリングされなければならない最大ビットレートを超えることがあります。
A.5. Continuous Interleave
A.5。連続インターリーブ
A.5.1. Introduction
A.5.1。前書き
In continuous interleave, once the scheme is 'primed', the number of AUs in a packet exceeds the 'stride' (the distance between them). This shortens the buffering needed, smoothes the data-flow, and gives slightly larger packets -- and thus lower overhead -- for the same interleave. For example, here is a continuous interleave also over a stride of 3 AUs, but with 4 AUs per packet, for a run of 20 AUs. This shows both how the scheme 'starts up' and how it finishes. Once again, the example assumes fixed time duration per Access Unit.
スキームは「プライミングされた」されると、連続インターリーブでは、パケット内のAUの数は、「ストライド」（それらの間の距離）を超えます。これは、必要なバッファリングを短縮するデータフローを平滑化し、そしてわずかに大きいパケットを与える - 、したがって低いオーバーヘッド - 同じインターリーブため。例えば、ここでの連続インターリーブは20個のAUの実行のために、3つのAUのストライドを超えるが、パケットあたり4 AUSともあります。これは、スキームは「起動」どのように、それが終了する方法の両方を示しています。もう一度、例では、アクセスユニット毎に一定の時間間隔を前提としています。
Packet Time-stamp Carried AUs AU-Index, AU-Index-delta 0 T[0] 0 0 1 T[1] 1 4 0 2 2 T[2] 2 5 8 0 2 2 3 T[3] 3 6 9 12 0 2 2 2 4 T[7] 7 10 13 16 0 2 2 2 5 T[11] 11 14 17 20 0 2 2 2 6 T[15] 15 18 0 2 7 T[19] 19 0
パケットタイムスタンプのAU AU-インデックスを搭載AU-インデックス・デルタ0 T [0] 0 0 1 T [1] 1 4 0 2 2 T [2] 2 5 8 0 2 2 3 T [3] 3 6 9 12 0 2 2 2 4 T [7] 7 10 13 16 0 2 2 2 5 T [11] 11 14 17 20 0 2 2 2 6 T [15] 15 18 0 2 7 T [19] 19 0
In this example, the AU-Index is present in the first AU-header and coded with the value 0, as required for AUs with a fixed duration. To reconstruct the original order, the RTP time stamp and the
この例では、AU-インデックスは、第AU-ヘッダに存在し、固定された期間でのAUのために必要に応じて、値0で符号化されます。元の順序、RTPタイムスタンプと再構築するには
AU-Index-delta (coded with the value 2) are used. See also 3.2.3.2. Note that this example has RTP time-stamps in increasing order.
（値2で符号化された）AU-インデックスデルタが使用されます。また、3.2.3.2を参照してください。この例では、昇順にRTPタイムスタンプを持っていることに注意してください。
A.5.2. Determining the De-interleave Buffer Size
A.5.2。デ・インタリーブバッファサイズを決定します
For this example the de-interleave buffer size can be derived from Figure 10. The maximum number of "early" AUs is 3. If the AUs are of constant size, then the de-interleave buffer size equals 3 times the AU size. Compared to the example in A.2, for constant size AUs the de-interleave buffer size is reduced from 4 to 3 times the AU size, while maintaining the same 'stride'.
この例では、デインタリーブバッファサイズは、図10「初期」のAUは、一定のサイズのものである場合のAUが3である場合、デインタリーブバッファサイズは3回AUサイズに等しい最大数から導出することができます。同一の「ストライド」を維持しながら、A.2の例と比較して、一定のサイズのAUのためにデインターリーブバッファのサイズは、4〜3倍AUサイズから縮小されます。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+- - - - 4 - - 4 8 - - 8 12 - - 5 9 "Early" AUs 8 12
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - インターリーブされたのAU | 0 | 1 | 4 | 2 | 5 | 8 | 3 | 6 | 9 | 12 | 7 | 10 | 13 | 16 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - - - 4 - - 4 8 - - 8 12 - 5 - 9、 "初期" 8~12
Figure 10: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
図10：インターリーブされたAUあたりのデインタリーブバッファにおける「早期」のAUのストレージ。
A.5.3. Determining the Maximum Displacement
A.5.3。最大変位を求めます
For this example, the maximum displacement has a value of 5 AU periods. See Figure 11. Compared to the example in A.2, the maximum displacement does not decrease, though in fact less de-interleave buffering is required.
この例では、最大変位は5つのAU期間の値を有します。実際にはあまりデインタリーブバッファリングが必要とされるがA.2例と比較すると図11を参照して、最大変位は減少しません。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Interleaved AUs | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+- Earliest not yet present AU - - 2 - 3 3 - - 7 7 - - 11 11
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - インターリーブのAU | 0 | 1 | 4 | 2 | 5 | 8 | 3 | 6 | 9 | 12 | 7 | 10 | 13 | 16 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - 最古まだ存在していないAU - 2 - - 3 3 - - 7 7 - - 11 11
Figure 11: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
図11：各AUについてインターリーブパターン、まだ存在していない以前のAUの最も初期に
References
リファレンス
Normative References
引用規格
[1] ISO/IEC International Standard 14496 (MPEG-4); "Information technology - Coding of audio-visual objects", January 2000
[1] ISO / IEC国際規格14496（MPEG-4）。 「情報技術 - オーディオビジュアルオブジェクトのコーディング」、2000年1月
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[2] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
[3] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[3]解放され、N.、Klensin、J.およびJ.ポステル、 "多目的インターネットメール拡張（MIME）パート4：登録手順"、BCP 13、RFC 2048、1996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月を。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
Informative References
参考文献
[7] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[7]ホフマン、D.、フェルナンド、G.、Goyal氏、V.とM. Civanlar、 "MPEG1 / MPEG2ビデオのためのRTPペイロードフォーマット"、RFC 2250、1998年1月。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real-Time Session Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinneと、H.とラオとA.とR. Lanphier、 "リアルタイムセッションプロトコル（RTSP）"、RFC 2326、1998年4月。
[9] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[9]パーキンス、C.およびO.ホドソン、 "ストリーミングメディアの修理のためのオプション"、RFC 2354、1998年6月。
[10] Schulzrinne, H. and J. Rosenberg, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[10] Schulzrinneと、H.とJ.ローゼンバーグ、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 2733、1999年12月。
[11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11]ハンドレー、M.、パーキンス、C.およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[12] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y. and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000.
[12]菊池、Y.、野村、T.、福永、S.、松井、Y.およびH.木全、 "MPEG-4オーディオ/ビジュアルストリームのためのRTPペイロードフォーマット"、RFC 3016、2000年11月。
Authors' Addresses
著者のアドレス
Jan van der Meer Philips Electronics Prof Holstlaan 4 Building WAH-1 5600 JZ Eindhoven Netherlands
ヤンファン・デル・ミーアフィリップスエレクトロニクス教授ホルストレーン4棟WAH-1 5600 JZアイントホーフェンオランダ
EMail: jan.vandermeer@philips.com
メールアドレス：jan.vandermeer@philips.com
David Mackie Apple Computer, Inc. One Infinite Loop, MS:302-3KS Cupertino CA 95014
デビッド・マッキーたApple Computer、Inc.の一つ無限ループ、MS：302-3KSクパチーノCA 95014
EMail: dmackie@apple.com
メールアドレス：dmackie@apple.com
Viswanathan Swaminathan Sun Microsystems Inc. 2600 Casey Avenue Mountain View, CA 94043
Viswanathanのスワミナサンサン・マイクロ株式会社2600ケーシー・アベニューマウンテンビュー、CA 94043
EMail: viswanathan.swaminathan@sun.com
メールアドレス：viswanathan.swaminathan@sun.com
David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014
デビッド・シンガーたApple Computer、Inc.の一つ無限ループ、MS：302-3MTクパチーノCA 95014
EMail: singer@apple.com
メールアドレス：singer@apple.com
Philippe Gentric Philips Electronics 51 rue Carnot 92156 Suresnes France
フィリップGentricフィリップスエレクトロニクス51 RUEカルノー92156サレネスフランス
EMail: philippe.gentric@philips.com
メールアドレス：philippe.gentric@philips.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。