[要約] RFC 3640は、MPEG-4 Elementary Streamsの輸送のためのRTPペイロード形式を定義しています。このRFCの目的は、MPEG-4ビデオやオーディオなどのマルチメディアデータをRTPを介して効率的に転送することです。
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
MPEG-4基本ストリームの輸送用のRTPペイロード形式
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.
Copyright（c）The Internet Society（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.
Motion Picture Experts Group（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、および最近ではMPEG-4標準[1]を指定したISO/IEC JTC1 SC29のワーキンググループ11（WG11）です。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ビデオストリームを含む、MPEG-4ビデオストリーム、およびMPEG-4システムストリームなど、MPEG-4の基本ストリームを輸送するための一般的で構成可能なペイロード構造を定義します（シーン用のバイナリ形式の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は、レシーバーが重要な情報の損失を検出し、次のランダムアクセスポイントが受信されるまでデコードを停止できるように、ストリーム状態の伝達方法を指定します。ODコマンド、BIFコマンド、MPEG-J（Java）やECMAScriptなどのプログラムコンテンツなどの重要な情報を含むストリームを送信するアプリケーションには、損失の可能性に応じて適切な周期性にランダムアクセスポイントを含める必要があります。ストリームの破損を許容レベルに減らします。例は、ISO/IEC 14496-1 [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 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].
このようなアプリケーションは、追加のプロトコルまたはサービスを使用して、損失の可能性を減らすこともできます。RTPレイヤーでは、これらの測定には、再送信またはフォワードエラー補正のためのペイロード形式とプロファイル（RFC 2733 [10]など）が含まれます。一部のアプリケーションに適している可能性のある別のソリューションは、RTPをTCPよりも携帯することです（RFC 2326 [8]、セクション10.12など）。ネットワークレイヤーでは、損失の可能性を減らすために、リソース割り当てまたは優先サービスが利用可能になる場合があります。ストリーミングメディアを修復する方法の一般的な説明については、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ビデオの輸送用のRFC 3016 [12]など、その他のより具体的な形式が存在する可能性があります（ISO/IEC 14496 [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.
このドキュメントで定義されているRTPペイロード形式は、MPEG-4システムで定義されているMPEG-4同期層（SL）に含まれる可能性のある情報に相当するシステム関連情報の運送を指定します[1]。このドキュメントでは、SLからRTPペイロード形式で定義されたフィールドに情報をトランスコードまたはマップする方法を規定していません。このような処理は、もしあれば、アプリケーションの裁量に任されています。ただし、将来の追加のシステム関連情報の輸送の必要性を予測するために、そのようなデータを運ぶ可能性のある補助フィールドを構成できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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]メッセージまたは他の手段のように、MIME形式のパラメーターによって伝えられます（セクション4を参照）。これらの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アクセスユニットは、定義によりOctet-Alignedです。たとえば、オーディオフレームがオクテットに整合されていない場合、MPEG-4仕様で要求されるように、オクテットに配置されたアクセスユニットを実現するには、フレームの端に最大7つのゼロパディングビットを挿入する必要があります。MPEG-4デコーダーは、そのようなパディングが適用されるAUSをデコードできる必要があります。
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 kbit/秒でステレオ信号をエンコードするために使用される場合、AACフレームには平均で約200オクテットが含まれています。1500 Octet MTUのLANでは、RTPパケットごとに平均7つの完全なAACフレームを運ぶことができます。
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形式パラメーターを介して「バンドから外れた」と伝えられます。可変サイズAUSの場合に連結する場合、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ペイロードをレシーバーによって個々のAUSに戻すことができます。
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パケットで繰り返してはなりません。したがって、Auの繰り返しは、重複したRTPパケットを使用する場合にのみ可能です。
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パケットがアクセスユニットの連続したシーケンスを搭載すると、そのようなパケットを失うと、ユーザーに「デコードギャップ」が生じる可能性があります。この問題を軽減する1つの方法は、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.
アクセスユニットのオプションのインターリービングをサポートするために、このペイロード形式により、各アクセスユニットにインデックス情報を送信できます。バッファリソースについて通知してinterLeavingに割り当てるためにバッファーリソースについて通知した後、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 AUSが含まれていると仮定し、AUSに番号が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）：au（0）、au（3）、au（6）rtpパケット（1）：au（1）、au（4）、au（7）rtpパケット（2）：au（2）、、au（5）、au（8）rtpパケット（3）：au（9）、au（12）、au（15）rtpパケット（4）：au（10）、au（13）、au（16）等。
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（フラグメント）のサンプリングインスタントを搭載する必要があります。RTPパケット内で複数のAUが運ばれると、各AUのフレーム期間がわかっている場合、後続のAUSのタイムスタンプを計算できます。オーディオとビデオの場合、これはフレームレートが一定の場合に可能です。ただし、場合によっては、このような計算を行うことはできません（たとえば、可変フレームレートビデオの場合、またはMPEG-4 BIFの構成情報を運ぶ）。このようなケースをサポートするために、このペイロード形式を構成することができます。それぞれのアクセスユニットのRTPペイロードにタイムスタンプを運ぶことができます。RTPパケットの最初のAUのタイムスタンプがRTPパケットのタイムスタンプが運ばれるため、RTPパケットの非ファーストAUSに対してのみRTPペイロードでタイムスタンプが伝達され、最初の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.
MPEG-4は、組成タイムスタンプ（CTS）とデコードタイムスタンプ（DTS）の2種類のタイムスタンプを定義します。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ペイロードにオプションのキャリッジが可能になります。ストリーム状態は、損失を許容できない情報を運ぶ「重要な」AUSを信号するために使用され、ISO/IEC 14496-1で定義されているカルーセルメカニズムに従ってAUSを繰り返す場合にも役立ちます。
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.
このペイロード形式は、補助データを伝達する特定のフィールドを定義します。補助データフィールドの前には、データを解析せずにデータのスキップを容易にするために、補助データの長さを指定するフィールドが先行します。補助データのコーディングは、このドキュメントでは定義されていません。代わりに、補助情報の形式、意味、および信号が1つ以上の将来のRFCで指定されると予想されます。補助情報は、その形式、意味、シグナル伝達が指定され、その使用がシグナルが行われるまで送信してはなりません。補助データの知識を持つ受信者は補助データをデコードする場合がありますが、そのようなデータの知識がない受信機は補助データフィールドをスキップする必要があります。
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形式のパラメーターは、セクション4.4.1で指定されているように、または他の手段でSDP [5]メッセージを介して受信機に伝えられます。
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ペイロードには、最初の2つのオクテットに配置された3つのデータセクションが含まれています。このセクションは空です。図1を参照してください。
+---------+-----------+-----------+---------------+
| 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.
最初のデータセクションは、1つ以上のAu-Headerを含むAU（アクセスユニット）ヘッダーセクションです。ただし、各Au-Headerが空である場合があります。その場合、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ストリームを受信できる完全に構成可能な受信機を構築することは可能ですが、この仕様は、たとえば、1つのタイプのMPEG-4ストリームのみを受信できる、単純化されたが専用の受信機の設計も可能にします。これは、この仕様を使用するために特定のモードを定義することを要求することによって達成されます。各モードは、たとえばペイロード構成の1つ以上のタイプのMPEG-4ストリームを輸送するための制約を定義する場合があります。
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 [12]で定義されたペイロード形式とほぼ同じとして構成できます。したがって、RFC 3016に準拠する受信機は、そのようなRTPペイロードを解読できます。RFC 3016 [12]で要求されるように、ビデオデコーダー構成（VO、VOL、VOSH）がストリームに挿入されます。逆に、このドキュメントの仕様に準拠しているレシーバーは、RFC 3016のMPEG-4ビデオに対して定義されたペイロード、名前、パラメーターをデコードできる必要があります[12]。この点で、実装は、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ペイロード形式で最大の相互運用性を実現するために、RFC 3016を使用してMPEG-4ビデオ（パート2）を輸送するアプリケーションを推奨して、ビデオデコーダー構成を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ペイロードタイプの割り当ては、このドキュメントの範囲外です。これは、このペイロード形式が使用されるRTPプロファイルによって指定されているか、動的に帯域外に合図されます（例：SDPを使用）。
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ビットは1に設定されており、RTPパケットペイロードには断片化されたアクセスユニットの最終的なフラグメントまたは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].
CCおよびCSRCフィールドは、RFC 3550 [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.
RTCPは、RFC 3550 [2]で定義されているように使用する必要があります。RTCP送信者レポートのタイムスタンプを使用して、複数のMPEG-4基本ストリームを同期し、MPEG-4ストリームを非MPEG-4ストリームと同期するために、これらのストリームの配信がRTPを使用した場合にも同期することができることに注意してください。
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-Headers-Lengthフィールドで構成され、その後に多くのAu-Headersが続きます。図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-HeadersはMIME形式のパラメーターを使用して構成されており、空である場合があります。Au-Headerが空に構成されている場合、Au-Headers-Lengthフィールドは存在しないため、Auヘッダーセクションが空になります。Au-Headerが空に構成されていない場合、Au-Headers-Lengthは、パディングビットを除くAu-Headersの直後のビットの長さを指定する2つのOctetフィールドです。
Each AU-header is associated with a single Access Unit (fragment) contained in the Access Unit Data Section in the same RTP packet.
各Au-Headerは、同じ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-Headerがちょうど1つあります。AUヘッダーセクション内で、Au-Headersは、アクセスユニットがアクセスユニットデータセクションに含まれる順序で少し連結されています。したがって、n-th au-headerはn-th au（フラグメント）を指します。連結されたAu-Headerが非整数数のオクテットを消費する場合、AUヘッダーセクションのオクテットアライメントを達成するために、最大7つのゼロパッジングビットを最後に挿入する必要があります。
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-Headerには、図3に示されているフィールドが含まれている場合があります。CTS-FLAG、DTS-FLAG、RAP-FLAGフィールドを除き、フィールドのビットの長さは、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-DELTAおよびDTS-DELTAフィールドの存在が存在するため、それを解析することによってAu-Headerのサイズを発見できます。それぞれCTS-FLAGとDTS-FLAGの値によって信号があります。
+---------------------------------------+
| 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-Headerのフィールド。使用すると、Au-Indexフィールドは、AUヘッダーセクション内の最初のAu-Headerでのみ発生します。他のAU-Headerでは、代わりにAu-Index-Deltaフィールドが発生します。
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-Size：同じRTPパケットのアクセスユニットデータセクションの関連するアクセスユニットのオクテットのサイズを示します。auサイズが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-Index：関連するアクセスユニット（フラグメント）のシリアル番号を示します。（デコード順）連続AUまたはAuフラグメントごとに、シリアル番号は1によって増加します。AUヘッダーセクションの最初のAUヘッダーでAUインデックスフィールドが発生しますが、後続で発生してはなりません（非ファースト）そのセクションのau-header。このような非ファーストAu-Headerでシリアル番号をエンコードするには、Au-Index-Deltaフィールドが使用されます。
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-Index-Delta：Au-Index-Deltaフィールドは、関連するAUのシリアル番号を前のアクセスユニットのシリアル番号との差として指定する署名されていない整数です。したがって、n-th（n> 1）auの場合、シリアル番号は以下から見つかります。
AU-Index(n) = AU-Index(n-1) + AU-Index-delta(n) + 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ヘッダーセクションの最初のAu-HeaderにAu-Indexフィールドが存在する場合、Au-Index-Deltaフィールドは、その後の（非ファースト）Au-Headerに存在する必要があります。Au-Index-Deltaが値0でコーディングされている場合、アクセスユニットがデコード順に連続していることを示します。インターリーブが適用されている0よりも大きいAu-index-delta値が適用されます。
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-FLAG：CTS-DELTAフィールドが存在するかどうかを示します。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-DELTAフィールドの長さがゼロより大きくなるように信号されている場合、CTS-FLAGフィールドは各Au-Headerに存在する必要があります。その場合、CTS-FLAGフィールドは、最初のAu-Headerで値0を持ち、すべての非ファーストAu-Headersで値1を持つことができます。CTS-FLAGフィールドは、アクセスユニットの非ファーストフラグメントの場合は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-DELTA：CTSの値を、このRTPパケットのRTPヘッダーのタイムスタンプから2の補数オフセット（DELTA）として指定することにより、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-FLAG：DTS-DELTAフィールドが存在するかどうかを示します。1の値は、DTS-deltaが存在することを示し、値は0が存在しないことを示します。
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-DELTAフィールドの長さがゼロより大きくなるように信号されている場合、DTS-FLAGフィールドは各Au-Headerに存在する必要があります。DTS-Flagフィールドは、アクセスユニットのすべてのフラグメントに対して同じ値を持つ必要があります。
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-DELTA：DTSの値を、CTSの2の補数オフセット（DELTA）として指定します。DTSは、RTPヘッダーのタイムスタンプと同じクロックレートを使用する必要があります。DTS-DELTAフィールドは、アクセスユニットのすべてのフラグメントに対して同じ値を持つ必要があります。
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-FLAG：1に設定すると、関連するアクセスユニットがストリームのコンテンツにランダムアクセスポイントを提供することを示します。アクセスユニットが断片化されている場合、Auの非ファーストフラグメントごとに、存在する場合はRAPフラグを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.
補助セクションは、補助ダタサイズのフィールドに続いて補助ダタフィールドで構成されています。受信者は、補助産型フィールドを解析することができます（ただし必要ありません）。受信機による補助データフィールドのスキップを容易にするために、補助ダタサイズのフィールドは、補助摂取のビットの長さを示します。補助産型サイズと補助型データフィールドの連結が非整数数のオクテットを消費する場合、オクターアライメントを達成するために、補助データの直後に最大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-size：補助データフィールドの直後のビットの長さを指定します。
auxiliary-data: the auxiliary-data field contains data of a format not defined by this specification.
Auxiliary-Data：Auxiliary-Dataフィールドには、この仕様で定義されていない形式のデータが含まれています。
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は隣接するオクテットの文字列に連結されます。図5を参照してください。アクセスユニットデータセクション内のAUSは、インターリーブの場合は必ずしも連続しているわけではありませんが、デコード順にする必要があります。
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パケットがPATH 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-HeaderのAuサイズのフィールドに示される必要があります。ただし、Auサイズがストリームの場合は一定の場合、このメカニズムを使用しないでください。代わりに、固定サイズは、MIME形式のパラメーター「定数化」によって信号を送信する必要があります。セクション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-HeaderにAu-Sizeの両方が存在しないことと、MIME形式の定数パラメーターは、単一のAu（フラグメント）のキャリッジ、つまり、そのストリームの各RTPパケットで単一のアクセスユニット（フラグメント）が輸送されることを示します。
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
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)
任意のIの場合、ここで：私は元の順序でAuのインデックスを示し、TS（i）はAu（i）のタイムスタンプを示します
The MIME parameter "constantDuration" SHOULD be used to signal that Access Units have a constant time duration; see section 4.1.
MIMEパラメーター「Construmentduration」を使用して、アクセスユニットの期間が一定の期間であることを信号する必要があります。セクション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.
「construmentduration」パラメーターが存在する場合、受信者は、RTPタイムスタンプとAu-Index-Deltaのみに基づいて、元のアクセスユニットタイミングを再構築できます。したがって、一定期間のアクセスユニットを送信する場合、AU-Indexは存在する場合は、値0に設定する必要があります。一定の期間アクセスユニットの受信機は、RTPパケットの最初のAUのインデックスを決定するためにRTPタイムスタンプを使用する必要があります。Au-Index-Deltaヘッダーと信号された「Constronduration」を使用して、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.
「定数」パラメーターが存在しない場合、送信者は、各RTPパケットでau-indexをゼロでコーディングすることにより、一定の持続時間のAUSを通知する場合があります。Constraldurationパラメーターレシーバーがない場合、Au-Indexが2つの連続したRTPパケットでゼロである場合、AUSは一定の期間であると結論付ける必要があります。
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.
可変持続時間のアクセスユニットを送信する場合、「定数」パラメーターが存在する必要はなく、送信機はAU-Indexを使用して再注文に必要なインデックス情報をエンコードする必要があり、受信者はその値を使用してインデックスを決定する必要があります。RTPパケットの各Auの。AUインデックスインターリービングスキームで有効なインデックス情報が提供されるように、Au-Indexフィールドのロールオーバーのために問題を引き起こすことなく、有効なインデックス情報が提供されるように、AUインデックスフィールドのビット数を選択する必要があります。さらに、CTS-DELTAは、RTPパケット内の各非ファーストAUの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パケットのIthアクセスユニットのタイムスタンプは、次のように計算されます。
Timestamp[0] = T
Timestamp[i, i > 0] = T +(Sum(for k=1 to i of (AU-Index-delta[k]
+ 1))) * access-unit-duration
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-index-deltaが常に0の場合、これはt i *（アクセスユニット期間）に減少します。これは、フレームがデコード順に連続している非インテリアケースです。この計算では、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.
パケットのサイズは、PATH MTUとレシーバーのデテルレーブバッファーの容量の両方に適しているように適切に選択する必要があります。セッションの最大パケットサイズは、PATH 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.
ausデコード順にデコーダーを入力します。インターレーブバッファーは、インターリーブAUのストリームをデコード順に再注文するために使用されます。インターリーブが適用されると、「早期」AUSのデコードを延期する必要があります。デコード順に先行するすべてのAUSが存在するまで延期する必要があります。したがって、これらの「初期」AUSは、interleaveバッファーに保存されます。図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
Figure 6: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
図6：インターリーブAuあたりのinterleaveバッファーにおける「初期」AUSの保存。
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（6）はAu（5）が存在するまで保存されますが、Au（4）とAu（7）は、それぞれAu（2）とAu（5）が存在するまで保存されます。interleaveバッファーの膨満感は時間が異なることに注意してください。図6では、interleaveバッファーは最大4つに含まれていますが、しばしばAUSが少なくなります。
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の時期の最大変位が定義されます。パターン内のAu（j）の場合、まだ存在していないI <jを使用する各au（i）を決定できます。AUの時期の最大変位は、パターンのAUのタイムスタンプと、まだ存在していない最も初期のAUのタイムスタンプの最大差です。言い換えれば、インターリーブされたAUSのシーケンスを検討するとき、次のとおりです。
Maximum displacement = max{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.
IおよびJ> Iの場合、ここで、IとJはインターリーブパターンのAUのインデックスを示し、TSは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（k <nを含む）が示されています。a " - "は、以前のすべてのAUが存在することを示します。Au周期が一定の場合、Au（6）とAu（7）で見つかったように、最大変位は5 Au周期に等しくなります。
+--+--+--+--+--+--+--+--+--+--+--+-
Interleaved AUs | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
+--+--+--+--+--+--+--+--+--+--+--+-
Earliest not yet present 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:
interleaveバッファーのサイズの推定値は、最大変位に最大ビットレートを掛けることで見つかります。
size(de-interleave buffer) = {(maxDisplacement) * Rate(max)} / (RTP
clock frequency),
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、Profile-Level-ID、およびconfigからレート（最大）を導出できることに注意してください。
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".
ただし、この計算では、非介入バッファーのサイズを推定し、必要なサイズは計算値と異なる場合があります。この計算では、interleaveバッファーのサイズを過小評価している場合、送信者は、インターリーブの場合、MIME形式のパラメーター「De-interLeaveBuffersize」を介してinterleaveバッファーのサイズを信号する必要があります。セクション4.1を参照してください。計算がインターレーブバッファーのサイズを過大評価している場合、送信者は、インターリーブの場合、MIME形式パラメーター「De-interLeaveBuffersize」を介してinterleaveバッファーのサイズを信号する可能性があります。
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:
インターレーブバッファーの信号サイズは、セッション中の任意の時点ですべての「初期」AUSを含めるのに十分な大きさでなければなりません。あれは：
minimum de-interleave buffer size = max [sum {if TS(i) > TS(j) then
AU-size(i) else 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.
任意のjおよび任意のi <j、ここで、iとjはインターリーブパターンのauのインデックスを示します。ts（i）は、au（i）のタイムスタンプを示し、au-size（i）はのサイズを示します。au（i）オクテットの数。
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.
「deterleavebufferize」パラメーターが存在する場合、レシーバーでのインターレアビングに適用されたバッファーには、少なくともinterleaveバッファーの信号サイズに等しいサイズが必要です。interleaveバッファーの計算サイズに。
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.
どのようなインターリービングスキームが使用されていても、スキームを分析して、該当する最大値と、必要なサイズのデーターレーブバッファーを計算する必要があります。送信者は、厳密に必要な値よりも大きくない値を信号する必要があります。より大きな値が信号をかけると、受信機は過度にバッファーします。
Note that for low bit-rate material, the applied interleaving may make packets shorter than the MTU size.
低金利材料の場合、適用されたインターリーブにより、Packetが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.
「重要な」AUSと呼ばれるMPEG-4システムデータを持つ一部のアクセスユニットは、プレゼンテーションまたはデコーダーのいずれかで、損失を容認できない情報を携帯しています。MPEG-4システムストリームの各重要なAUで、ストリーム状態が変化します。河川状態は、非慎重なAUSで一定のままである可能性があります。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つのAUSが与えられたAU1 = "ノードXの挿入"、au2 = "ノードxの位置を設定し、au3 ="ノードxの位置を設定します "。AU1は重要です。これは、それが失われた場合、AU2を実行できないためです。ただし、Au2が失われたとしてもAu3を実行できるため、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が重要である可能性があります。破損すると、ストリームは次のランダムアクセスポイントまで破損したままになります。非重要なAUSの損失はストリームを破壊しないことに注意してください。デコーダーがストリームの受信を開始すると、デコーダーは、ランダムアクセスポイントを提供する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 AUSは、最近ストリームに結合したデコーダーや、ストリームの腐敗後にデコードを再起動する必要があるデコーダーによる「繰り返される」ランダムアクセスポイントを提供します。非重要なRAP AUSには、最後の重要なRAP AU以降のすべての更新を含める必要があります。
Upon receiving AUs, decoders are to react as follows:
AUSを受信すると、デコーダーは次のように反応します。
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.
a) RAP-FLAGが1に設定され、ストリーム状態が変更された場合、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-FLAGが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.
c) RAP-FLAGが0に設定されている場合、ストリームが破損していない限り、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形式パラメーター「モード」を介して適用モードを信号する必要があります。この仕様は、任意のMPEG-4ストリームに使用できる汎用モードと、ISO/IEC 14496-3で定義されたMPEG-4 CELPおよびMPEG-4 AACストリームの輸送用の特定のモードを定義します[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>]
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ステレオ素材（RFC 2327 [5]を参照）を参照）、モノについては1を指定します。追加のパラメーターが必要ない場合は、このパラメーターがモノマテリアルで省略される場合があるため、デフォルト値は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ストリームに使用できます。このモードでは、モード固有の制約は適用されません。したがって、一般的なモードでは、この仕様の完全な柔軟性を悪用することができます。汎用モードは、モード= genericによって信号されます。
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パケットで許可されています。Au-Headerには、AUサイズのフィールド、CTS-FLAG、およびCTSフラグが1に設定されている場合、CTS-DELTAフィールドが含まれています。AUサイズとCTS-DELTAフィールドのビット数は、それぞれ10と16です。Au-Headerには、Rap-Flagと4ビットのストリームステートも含まれています。これにより、BIFS-Anim Auあたり2〜4オクターの合計サイズのAu-Headerになります。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ファイルの単一行で構成されています。
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.
「config」パラメーターの16進数は、ISO/IEC 14496-1で定義されている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.
このモードは、Mode = celp-cbrで信号されます。このモードでは、固定サイズの1つ以上の完全なCELPフレームを1つのRTPパケットで輸送できます。このモードでは、インターリーブを使用しないでください。RTPペイロードは、それぞれ等しいサイズの1つ以上の連結CELPフレームで構成されています。このモードを使用する場合、CELPフレームを断片化しないでください。AUヘッダーセクションと補助セクションの両方が空でなければなりません。
The MIME format parameter constantSize MUST be provided to specify the length of each CELP frame.
各CELPフレームの長さを指定するには、MIME形式のパラメーター定数を提供する必要があります。
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
Note: The a=fmtp line has been wrapped to fit the page, it comprises a single line in the SDP file.
注：a = fmtp行は、ページに合うようにラップされており、SDPファイルの単一行で構成されています。
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.
「config」パラメーターの16進数は、ISO/IEC 14496-3で定義されているaudipecificconfig（）です。AudioSpecificConfig（）は、14.4 kb/sの固定ビットレートとCELPフレームごとに6サブフレームで16 kHzのサンプリングレートを持つモノセルプストリームを指定します。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.
このモードは、Mode = CELP-VBRで信号されます。このモードでは、オプションのインターリーブを備えた1つのRTPパケットで、可変サイズの1つ以上の完全なCELPフレームを輸送できます。このモードでは、Au-Sizeの最大の値は、最大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ペイロードはAUヘッダーセクションで構成され、その後に1つ以上の連結CELPフレームが続きます。補助セクションは空でなければなりません。ペイロードに含まれる各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.
b) 各CELPフレームのシーケンス（およびタイミング）を計算するためのインデックス情報。
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-Index（-delta）フィールドに2ビットが割り当てられます。各Au-Indexフィールドは、値0でコーディングする必要があります。Auヘッダーセクションでは、セクション3.2.1で指定されているように、連結されたAuヘッダーの前に16ビットAu-Headers-Lengthフィールドがあります。
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 MUST be signaled by the MIME format parameter constantDuration. In addition, the parameter maxDisplacement MUST be present when interleaving.
必要なMIME形式のパラメーターに加えて、次のパラメーターが存在する必要があります：Sizelength、IndexLength、およびIndexDeltalength。CELPフレームには、常にアクセスユニットごとに固定期間があります。このモードでインターリーブする場合、この特定の持続時間は、MIME形式のパラメーターConstrumentDurationによってシグナルを受信する必要があります。さらに、インターリーブするときは、パラメーターの最大値が存在する必要があります。
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
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注：A = FMTP行は、ページに合うようにラップされています。SDPファイルの単一行で構成されています。
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.
「config」パラメーターの16進数は、ISO/IEC 14496-3で定義されているaudipecificconfig（）です。audiospecificconfig（）は、13.9から16.2 kb/sの間で変化するビットレートで、セルプフレームごとに4つのサブフレームを持つビットレートで、16 kHzのサンプリングレートのモノセルプストリームを指定します。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ペイロードは、AUヘッダーセクションで構成され、その後に連結されたAACフレームが続きます。補助セクションは空でなければなりません。ペイロードに含まれる各AACフレームについて、1オクテットのAu-Headerが提供する必要があります。
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.
b) 各AACフレームのシーケンス（およびタイミング）を計算するためのインデックス情報。
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.
Au-Headerセクションでは、セクション3.2.1で指定されているように、連結されたAu-Headersの前に16ビットAu-Headers-Lengthフィールドが必要です。
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形式のパラメーターConstrumentDurationによってシグナルを受信する必要があります。さらに、インターリーブするときは、パラメーターの最大値が存在する必要があります。
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
Note: The a=fmtp line has been wrapped to fit the page; it comprises a single line in the SDP file.
注：A = FMTP行は、ページに合うようにラップされています。SDPファイルの単一行で構成されています。
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で定義されているように、「config」パラメーターの16進数はaudipecificconfig（）です。audiospecificconfig（）サンプリングレートが22.05 kHzのモノ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.
このモードは、Mode = AAC-HBRによって信号があります。このモードは、可変サイズAACフレームの輸送をサポートします。1つのRTPパケットでは、1つ以上の完全な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ペイロードはAuヘッダーセクションで構成され、その後に1つのAACフレーム、いくつかの連結AACフレーム、または1つの断片化されたAACフレームが続きます。補助セクションは空でなければなりません。ペイロードに含まれる各AACフレームについて、AUヘッダーセクションにAu-Headerが必要な場合があります。
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.
b) 各AACフレームのシーケンス（およびタイミング）を計算するためのインデックス情報。
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サイズに割り当てられ、3ビットがAu-Index（-delta）フィールドに3ビットに割り当てられます。したがって、各au-headerのサイズは2オクターです。各AUインデックスフィールドは、値0でコーディングする必要があります。AUヘッダーセクションでは、セクション3.2.1で指定されているように、連結されたAUヘッダーの前に16ビットAu-Headers-Lengthフィールドが必要です。
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形式のパラメーターConstrumentDurationによってシグナルを受信する必要があります。さらに、インターリーブするときは、パラメーターの最大値が存在する必要があります。
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ファイルの単一行で構成されています。
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で定義されているように、「config」パラメーターの16進数はaudipecificconfig（）です。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.2から3.3.6で指定されたモードのみを定義します。追加のモードは、将来の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 [3]に従って、MIMEタイプを登録します。
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-Generic
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メディアコーデックが有能な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オーディオストリームの場合、このパラメーターは、ISO/IEC 14496-1の表5（audioprofileLevelindication値）の小数値であり、オーディオストリームをデコードするためにどのMPEG-4オーディオツールサブセットが必要かを示しています。
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 [1]のテーブルG-1（プロファイルとレベルの表示のためのFLCテーブル）からの小数値であり、どの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.
BIFストリームの場合、このパラメーターは（SPLI 256*gpli）から得られる小数値です。ここで、SPLIは、適用されたシーンフィルレベルインディケーションを備えたISO/IEC 14496-1の表4の小数値です。GPLIは、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ストリームの場合、このパラメーターは、ISO/IEC 14496-1の表13（MPEGJProfileLevelindication）の小数値であり、MPEG-Jストリームのプロファイルとレベルを示しています。
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ストリームの場合、このパラメーターは、ISO/IEC 14496-1の表3（ODProfileLevelindication）の小数値であり、ODストリームのプロファイルとレベルを示しています。
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ストリームの場合、このパラメーターには小数値0があり、不特定のプロファイルとレベルを示し、ゼロよりも大きい値を示し、将来のMPEG-4仕様で定義されているMPEG-4 IPMPプロファイルとレベルを示します。
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ファーストベースで16進オクテット文字列にマッピングされます。構成データの最初のビットは、最初のオクテットのMSBに配置するものとします。最後のオクテットでは、必要に応じてオクテットアライメントを達成するために、最大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="".
MPEG-4オーディオストリームの場合、構成は、ISO/IEC 14496-3で定義されているように、オーディオオブジェクトタイプ固有のデコーダー構成データaudiospecificconfig（）です。構造化されたオーディオの場合、audiospecificconfig（）は、この仕様で定義されていない他の手段によって伝達される場合があります。audiospecificconfig（）が構造化されたオーディオのために他の手段によって伝達される場合、構成は次のように引用された空の16進オクテット文字列でなければなりません：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 Visual Streamsの場合、configは、サブクラーズ6.2.1で定義されているMPEG-4視覚構成情報です。ISO/IEC 14496-2の開始コードです。このパラメーターで示されている構成情報は、対応するMPEG-4視覚ストリームの構成情報と同じでなければなりません。ただし、存在する場合は、存在する場合は、後半のVBV-vbv-cupancyを除きます。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.
BIFストリームの場合、これは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ストリームの場合、これは引用された空の16進オクテット文字列であり、デコーダー構成情報（config = ""）がないことを示し、将来の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.
オブジェクトコンテンツ情報（OCI）ストリームの場合、これはISO/IEC 14496-1のセクション8.4.2.4で定義されているように、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ストリームの場合、これは引用された空の16進オクテット文字列（config = ""）です。デコーダー構成に関する情報は不要です。
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.
モード= generic、mode = celp-cbr、mode = celp-vbr、mode = aac-lbrおよびmode = 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の小数値。輸送されたストリームのオブジェクトタイプインジケーションの値を示しています。BIFストリームの場合、このパラメーターはbifsconfiguration（）のバージョンを信号するために存在する必要があります。ObjectTypeindicationは、Non-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.
定数化：このストリームの各アクセスユニットのオクテットの定数サイズ。定数化とサイズのパラメーターを同時に存在させてはなりません。
constantDuration: The constant duration of each Access Unit for this stream, measured with the same units as the RTP time stamp.
construmentduration：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：RTPタイムスタンプクロックの単位で表されるセクション3.2.3.3で定義されているように、インターリーブAUの時期における最大変位の小数表現。
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.
DeterLeaveBuffersize：セクション3.2.3.3で説明されているinterleaveバッファーのサイズのオクテット数における小数表現。インターリーブの場合、3.2.3.3で与えられたインターレブバッファーサイズの計算が、最大値と速度（MAX）に基づいて、interleaveバッファーのサイズを過小評価する場合、このパラメーターを存在する必要があります。この計算では、interLeaveバッファーのサイズを過小評価していない場合、DeterLeaveBuffersizeパラメーターは存在しないでください。
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-HeaderでAUサイズのフィールドがエンコードされるビット数。サイズの長さと定数化パラメーターを同時に存在させてはなりません。
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-Indexが最初のAu-Headerでエンコードされるビット数。ゼロのデフォルト値は、各最初のAu-Headerに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-Index-Deltaフィールドが任意の非ファーストAu-Headerでエンコードされるビット数。ゼロのデフォルト値は、各非ファーストAu-HeaderにAu-Index-Deltaフィールドが存在しないことを示します。
CTSDeltaLength: The number of bits on which the CTS-delta field is encoded in the AU-header.
CTSDELTALENGTH：CTS-DELTAフィールドがAU-Headerでエンコードされるビット数。
DTSDeltaLength: The number of bits on which the DTS-delta field is encoded in the AU-header.
dtsdeltalength：dts-deltaフィールドがAu-headerでエンコードされるビット数。
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.
ランダムアクセスインド：ゼロまたは1の小数値。Au-headerにラップフラグが存在するかどうかを示します。1の小数値は、ラップフラグの存在を示し、デフォルト値ゼロはその不在を示します。
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-Headerで河川状態フィールドがエンコードされるビット数。このパラメーターは、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）に従って生成する必要があります。RFC 3640で定義されているRTPペイロード形式に従って、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ツールセットのサブセットが特定のアプリケーションで使用するために提供されています。「プロファイル」と呼ばれるこれらのサブセットは、実装するためにデコーダーが必要なツールセットのサイズを制限します。計算の複雑さを制限するために、各プロファイルに対して1つ以上の「レベル」が設定されます。プロファイル@レベルの組み合わせにより：
. 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
。同じ組み合わせを実装する他のMPEG-4デバイスとの相互作用を維持しながら、必要な標準のサブセットのみを実装するためのコーデックビルダーと
. 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
マジックナンバー：なし
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ファイルタイプコード：なし
Person & email address to contact for further information: Authors of RFC 3640, IETF Audio/Video Transport working group.
連絡先への個人および電子メールアドレス詳細については、RFC 3640、IETFオーディオ/ビデオトランスポートワーキンググループの著者。
Intended usage: 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.
この仕様は、多くのモードで使用できます。操作モードは、「モード」MIMEパラメーターを使用してシグナル伝達され、セクション4.1で指定された最初の値セットがあります。セクション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.2から3.3.6までのセクションを参照）。
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:
このペイロード形式に関連付けられた上記のパラメーターを輸送する典型的な方法の1つは、たとえば、RTSP描写[8]またはSAP [11]に返信してクライアントに輸送されるSDPメッセージ[5]を介してであると想定されています。その場合、（a = fmtp）キーワードは、RFC 2327 [5]、セクション6、構文で説明されているように使用する必要があります。
a=fmtp:<format> <parameter name>=<value>[; <parameter name>=<value>]
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]で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮データで暗号化が実行される可能性があるため、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.
MPEG-4システムは、ODコマンド、BIFコマンドなど、MPEG-J（Java（TM）BYTEコード）やMPEG-4スクリプトなどのプログラムコンテンツなど、端末で実行されるコマンドを含むストリームタイプをサポートしています。MPEGに準拠していない方法で上記の1つ以上を使用して、レシーバーをクラッシュさせるか、一時的に利用できないようにすることができます。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コンテンツは、定義されたセキュリティモデル内のレシーバーでサポートされている一連のJavaパッケージからこのAPIおよびJava（TM）メソッドのセットを呼び出すことができます。このセキュリティモデルによれば、ダウンロードされたBYTEコードは、ライブラリをロードしたり、ネイティブメソッドを定義したり、プログラムを開始したり、ファイルを読み書きしたり、システムプロパティを読み取ったりすることが禁止されています。受信機は、バッファー要件またはパラメトリック（OD、BIFなど）またはプログラマティック（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スクリプト（ECMAScriptのサブセット）を実装する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アドホックグループのおかげです。著者は、関係するすべての人々、特にアンドレア・バッソ、スティーブン・カスナー、M。レハ・サーペル、カルステン・ヘルペル、ジョン・ラザロ、ズヴィ・ライフシッツ、ヤング・クウン・リム、アレックス・マコーレイ、ビル・メイ、コリン・パーキンス、ドライラジV、ステファン・ウェンガーのためのビル・メイに感謝したいと考えています。彼らの貴重なコメントとサポート。
APPENDIX: Usage of this Payload Format
付録：このペイロード形式の使用
A. Examples of Delay Analysis with Interleave
A.インターリーブによる遅延分析の例
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タイムスタンプクロックの単位で通知されます。
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で処理を続ける必要があります。
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.
通常のインターリーブの例は、パケットがグループに形成されたときです。インターリーブの「ストライド」（インターリーブAUS間の距離）が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
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-Indexは最初のAu-Headerに存在し、固定期間AUSに必要な値0でコード化されています。グループ内の各パケットの最初のAuの位置はRTPタイムスタンプで定義され、Au-Index-Deltaフィールドは、パケットの最初のAuに対する後続のAUの位置を示します。この例では、すべてのAu-Index-Deltaフィールドには値n-1でコード化されています。したがって、RTPタイムスタンプとAu-Index-Deltaを使用して、元の順序を再構築します。セクション3.2.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 ausのインターレーブバッファーが格納していることを示しています。同時に保存されている4つの「早期」AUの総数に少なくとも等しい、同時に保存される任意の任意の任意のオクテットに等しいinterLeaveBuffersize値が信号を受ける場合があります。
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期間に等しいことを示しています。したがって、信号を送信する必要がある最小最大値は5 au期間です。各Auのサイズが同じ場合、この最大値は1つのAuを使用してinterleaveバッファーサイズを過剰に超えています。ただし、可変Auサイズの場合、同時に保存する必要がある4つの「早期」AUの合計サイズは、最大ビットレートを最大値を超える可能性があることに注意してください。
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.
グループインターリーブを使用してパケットを形成する別の例を以下に示します。この例では、2つの後続の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 ..
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-Indexは最初のAu-Headerに存在し、固定期間のAUSに必要な値0でコード化されています。元の注文を再構築するために、RTPタイムスタンプとAu-Index-Delta（値4でコーディング）が使用されます。セクション3.2.3.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が保存されることを決定することができます。AUSが一定のサイズの場合、この値はAUサイズの5倍に等しくなります。interLeaveバッファーの最小サイズは、同時に保存される「初期」AUのオクテットの最大総数に等しくなります。これにより、シグナルがある可能性のあるinterleavebufferizeの最小値が得られます。
+--+--+--+--+--+--+--+--+--+--+
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
Figure 8: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
図8：インターリーブAuあたりのinterleaveバッファーにおける「初期」AUSの保存。
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期間に等しいことがわかります。したがって、信号を受ける最小最大値は8 au期間です。
+--+--+--+--+--+--+--+--+--+--+
Interleaved AUs | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
+--+--+--+--+--+--+--+--+--+--+
Earliest not yet present 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について、まだ存在していない以前のausの最も早い
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のサイズが同じ場合、見つかった最大値は3つのAUでインターレーブバッファーサイズを過大評価しています。ただし、可変Auサイズの場合、同時に保存されている5つの「早期」AUの合計サイズは、最大ビットレートを最大値を超えている場合があります。
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.
連続的なインターリーブでは、スキームが「プライミング」されると、パケット内のAUSの数は「ストライド」（それらの間の距離）を超えます。これにより、必要なバッファリングが短縮され、データフローが滑らかになり、同じインターリーブに対してわずかに大きなパケット（したがってオーバーヘッドが低下）が得られます。たとえば、ここでは3 AUの歩幅にわたって連続的なインターリーブがありますが、20 AUSの実行に対してパケットごとに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
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 2) are used. See also 3.2.3.2. Note that this example has RTP time-stamps in increasing order.
この例では、Au-Indexは最初のAu-Headerに存在し、固定期間のAUSに必要な値0でコード化されています。元の注文を再構築するために、RTPタイムスタンプとAu-Index-Delta（値2でコーディング）が使用されます。3.2.3.2も参照してください。この例には、RTPのタイムスタンプがあり、順序が増えていることに注意してください。
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'.
この例では、interLeaveバッファーサイズは図10から導出できます。「早期」AUSの最大数は3です。AUSが一定サイズの場合、インターレーブバッファサイズはAUサイズの3倍に等しくなります。A.2の例と比較して、一定のサイズの場合、interleaveバッファーサイズは、同じ「ストライド」を維持しながら、AUサイズの4倍から3倍に減少します。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
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
Figure 10: Storage of "early" AUs in the de-interleave buffer per interleaved AU.
図10：インターリーブAuあたりのinterleaveバッファーにおける「初期」AUSの保存。
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期間です。図11を参照してください。A.2の例と比較して、最大変位は減少しませんが、実際には介入後のバッファリングが少ないです。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
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
Figure 11: For each AU in the interleaving pattern, the earliest of any earlier AUs not yet present
図11：インテリアパターンの各AUについて、まだ存在していない以前のausの最も早い
References
参考文献
Normative References
引用文献
[1] ISO/IEC International Standard 14496 (MPEG-4); "Information technology - Coding of audio-visual objects", January 2000
[1] ISO/IEC International Standard 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.、Frederick、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] Freed、N.、Klensin、J。and J. Postel、「多目的インターネットメール拡張機能（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and 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] Hoffman、D.、Fernando、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.、Rao、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] Perkins、C。and O. Hodson、「ストリーミングメディアの修理のオプション」、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. Rosenberg、「一般的なフォワードエラー補正のためのRTPペイロード形式」、RFC 2733、1999年12月。
[11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、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] Kikuchi、Y.、Nomura、T.、Fukunaga、S.、Matsui、Y。、およびH. kimata、「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
Jan van Der Meer Philips Electronics Prof Holstlaan 4 Building WAH-1 5600 JZ Eindhovenオランダ
EMail: jan.vandermeer@philips.com
David Mackie Apple Computer, Inc. One Infinite Loop, MS:302-3KS Cupertino CA 95014
David Mackie Apple Computer、Inc。One Infinite Loop、MS：302-3KS Cupertino CA 95014
EMail: dmackie@apple.com
Viswanathan Swaminathan Sun Microsystems Inc. 2600 Casey Avenue Mountain View, CA 94043
Viswanathan Swaminathan Sun Microsystems Inc. 2600 Casey Avenue Mountain View、CA 94043
EMail: viswanathan.swaminathan@sun.com
David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014
David Singer Apple Computer、Inc。One Infinite Loop、MS：302-3MT Cupertino CA 95014
EMail: singer@apple.com
Philippe Gentric Philips Electronics 51 rue Carnot 92156 Suresnes France
フィリップ紳士フィリップスエレクトロニクス51 Rue Carnot 92156 Suresnes France
EMail: philippe.gentric@philips.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。