[要約] RFC 3016は、MPEG-4オーディオ/ビジュアルストリームのためのRTPペイロード形式を定義しています。このRFCの目的は、MPEG-4コンテンツをリアルタイムでストリーミングするための標準化と相互運用性の向上です。
Network Working Group Y. Kikuchi
Request for Comments: 3016 Toshiba
Category: Standards Track T. Nomura
NEC
S. Fukunaga
Oki
Y. Matsui
Matsushita
H. Kimata
NTT
November 2000
RTP Payload Format for MPEG-4 Audio/Visual 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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Multipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP).
このドキュメントでは、MPEG-4システムを使用せずにMPEG-4オーディオとMPEG-4のビジュアルビットストリームを運ぶためのリアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットについて説明します。MPEG-4オーディオ/ビジュアルビットストリームをRTPパケットに直接マッピングする目的で、RTPヘッダーフィールドの使用の仕様を提供し、フラグメンテーションルールも指定します。また、多目的インターネットメールエクステンション（MIME）タイプの登録とセッション説明プロトコル（SDP）の使用の仕様も提供します。
The RTP payload formats described in this document specify how MPEG-4 Audio [3][5] and MPEG-4 Visual streams [2][4] are to be fragmented and mapped directly onto RTP packets.
このドキュメントで説明されているRTPペイロード形式は、MPEG-4オーディオ[3] [5]およびMPEG-4の視覚ストリーム[2] [4]を断片化し、RTPパケットに直接マッピングする方法を指定します。
These RTP payload formats enable transport of MPEG-4 Audio/Visual streams without using the synchronization and stream management functionality of MPEG-4 Systems [6]. Such RTP payload formats will be used in systems that have intrinsic stream management functionality and thus require no such functionality from MPEG-4 Systems. H.323 terminals are an example of such systems, where MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors but by H.245. The streams are directly mapped onto RTP packets without using MPEG-4 Systems Sync Layer. Other examples are SIP and RTSP where MIME and SDP are used. MIME types and SDP usages of the RTP payload formats described in this document are defined to directly specify the attribute of Audio/Visual streams (e.g., media type, packetization format and codec configuration) without using MPEG-4 Systems. The obvious benefit is that these MPEG-4 Audio/Visual RTP payload formats can be handled in an unified way together with those formats defined for non-MPEG-4 codecs. The disadvantage is that interoperability with environments using MPEG-4 Systems may be difficult, other payload formats may be better suited to those applications.
これらのRTPペイロード形式は、MPEG-4システムの同期とストリーム管理機能を使用せずにMPEG-4オーディオ/ビジュアルストリームの輸送を可能にします[6]。このようなRTPペイロード形式は、本質的なストリーム管理機能を備えたシステムで使用され、したがってMPEG-4システムからのそのような機能を必要としません。H.323端子は、MPEG-4オーディオ/ビジュアルストリームがMPEG-4システムオブジェクトの記述子によってはなく、H.245によって管理されるようなシステムの例です。ストリームは、MPEG-4システム同期レイヤーを使用せずにRTPパケットに直接マッピングされます。他の例は、MIMEとSDPが使用されるSIPとRTSPです。このドキュメントで説明されているRTPペイロード形式のMIMEタイプとSDP使用は、MPEG-4システムを使用せずにオーディオ/ビジュアルストリーム（メディアタイプ、パケット化形式、コーデック構成など）の属性を直接指定するように定義されています。明らかな利点は、これらのMPEG-4オーディオ/ビジュアルRTPペイロードフォーマットが、Non-MPEG-4コーデック用に定義された形式と一緒に統合された方法で処理できることです。不利な点は、MPEG-4システムを使用した環境との相互運用性が難しい場合があり、他のペイロード形式がそれらのアプリケーションにより適している可能性があることです。
The semantics of RTP headers in such cases need to be clearly defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it is beneficial to define the fragmentation rules of RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside the MPEG-4 Video stream.
このような場合のRTPヘッダーのセマンティクスは、MPEG-4オーディオ/ビジュアルデータ要素との関連を含め、明確に定義する必要があります。さらに、MPEG-4ビデオストリーム内で提供されるエラーレジリエンスツールを利用することによりエラーレジリエンシーを強化するために、MPEG-4ビデオストリームのRTPパケットの断片化ルールを定義することが有益です。
MPEG-4 Visual is a visual coding standard with many new features: high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrates from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to mobile networks with high error rates.
MPEG-4 Visualは、多くの新機能を備えた視覚的なコーディング標準です。高いコーディング効率。高い誤差の弾力性;複数の任意の形状オブジェクトベースのコーディング。など[2]。KBPのスコアからいくつかのMBPまで、幅広いビットレートをカバーしています。また、エラーのないエラーのないネットワークまで、エラー率が高いモバイルネットワークに至るまで、さまざまなネットワークをカバーしています。
With respect to the fragmentation rules for an MPEG-4 Visual bitstream defined in this document, since MPEG-4 Visual is used for a wide variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video packet shall always be mapped on a single RTP packet" may be inappropriate. On the other hand, careless, media unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but manage to define the minimum rules for preventing meaningless fragmentation while utilizing the error resilience functionalities of MPEG-4 Visual.
このドキュメントで定義されているMPEG-4の視覚的ビットストリームの断片化ルールに関しては、MPEG-4ビジュアルはさまざまなネットワークに使用されるため、断片化に多くの制限を適用しないことが望ましいです。「単一のビデオパケットは、常に単一のRTPパケットにマッピングされる必要があります」は、不適切な場合があります。一方、不注意で、メディアが気づかない断片化は、誤差と帯域幅の効率の劣化を引き起こす可能性があります。このドキュメントで説明されている断片化ルールは柔軟ですが、MPEG-4ビジュアルのエラーレジリエンス機能を利用しながら、意味のない断片化を防ぐための最小ルールを定義することができます。
The fragmentation rule recommends not to map more than one VOP in an RTP packet so that the RTP timestamp uniquely indicates the VOP time framing. On the other hand, MPEG-4 video may generate VOPs of very small size, in cases with an empty VOP (vop_coded=0) containing only VOP header or an arbitrary shaped VOP with a small number of coding blocks. To reduce the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet. (See fragmentation rule (4) in section 3.2 and marker bit and timestamp in section 3.1.)
フラグメンテーションルールは、RTPタイムスタンプがVOPタイムフレーミングを一意に示すように、RTPパケットに複数のVOPをマッピングしないことを推奨しています。一方、MPEG-4ビデオは、VOPヘッダーのみを含む空のVOP（VOP_Coded = 0）の場合、または少数のコーディングブロックを備えた任意の形状のVOPを含む非常に小さなサイズのVOPを生成する場合があります。そのような場合のオーバーヘッドを減らすために、フラグメンテーションルールは、RTPパケットで複数のVOPを連結することを許可します。（セクション3.2のフラグメンテーションルール（4）およびセクション3.1のマーカービットとタイムスタンプを参照してください。）
While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, MPEG-4 Visual has already error resilience functionalities for recovering corrupt headers, and these can be used on RTP/IP networks as well as on other networks (H.223/mobile, MPEG-2/TS, etc.). Therefore, no extra RTP header fields are defined in this MPEG-4 Visual RTP payload format.
H.261またはMPEG-1/2などのビデオコーディングツールで定義された追加のメディア固有のRTPヘッダーは、パケット損失によって破損した画像ヘッダーの回復に役立つのに効果的ですが、MPEG-4 Visualには、破損したヘッダーを回復するための誤差機能機能が既にあります。また、これらはRTP/IPネットワークと他のネットワーク（H.223/Mobile、MPEG-2/TSなど）で使用できます。したがって、このMPEG-4 Visual RTPペイロード形式では、追加のRTPヘッダーフィールドは定義されていません。
MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto the RTP packets without using MPEG-4 Systems.
MPEG-4オーディオは、さまざまな種類のオーディオコーディングツールを統合する新しい種類のオーディオ標準です。低オーバーヘッドMPEG-4オーディオトランスポートマルチプレックス（LATM）は、オーディオデータのシーケンスを比較的小さなオーバーヘッドで管理します。オーディオのみのアプリケーションでは、LATMベースのMPEG-4オーディオビットストリームがMPEG-4システムを使用せずにRTPパケットに直接マッピングすることが望ましいです。
While LATM has several multiplexing features as follows;
LATMには次のようにいくつかの多重化機能があります。
- Carrying configuration information with audio data, - Concatenation of multiple audio frames in one audio stream, - Multiplexing multiple objects (programs), - Multiplexing scalable layers,
- オーディオデータを使用して構成情報をキャリングする - 1つのオーディオストリームでの複数のオーディオフレームの連結 - 複数のオブジェクト（プログラム）、マルチプレックススケーラブルレイヤー、
in RTP transmission there is no need for the last two features. Therefore, these two features MUST NOT be used in applications based on RTP packetization specified by this document. Since LATM has been developed for only natural audio coding tools, i.e., not for synthesis tools, it seems difficult to transmit Structured Audio (SA) data and Text to Speech Interface (TTSI) data by LATM. Therefore, SA data and TTSI data MUST NOT be transported by the RTP packetization in this document.
RTPトランスミッションでは、最後の2つの機能は必要ありません。したがって、これらの2つの機能は、このドキュメントで指定されたRTPパケット化に基づいてアプリケーションで使用してはなりません。LATMは自然なオーディオコーディングツールのみ、つまり合成ツール用ではないため、構造化されたオーディオ（SA）データとテキストからテキストへのテキスト（TTSI）データをLATMによって送信することは難しいようです。したがって、SAデータとTTSIデータは、このドキュメントのRTPパケット化によって輸送されてはなりません。
For transmission of scalable streams, audio data of each layer SHOULD be packetized onto different RTP packets allowing for the different layers to be treated differently at the IP level, for example via some means of differentiated service. On the other hand, all configuration data of the scalable streams are contained in one LATM configuration data "StreamMuxConfig" and every scalable layer shares the StreamMuxConfig. The mapping between each layer and its configuration data is achieved by LATM header information attached to the audio data. In order to indicate the dependency information of the scalable streams, a restriction is applied to the dynamic assignment rule of payload type (PT) values (see section 4.2).
スケーラブルなストリームを送信するには、各レイヤーのオーディオデータを異なるRTPパケットにパケット化して、例えば差別化されたサービスを介して、IPレベルで異なるレイヤーを異なる方法で処理できるようにする必要があります。一方、スケーラブルストリームのすべての構成データは、1つのLATM構成データ「StreamMuxConfig」に含まれており、すべてのスケーラブルレイヤーがStreamMuxConfigを共有しています。各レイヤーとその構成データの間のマッピングは、オーディオデータに添付されたLATMヘッダー情報によって達成されます。スケーラブルストリームの依存関係情報を示すために、ペイロードタイプ（PT）値の動的割り当てルールに制限が適用されます（セクション4.2を参照）。
For MPEG-4 Audio coding tools, as is true for other audio coders, if the payload is a single audio frame, packet loss will not impair the decodability of adjacent packets. Therefore, the additional media specific header for recovering errors will not be required for MPEG-4 Audio. Existing RTP protection mechanisms, such as Generic Forward Error Correction (RFC 2733) and Redundant Audio Data (RFC 2198), MAY be applied to improve error resiliency.
MPEG-4オーディオコーディングツールの場合、他のオーディオコーダーに当てはまるように、ペイロードが単一のオーディオフレームである場合、パケットの損失は隣接するパケットのデコード可能性を損ないません。したがって、MPEG-4オーディオには、エラーを回復するための追加のメディア固有のヘッダーは必要ありません。ジェネリックフォワードエラー補正（RFC 2733）や冗長なオーディオデータ（RFC 2198）などの既存の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 RFC-2119 [7].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC-2119 [7]に記載されているように解釈される。
This section specifies RTP packetization rules for MPEG-4 Visual content. An MPEG-4 Visual bitstream is mapped directly onto RTP packets without the addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode MUST be used so that configuration information will be carried to the same RTP port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC 14496-2 [2][9][4]) The configuration information MAY additionally be specified by some out-of-band means. If needed for an H.323 terminal, H.245 codepoint "decoderConfigurationInformation" MUST be used for this purpose. If needed by systems using MIME content type and SDP parameters, e.g., SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information (see 5.1 and 5.2).
このセクションでは、MPEG-4視覚コンテンツのRTPパケット化ルールを指定します。MPEG-4ビジュアルビットストリームは、追加のヘッダーフィールドを追加したり、視覚的な構文要素を削除したりすることなく、RTPパケットに直接マッピングされます。構成情報が基本ストリームと同じRTPポートに運ばれるように、構成/初等ストリームモードを組み合わせて使用する必要があります。（ISO/IEC 14496-2 [2] [9] [4]の6.2.1「開始コード」を参照）構成情報は、いくつかの帯域外の手段でさらに指定される場合があります。H.323端末に必要な場合は、H.245 CodePoint「DecoderConfigurationInformation」をこの目的に使用する必要があります。MIMEコンテンツタイプとSDPパラメーターを使用したシステムで必要な場合は、SIPやRTSPなど、オプションのパラメーター「構成」を使用して構成情報を指定する必要があります（5.1および5.2を参照）。
When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older implementations).
短いビデオヘッダーモードを使用する場合、H.263のRTPペイロード形式を使用する必要があります（RFC 2429で定義されている形式を推奨しますが、RFC 2190形式は、古い実装との互換性に使用できます）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | RTP
| MPEG-4 Visual stream (byte aligned) | Pay-
| | load
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - An RTP packet for MPEG-4 Visual stream
図1-MPEG -4ビジュアルストリームのRTPパケット
Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range SHALL be chosen by means of an out of band signaling protocol (e.g., H.245, SIP, etc).
ペイロードタイプ（PT）：この新しいパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。特定のクラスのアプリケーションのRTPプロファイルは、このエンコードにペイロードタイプを割り当てるか、それが完了していない場合、ダイナミックレンジのペイロードタイプは、バンドからの信号プロトコル（例：、H.245、SIPなど）。
Extension (X) bit: Defined by the RTP profile used.
拡張機能（x）ビット：使用されるRTPプロファイルによって定義されています。
Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value.
シーケンス番号：セキュリティ上の理由で、ランダムな初期値を使用して、送信されたRTPデータパケットごとに1つずつ増加します。
Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. When multiple VOPs are carried in the same RTP packet, the marker bit is set to one.
マーカー（M）ビット：マーカービットは、VOPの最後のRTPパケット（またはRTPパケットのみ）を示すために1に設定されています。複数のVOPが同じRTPパケットで運ばれると、マーカービットが1に設定されます。
Timestamp: The timestamp indicates the sampling instance of the VOP contained in the RTP packet. A constant offset, which is random, is added for security reasons.
タイムスタンプ：タイムスタンプは、RTPパケットに含まれるVOPのサンプリングインスタンスを示しています。ランダムな一定のオフセットがセキュリティ上の理由で追加されます。
- When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the VOP times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the timestamp of the next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the timestamp of the immediately preceding VOP in the coding order is used.
- 複数のVOPが同じRTPパケットで運ばれると、タイムスタンプは、RTPパケットで運ばれるVOP内のVOP時間の最も早い時間を示します。残りのVOPのタイムスタンプ情報は、VOPヘッダーのタイムスタンプフィールド（modulo_time_baseおよびvop_time_increment）から派生しています。-RTPパケットに構成情報および/またはgroup_of_videOobjectplane（）フィールドのみが含まれている場合、コーディング順序の次のVOPのタイムスタンプが使用されます。-RTPパケットにVisual_Object_Sequence_End_Code情報のみが含まれている場合、コーディング順序の直前のVOPのタイムスタンプが使用されます。
The resolution of the timestamp is set to its default value of 90kHz, unless specified by an out-of-band means (e.g., SDP parameter or MIME parameter as defined in section 5).
タイムスタンプの解像度は、帯域外の平均（例：セクション5で定義されているSDPパラメーターまたはMIMEパラメーターなど）で指定されていない限り、デフォルト値90kHzに設定されます。
Other header fields are used as described in RFC 1889 [8].
他のヘッダーフィールドは、RFC 1889 [8]に記載されているように使用されます。
A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation.
断片化されたMPEG-4ビジュアルビットストリームは、追加のヘッダーフィールドを追加したり、視覚的な構文要素を削除することなく、RTPペイロードに直接マッピングされます。組み合わせた構成/基本ストリームモードが使用されます。断片化には、次のルールが適用されます。
In the following, header means one of the following:
以下では、ヘッダーは次のいずれかを意味します。
- Configuration information (Visual Object Sequence Header, Visual Object Header and Video Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() See 6.2.1 "Start codes" of ISO/IEC 14496-2 [2][9][4] for the definition of the configuration information and the entry point functions.
- 構成情報（Visual Object Sequence Header、Visual Object Header、およびVideo Object Layer Header） - Visual_object_sequence_end_code-基本ストリームのエントリポイント関数のヘッダー（group_of_videoobjectplane（）またはvideo_plane_with_short_short_header（）、meshobject（）、meshobject（）またはfaceObject（）） - ビデオパケットヘッダー（video_packet_header（）を除くnext_resync_marker（）） - gob_layer（）のヘッダー（）を参照してください。構成情報とエントリポイント関数の定義。
(1) Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload (just after the RTP header) or just after the header of the syntactically upper layer function.
(1) 構成情報とgroup_of_videOObjectplane（）フィールドは、RTPペイロードの先頭（RTPヘッダーの直後）または構文的に上層層関数のヘッダーの直後に配置する必要があります。
(2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. Note: The visual_object_sequence_end_code is regarded as the lowest function.
(2) RTPペイロードに1つ以上のヘッダーが存在する場合、RTPペイロードは、構文的に最高の関数のヘッダーから始まります。注：visual_object_sequence_end_codeは、最も低い関数と見なされます。
(3) A header SHALL NOT be split into a plurality of RTP packets.
(3) ヘッダーは、複数のRTPパケットに分割されてはなりません。
(4) Different VOPs SHOULD be fragmented into different RTP packets so that one RTP packet consists of the data bytes associated with a unique VOP time instance (that is indicated in the timestamp field in the RTP packet header), with the exception that multiple consecutive VOPs MAY be carried within one RTP packet in the decoding order if the size of the VOPs is small.
(4) 異なるVOPは、異なるRTPパケットに断片化する必要があります。これにより、1つのRTPパケットが一意のVOPタイムインスタンス（RTPパケットヘッダーのタイムスタンプフィールドに示されている）に関連付けられたデータバイトで構成されています。VOPSのサイズが小さい場合、デコード順に1つのRTPパケット内に運ばれます。
Note: When multiple VOPs are carried in one RTP payload, the timestamp of the VOPs after the first one may be calculated by the decoder. This operation is necessary only for RTP packets in which the marker bit equals to one and the beginning of RTP payload corresponds to a start code. (See timestamp and marker bit in section 3.1.)
注：複数のVOPが1つのRTPペイロードで運ばれると、最初のVOPSのタイムスタンプはデコーダーによって計算されます。この操作は、マーカービットが1つに等しく、RTPペイロードの開始が開始コードに対応するRTPパケットにのみ必要です。（セクション3.1のタイムスタンプとマーカービットを参照してください。）
(5) It is RECOMMENDED that a single video packet is sent as a single RTP packet. The size of a video packet SHOULD be adjusted in such a way that the resulting RTP packet is not larger than the path-MTU. Note: Rule (5) does not apply when the video packet is disabled by the coder configuration (by setting resync_marker_disable in the VOL header to 1), or in coding tools where the video packet is not supported. In this case, a VOP MAY be split at arbitrary byte-positions.
(5) 単一のビデオパケットを単一のRTPパケットとして送信することをお勧めします。ビデオパケットのサイズは、結果のRTPパケットがPath-MTUより大きくないように調整する必要があります。注：ルール（5）は、ビデオパケットがCoder構成によって無効になっている場合は適用されません（volヘッダーで1にresync_marker_disableを設定します）、またはビデオパケットがサポートされていないコーディングツールでは適用されません。この場合、VOPは任意のバイトポジションで分割される場合があります。
The video packet starts with the VOP header or the video packet header, followed by motion_shape_texture(), and ends with next_resync_marker() or next_start_code().
ビデオパケットは、VOPヘッダーまたはビデオパケットヘッダーから始まり、その後にvoty_shape_texture（）が続き、next_resync_marker（）またはnext_start_code（）で終了します。
Figure 2 shows examples of RTP packets generated based on the criteria described in 3.2
図2は、3.2で説明されている基準に基づいて生成されたRTPパケットの例を示しています。
(a) is an example of the first RTP packet or the random access point of an MPEG-4 Visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header(VS header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header(VO header, VOL header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code.
(a) 構成情報を含む最初のRTPパケットまたはMPEG-4ビジュアルビットストリームのランダムアクセスポイントの例です。Criterion（1）によれば、Visual Object Object HeaderとVideo Object Layer Header（Vo Header、Vol Header）の前に、Visual Object Sequence Header（VS Header）がRTPペイロードの先頭に配置されます。3.2で定義されているフラグメンテーションルールは、visual_object_sequence_start_codeから始まる構成情報が常にRTPペイロードの先頭に配置されることを保証するため、RTP受信機はRTPペイロードの最初の32ビットフィールドがあるかどうかを確認してランダムアクセスポイントを検出できます。Visual_object_sequence_start_code。
(b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet containing only the configuration information may thus increase the overhead, the configuration information and the immediately following GOV and/or (a part of) VOP can be packetized into a single RTP packet as in this example.
(b) 構成情報を含むRTPパケットの別の例です。RTPパケットには、構成情報に従ってVOPにビデオパケットも含まれているという点で、例（a）とは異なります。構成情報の長さは比較的短く（通常はバイトのスコア）、構成情報のみを含むRTPパケットがオーバーヘッド、構成情報、およびvopの直後のvopを増加させる可能性があるためこの例のように、単一のRTPパケットにパケット化されました。
(c) is an example of an RTP packet that contains Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of RTP/IP header overhead to generate an RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be placed in the same RTP packet as shown in (c).
(c) group_of_videoobjectplane（gov）を含むRTPパケットの例です。基準（1）に従って、GOVはRTPペイロードの先頭に配置されます。長さが7バイトであるGOVのみを含むRTPパケットを生成するのは、RTP/IPヘッダーのオーバーヘッドの無駄です。したがって、（c）に示すのと同じRTPパケットに次のVOPを配置できます。
(d) is an example of the case where one video packet is packetized into one RTP packet. When the packet-loss rate of the underlying network is high, this kind of packetization is recommended. Even when the RTP packet containing the VOP header is discarded by a packet loss, the other RTP packets can be decoded by using the HEC(Header Extension Code) information in the video packet header. No extra RTP header field is necessary.
(d) 1つのビデオパケットが1つのRTPパケットにパケット化されている場合の例です。基礎となるネットワークのパケット損失率が高い場合、この種のパケット化が推奨されます。VOPヘッダーを含むRTPパケットがパケット損失によって破棄された場合でも、ビデオパケットヘッダーにHEC（ヘッダー拡張コード）情報を使用して、他のRTPパケットをデコードできます。追加のRTPヘッダーフィールドは必要ありません。
(e) is an example of the case where more than one video packet is packetized into one RTP packet. This kind of packetization is effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single RTP packet loss. The optimal number of video packets in an RTP packet and the length of the RTP packet can be determined considering the packet-loss rate and the bit-rate of the underlying network.
(e) 複数のビデオパケットが1つのRTPパケットにパケット化されている場合の例です。この種のパケット化は、基礎となるネットワークのビットレートが低い場合に、RTP/IPヘッダーのオーバーヘッドを保存するのに効果的です。ただし、複数のビデオパケットが単一のRTPパケット損失によって破棄されるため、パケット損失回復力が低下します。RTPパケット内の最適な数のビデオパケットとRTPパケットの長さは、パケットロスレートと基礎となるネットワークのビット率を考慮して決定できます。
(f) is an example of the case when the video packet is disabled by setting resync_marker_disable in the VOL header to 1. In this case, a VOP may be split into a plurality of RTP packets at arbitrary byte-positions. For example, it is possible to split a VOP into fixed-length packets. This kind of coder configuration and RTP packet fragmentation may be used when the underlying network is guaranteed to be error-free. On the other hand, it is not recommended to use it in error-prone environment since it provides only poor packet loss resiliency.
(f) VOLヘッダーでRESYNC_MARKER_DISABLEを1に設定することにより、ビデオパケットが無効になっている場合の例です。この場合、VOPは任意のバイトポジションで複数のRTPパケットに分割される場合があります。たとえば、VOPを固定長のパケットに分割することができます。この種のコーダー構成とRTPパケットフラグメンテーションは、基礎となるネットワークのエラーがないことが保証されている場合に使用できます。一方、パケット損失の低い回復力のみを提供するため、エラーが発生しやすい環境で使用することはお勧めしません。
Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.
図3は、3.2の基準で禁止されているRTPパケットの例を示しています。
Fragmentation of a header into multiple RTP packets, as in (a), will not only increase the overhead of RTP/IP headers but also decrease the error resiliency. Therefore, it is prohibited by the criterion (3).
（a）のように、ヘッダーの複数のRTPパケットへの断片化は、RTP/IPヘッダーのオーバーヘッドを増加させるだけでなく、エラーの弾力性を低下させます。したがって、基準（3）によって禁止されています。
When concatenating more than one video packets into an RTP packet, VOP header or video_packet_header() shall not be placed in the middle of the RTP payload. The packetization as in (b) is not allowed by criterion (2) due to the aspect of the error resiliency. Comparing this example with Figure 2(d), although two video packets are mapped onto two RTP packets in both cases, the packet-loss resiliency is not identical. Namely, if the second RTP packet is lost, both video packets 1 and 2 are lost in the case of Figure 3(b) whereas only video packet 2 is lost in the case of Figure 2(d).
複数のビデオパケットをRTPパケットに連結する場合、VOPヘッダーまたはVideo_Packet_Header（）はRTPペイロードの中央に配置されません。（b）のようなパケット化は、エラーの弾力性の側面により、基準（2）によって許可されません。この例を図2（d）と比較すると、2つのビデオパケットが両方の場合に2つのRTPパケットにマッピングされていますが、パケット損失回復力は同一ではありません。つまり、2番目のRTPパケットが失われた場合、図3（b）の場合、ビデオパケット1と2の両方が失われますが、図2（d）の場合、ビデオパケット2のみが失われます。
+------+------+------+------+
(a) | RTP | VS | VO | VOL |
|header|header|header|header|
+------+------+------+------+
+------+------+------+------+------------+
(b) | RTP | VS | VO | VOL |Video Packet|
|header|header|header|header| |
+------+------+------+------+------------+
+------+-----+------------------+
(c) | RTP | GOV |Video Object Plane|
|header| | |
+------+-----+------------------+
+------+------+------------+ +------+------+------------+
(d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet|
|header|header| (1) | |header|header| (2) |
+------+------+------------+ +------+------+------------+
+------+------+------------+------+------------+------+------------+
(e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet|
|header|header| (1) |header| (2) |header| (3) |
+------+------+------------+------+------------+------+------------+
+------+------+------------+ +------+------------+
(f) | RTP | VOP |VOP fragment| | RTP |VOP fragment|
|header|header| (1) | |header| (2) | ___
+------+------+------------+ +------+------------+
Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream
図2- RTPパケット化されたMPEG -4ビジュアルビットストリームの例
+------+-------------+ +------+------------+------------+
(a) | RTP |First half of| | RTP |Last half of|Video Packet|
|header| VP header | |header| VP header | |
+------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+
(b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet|
|header|header| of VP(1) | |header| of VP(1)|header| (2) |
+------+------+----------+ +------+---------+------+------------+
Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream
図3- MPEG -4ビジュアルビットストリームの禁止されているRTPパケット化の例
This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams MUST be formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) tool [5], and the LATM-based streams are then mapped onto RTP packets as described the three sections below.
このセクションでは、MPEG-4オーディオビットストリームのRTPパケット化ルールを指定します。MPEG-4オーディオストリームは、LATM（ローオーバーヘッドMPEG-4オーディオトランスポートマルチプレックス）ツール[5]でフォーマットする必要があり、LATMベースのストリームは、以下の3つのセクションを説明するようにRTPパケットにマッピングされます。
LATM-based streams consist of a sequence of audioMuxElements that include one or more audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of each audioMuxElement SHALL be located at the first payload location in an RTP packet.
LATMベースのストリームは、1つ以上のオーディオフレームを含む一連のAudiOmuxelementsで構成されています。完全なオーディオムクサーメントまたは1つの一部は、AudiOmuxElementの構文要素を除去することなく、RTPペイロードに直接マッピングするものとします（図4を参照）。各audiOmuxelementの最初のバイトは、RTPパケットの最初のペイロード場所に配置する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |RTP
: audioMuxElement (byte aligned) :Payload
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - An RTP packet for MPEG-4 Audio
図4- MPEG -4オーディオ用のRTPパケット
In order to decode the audioMuxElement, the following muxConfigPresent information is required to be indicated by an out-of-band means. When SDP is utilized for this indication, MIME parameter "cpresent" corresponds to the muxConfigPresent information (see section 5.3).
audiOmuxelementをデコードするには、以下のmuxconfigpresent情報を帯域外の手段で示す必要があります。この表示にSDPが使用される場合、MIMEパラメーター「Cpresent」はMuxConfigPresent情報に対応します（セクション5.3を参照）。
muxConfigPresent: If this value is set to 1 (in-band mode), the audioMuxElement SHALL include an indication bit "useSameStreamMux" and MAY include the configuration information for audio compression "StreamMuxConfig". The useSameStreamMux bit indicates whether the StreamMuxConfig element in the previous frame is applied in the current frame. If the useSameStreamMux bit indicates to use the StreamMuxConfig from the previous frame, but if the previous frame has been lost, the current frame may not be decodable. Therefore, in case of in-band mode, the StreamMuxConfig element SHOULD be transmitted repeatedly depending on the network condition. On the other hand, if muxConfigPresent is set to 0 (out-band mode), the StreamMuxConfig element is required to be transmitted by an out-of-band means. In case of SDP, MIME parameter "config" is utilized (see section 5.3).
MuxConfigpresent：この値が1（インバンドモード）に設定されている場合、AudiOmuxElementには表示ビット「USESAMESTREAMMUX」が含まれ、オーディオ圧縮「StreamMuxConfig」の構成情報が含まれる場合があります。USESAMESTREAMMUXビットは、前のフレームのStreamMuxConfig要素が現在のフレームに適用されているかどうかを示します。UseSamestreamMuxビットが前のフレームからStreamMuxConfigを使用することを示しているが、前のフレームが失われた場合、現在のフレームがデコードできない場合があります。したがって、インバンドモードの場合、StreamMuxConfig要素は、ネットワーク条件に応じて繰り返し送信する必要があります。一方、muxconfigpresentが0（bandモード）に設定されている場合、StreamMuxConfig要素は帯域外の手段で送信する必要があります。SDPの場合、MIMEパラメーター「config」が利用されます（セクション5.3を参照）。
Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range shall be chosen by means of an out of band signaling protocol (e.g., H.245, SIP, etc). In the dynamic assignment of RTP payload types for scalable streams, a different value SHOULD be assigned to each layer. The assigned values SHOULD be in order of enhance layer dependency, where the base layer has the smallest value.
ペイロードタイプ（PT）：この新しいパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。特定のクラスのアプリケーションのRTPプロファイルは、このエンコードにペイロードタイプを割り当てるか、それが完了していない場合、ダイナミックレンジのペイロードタイプは、バンドからの信号プロトコル（例：、H.245、SIPなど）。スケーラブルストリームのRTPペイロードタイプの動的割り当てでは、各レイヤーに異なる値を割り当てる必要があります。割り当てられた値は、ベースレイヤーの値が最小のレイヤー依存性を強化する順番である必要があります。
Marker (M) bit: The marker bit indicates audioMuxElement boundaries. It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement.
マーカー（M）ビット：マーカービットは、オーディオムクサーメントの境界を示します。RTPパケットには、完全なaudiomuxelementまたはaudiomuxelementの最後の断片が含まれていることを示すために設定されています。
Timestamp: The timestamp indicates the sampling instance of the first audio frame contained in the RTP packet. Timestamps are recommended to start at a random value for security reasons.
タイムスタンプ：タイムスタンプは、RTPパケットに含まれる最初のオーディオフレームのサンプリングインスタンスを示します。タイムスタンプは、セキュリティ上の理由からランダムな価値で開始することをお勧めします。
Unless specified by an out-of-band means, the resolution of the timestamp is set to its default value of 90 kHz.
帯域外の平均で指定されていない限り、タイムスタンプの解像度は90 kHzのデフォルト値に設定されます。
Sequence Number: Incremented by one for each RTP packet sent, starting, for security reasons, with a random value.
シーケンス番号：セキュリティ上の理由からランダムな値で、送信されたRTPパケットごとに1つずつ増加します。
Other header fields are used as described in RFC 1889 [8].
他のヘッダーフィールドは、RFC 1889 [8]に記載されているように使用されます。
It is RECOMMENDED to put one audioMuxElement in each RTP packet. If the size of an audioMuxElement can be kept small enough that the size of the RTP packet containing it does not exceed the size of the path-MTU, this will be no problem. If it cannot, the audioMuxElement MAY be fragmented and spread across multiple packets.
各RTPパケットに1つのAudiOmuxelementを入れることをお勧めします。AudiOmuxelementのサイズを十分に小さく保つことができ、それを含むRTPパケットのサイズがPath-MTUのサイズを超えない場合、これは問題ありません。できない場合、AudiOmuxelementは断片化され、複数のパケットに広がる可能性があります。
The following sections describe the MIME type registrations for MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the MPEG-4 Visual stream are described in Sections 5.1 and 5.2, respectively, while MIME type registration and SDP usage for MPEG-4 Audio stream are described in Sections 5.3 and 5.4, respectively.
次のセクションでは、MPEG-4オーディオ/ビジュアルストリームのMIMEタイプ登録について説明します。MPEG-4視覚ストリームのMIMEタイプの登録とSDPの使用については、それぞれセクション5.1と5.2で説明しますが、MPEG-4オーディオストリームのMIMEタイプの登録とSDPの使用は、それぞれセクション5.3および5.4で説明されています。
MIME media type name: video
MIMEメディアタイプ名：ビデオ
MIME subtype name: MP4V-ES
MIMEサブタイプ名：MP4V-ES
Required parameters: none
必要なパラメーター：なし
Optional parameters:
オプションのパラメーター：
rate: This parameter is used only for RTP transport. It indicates the resolution of the timestamp field in the RTP header. If this parameter is not specified, its default value of 90000 (90kHz) is used.
レート：このパラメーターは、RTP輸送にのみ使用されます。RTPヘッダーのタイムスタンプフィールドの解像度を示します。このパラメーターが指定されていない場合、90000（90kHz）のデフォルト値が使用されます。
profile-level-id: A decimal representation of MPEG-4 Visual Profile and Level indication value (profile_and_level_indication) defined in Table G-1 of ISO/IEC 14496-2 [2][4]. This parameter MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual codec is capable. If this parameter is not specified by the procedure, its default value of 1 (Simple Profile/Level 1) is used.
プロファイルレベルID：ISO/IEC 14496-2 [2] [4]の表G-1で定義されているMPEG-4視覚プロファイルとレベル表示値（Profile_and_level_indication）の10進表現。このパラメーターは、機能交換またはセッションのセットアップ手順で使用され、MPEG-4の視覚プロファイルとMPEG-4ビジュアルコーデックが有能なレベルの組み合わせを示します。このパラメーターが手順で指定されていない場合、そのデフォルト値1（単純プロファイル/レベル1）が使用されます。
config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. It is a hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start codes of ISO/IEC14496-2 [2][4][9]. The configuration information is mapped onto the octet string in an MSB-first basis. The first bit of the configuration information SHALL be located at the MSB of the first octet. 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 exist, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2).
構成：このパラメーターは、対応するMPEG-4 Visual BitStreamの構成を示すために使用するものとします。機能交換手順でコーデック機能を示すために使用してはなりません。これは、ISO/IEC14496-2 [2] [4] [9]のサブクロート6.2.1の開始コードで定義されているように、MPEG-4視覚構成情報を表現するオクテット文字列の16進表現です。構成情報は、MSBファーストベースでOctet文字列にマッピングされます。構成情報の最初のビットは、最初のオクテットのMSBに配置するものとします。このパラメーターで示されている構成情報は、first_half_vbv_occupancyとlatter_half_vvbv_occupancyを除き、対応するMPEG-4視覚ストリームの構成情報と同じでなければなりません。6.2.1 ISO/IEC14496-2の開始コード）。
Example usages for these parameters are:
これらのパラメーターの使用例は次のとおりです。
- MPEG-4 Visual Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=1
- MPEG-4ビジュアルシンプルプロファイル/レベル1：コンテンツタイプ：ビデオ/MP4V-ES;プロファイルレベルID = 1
- MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v-es; profile-level-id=34
- MPEG-4ビジュアルコアプロファイル/レベル2：コンテンツタイプ：ビデオ/MP4V-ES;プロファイルレベルID = 34
- MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=145
- MPEG-4 Visual Advancedリアルタイムシンプルプロファイル/レベル1：コンテンツタイプ：ビデオ/MP4V-ES;プロファイルレベルID = 145
Published specification: The specifications for MPEG-4 Visual streams are presented in ISO/IEC 14469-2 [2][4][9]. The RTP payload format is described in RFC 3016.
公開された仕様：MPEG-4の視覚ストリームの仕様は、ISO/IEC 14469-2 [2] [4] [9]で提示されています。RTPペイロード形式は、RFC 3016で説明されています。
Encoding considerations: Video bitstreams MUST be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). A video bitstream is binary data and MUST be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets MUST be packetized according to the MPEG-4 Visual RTP payload format defined in RFC 3016.
エンコーディングの考慮事項：ビデオビットストリームは、MPEG-4の視覚仕様（ISO/IEC 14496-2）に従って生成する必要があります。ビデオビットストリームはバイナリデータであり、非バイナリトランスポート用にエンコードする必要があります（電子メールの場合、Base64エンコードで十分です）。このタイプは、RTP経由の転送用にも定義されています。RFC 3016で定義されているMPEG-4 Visual RTPペイロード形式に従って、RTPパケットをパケット化する必要があります。
Security considerations: See section 6 of RFC 3016.
セキュリティ上の考慮事項：RFC 3016のセクション6を参照してください。
Interoperability considerations: MPEG-4 Visual 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 Visual 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 Visualは、視覚オブジェクトのコーディングのための大規模でリッチなツールセットを提供します。標準の効果的な実装のために、MPEG-4視覚ツールセットのサブセットが特定のアプリケーションで使用するために提供されています。「プロファイル」と呼ばれるこれらのサブセットは、実装するためにデコーダーが必要なツールセットのサイズを制限します。計算の複雑さを制限するために、各プロファイルに対して1つ以上のレベルが設定されます。プロファイル@レベルの組み合わせにより：
o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and
o 同じ組み合わせに含まれる他のMPEG-4デバイスとのインターワーキングを維持しながら、必要な標準のサブセットのみを実装するためのコーデックビルダーと
o checking whether MPEG-4 devices comply with the standard (' conformance testing').
o MPEG-4デバイスが標準に準拠しているかどうかを確認します（「適合テスト」）。
The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange/announcement procedure to set this parameter mutually to the same value.
視覚ストリームは、パラメーター「プロファイルレベルID」で指定されたMPEG-4 Visual Profile@レベルに準拠するものとします。送信者とレシーバー間の相互運用性は、MIMEコンテンツのパラメーター「プロファイルレベルID」を指定するか、このパラメーターを相互に同じ値に設定する機能交換/アナウンス手順を配置することによって達成できます。
Applications which use this media type: Audio and visual streaming and conferencing tools, Internet messaging and Email applications.
このメディアタイプを使用するアプリケーション：オーディオおよびビジュアルストリーミングおよび会議ツール、インターネットメッセージング、電子メールアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: The authors of RFC 3016. (See section 8.)
連絡先への個人およびメールアドレス詳細については、RFC 3016の著者（セクション8を参照）
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The authors of RFC 3016. (See section 8.)
著者/変更コントローラー：RFC3016の著者。（セクション8を参照）
The MIME media type video/MP4V-ES string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
Mime Media Type Video/MP4V-ES文字列は、次のように、セッション説明プロトコル（SDP）、RFC 2327のフィールドにマッピングされます。
o The MIME type (video) goes in SDP "m=" as the media name.
o MIMEタイプ（ビデオ）は、SDP "M ="でメディア名として掲載されます。
o The MIME subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding name.
o MIMEサブタイプ（MP4V-ES）は、エンコーディング名としてSDP "a = rtpmap"になります。
o The optional parameter "rate" goes in "a=rtpmap" as the clock rate.
o オプションのパラメーター「レート」は、クロックレートとして「a = rtpmap」になります。
o The optional parameter "profile-level-id" and "config" go in the "a=fmtp" line to indicate the coder capability and configuration, respectively. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=value pairs.
o オプションのパラメーター「プロファイルレベルID」と「構成」は、それぞれ「A = FMTP」行に移動し、それぞれコーダーの機能と構成を示します。これらのパラメーターは、パラメーター=値ペアのセミコロン分離リストとしての形で、MIMEメディアタイプの文字列として表されます。
The following are some examples of media representation in SDP:
以下は、SDPのメディア表現の例です。
Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" and
"config" are present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=1;config=000001B001000001B509000001000000012
0008440FA282C2090A21F
Core Profile/Level 2, rate=90000(90kHz), "profile-level-id" is present in
"a=fmtp" line:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=34
Advance Real Time Simple Profile/Level 1, rate=90000(90kHz),
"profile-level-id" is present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=145
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: MP4A-LATM Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. The default value is 90000. Other rates MAY be specified only if they are set to the same value as the audio sampling rate (number of samples per second).
MIMEサブタイプ名：MP4A-LATM必要パラメーター：レート：レートパラメーターはRTPタイムスタンプクロックレートを示します。デフォルト値は90000です。その他のレートは、オーディオサンプリングレート（秒あたりのサンプル数）と同じ値に設定されている場合にのみ指定できます。
Optional parameters: profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 ([6] and its amendments). This parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used.
オプションのパラメーター：プロファイルレベルID：ISO/IEC 14496-1（[6]およびその修正）で定義されているMPEG-4オーディオプロファイルレベルの表示値の10進表現。このパラメーターは、デコーダーが使用できるMPEG-4オーディオツールサブセットを示します。このパラメーターが機能交換またはセッションのセットアップ手順で指定されていない場合、そのデフォルト値は30（ナチュラルオーディオプロファイル/レベル1）が使用されます。
object: a decimal representation of the MPEG-4 Audio Object Type value defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool to be used by the coder. It CAN be used to limit the capability within the specified "profile-level-id".
オブジェクト：ISO/IEC 14496-3 [5]で定義されたMPEG-4オーディオオブジェクトタイプ値の10進表現。このパラメーターは、コーダーが使用するツールを指定します。指定された「プロファイルレベルID」内の機能を制限するために使用できます。
bitrate: the data rate for the audio bit stream.
Bitrate：オーディオビットストリームのデータレート。
cpresent: a boolean parameter indicates whether audio payload configuration data has been multiplexed into an RTP payload (see section 4.1). A 0 indicates the configuration data has not been multiplexed into an RTP payload, a 1 indicates that it has. The default if the parameter is omitted is 1.
cpresent：ブールパラメーターは、オーディオペイロード構成データがRTPペイロードに多重化されたかどうかを示します（セクション4.1を参照）。0は、構成データがRTPペイロードに多重化されていないことを示し、1はそれがあることを示します。パラメーターが省略されている場合のデフォルトは1です。
config: a hexadecimal representation of an octet string that expresses the audio payload configuration data "StreamMuxConfig", as defined in ISO/IEC 14496-3 [5] (see section 4.1). Configuration data is mapped onto the 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, zero-padding bits, if necessary, SHALL follow the configuration data.
構成：ISO/IEC 14496-3 [5]で定義されているように、オーディオペイロード構成データ「StreamMuxConfig」を表現するOctet文字列の16進表現（セクション4.1を参照）。構成データは、MSBファーストベースでOctet文字列にマッピングされます。構成データの最初のビットは、最初のオクテットのMSBに配置するものとします。最後のオクテットでは、必要に応じてゼロパディングビットが構成データに従うものとします。
ptime: RECOMMENDED duration of each packet in milliseconds.
PTIME：各パケットの推奨期間はミリ秒単位で。
Published specification: Payload format specifications are described in this document. Encoding specifications are provided in ISO/IEC 14496-3 [3][5].
公開された仕様：ペイロード形式の仕様は、このドキュメントで説明されています。エンコード仕様は、ISO/IEC 14496-3 [3] [5]で提供されています。
Encoding considerations: This type is only defined for transfer via RTP.
考慮事項のエンコード：このタイプは、RTPを介した転送のみで定義されます。
Security considerations: See Section 6 of RFC 3016.
セキュリティ上の考慮事項：RFC 3016のセクション6を参照してください。
Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding of audio objects. For effective implementation of the standard, subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 Visual have been provided (see section 5.1).
相互運用性の考慮事項：MPEG-4オーディオは、オーディオオブジェクトのコーディングのための大規模でリッチなツールセットを提供します。標準の効果的な実装のために、MPEG-4ビジュアルで使用されるものと同様のMPEG-4オーディオツールセットのサブセットが提供されています（セクション5.1を参照）。
The audio stream SHALL be compliant with the MPEG-4 Audio Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this parameter mutually to the same value. Furthermore, the "object" parameter can be used to limit the capability within the specified Profile@Level in capability exchange.
オーディオストリームは、パラメーター「プロファイルレベルID」で指定されたMPEG-4オーディオプロファイル@レベルに準拠するものとします。送信者とレシーバー間の相互運用性は、MIMEコンテンツのパラメーター「プロファイルレベルID」を指定するか、このパラメーターを相互に同じ値に設定する機能交換手順を配置することによって達成できます。さらに、「オブジェクト」パラメーターを使用して、指定されたプロファイル@レベルの機能交換内の機能を制限できます。
Applications which use this media type: Audio and video streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオストリーミングおよび会議ツール。
Additional information: none
追加情報：なし
Personal & email address to contact for further information: See Section 8 of RFC 3016.
詳細については、お問い合わせの個人および電子メールアドレス：RFC 3016のセクション8を参照してください。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: See Section 8 of RFC 3016.
著者/変更コントローラー：RFC 3016のセクション8を参照してください。
The MIME media type audio/MP4A-LATM string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
MIME Media Type Audio/MP4A-LATM文字列は、次のように、セッション説明プロトコル（SDP）、RFC 2327のフィールドにマッピングされます。
o The MIME type (audio) goes in SDP "m=" as the media name.
o MIMEタイプ（オーディオ）は、SDP "M ="でメディア名として掲載されます。
o The MIME subtype (MP4A-LATM) goes in SDP "a=rtpmap" as the encoding name.
o MIMEサブタイプ（MP4A-LATM）は、エンコーディング名としてSDP "a = rtpmap"になります。
o The required parameter "rate" goes in "a=rtpmap" as the clock rate.
o 必要なパラメーター「レート」は、クロックレートとして「a = rtpmap」になります。
o The optional parameter "ptime" goes in SDP "a=ptime" attribute.
o オプションのパラメーター「ptime」は、SDP "a = ptime"属性になります。
o The optional parameter "profile-level-id" goes in the "a=fmtp" line to indicate the coder capability. The "object" parameter goes in the "a=fmtp" attribute. The payload-format-specific parameters
o オプションのパラメーター「プロファイルレベルID」は、「a = fmtp」行に移動し、コーダーの機能を示します。「オブジェクト」パラメーターは、「a = fmtp」属性になります。ペイロード形式固有のパラメーター
"bitrate", "cpresent" and "config" go in the "a=fmtp" line. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=value pairs.
「Bitrate」、「Cpresent」、および「config」は、「a = fmtp」行に移動します。これらのパラメーターは、パラメーター=値ペアのセミコロン分離リストとしての形で、MIMEメディアタイプの文字列として表されます。
The following are some examples of the media representation in SDP:
以下は、SDPのメディア表現の例です。
For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz),
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/8000
a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
a=ptime:20
For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of 24 kHz),
64 KB/s AAC LCステレオビットストリーム（オーディオサンプリングレート24 kHz）の場合、
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
config=9122620000
In the above two examples, audio configuration data is not multiplexed into the RTP payload and is described only in SDP. Furthermore, the "clock rate" is set to the audio sampling rate.
上記の2つの例では、オーディオ構成データはRTPペイロードに多重化されず、SDPでのみ説明されています。さらに、「クロックレート」はオーディオサンプリングレートに設定されます。
If the clock rate has been set to its default value and it is necessary to obtain the audio sampling rate, this can be done by parsing the "config" parameter (see the following example).
クロックレートがデフォルト値に設定されており、オーディオサンプリングレートを取得する必要がある場合、これは「構成」パラメーターを解析することで実行できます（次の例を参照）。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 object=8; cpresent=0; config=9128B1071070
The following example shows that the audio configuration data appears in the RTP payload.
次の例は、オーディオ構成データがRTPペイロードに表示されることを示しています。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 object=2; cpresent=1
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [8]. 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.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[8]で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮データで暗号化が実行される可能性があるため、2つの操作間に競合がありません。
The complete MPEG-4 system allows for transport of a wide range of content, including Java applets (MPEG-J) and scripts. Since this payload format is restricted to audio and video streams, it is not possible to transport such active content in this format.
完全なMPEG-4システムにより、Javaアプレット（MPEG-J）やスクリプトなど、幅広いコンテンツを輸送できます。このペイロード形式はオーディオおよびビデオストリームに制限されているため、このようなアクティブなコンテンツをこの形式で輸送することはできません。
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
1 Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual objects - Part2: Visual".
2 ISO/IEC 14496-2：1999、「情報技術 - 視聴覚オブジェクトのコーディング-Part2：Visual」。
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual objects - Part3: Audio".
3 ISO/IEC 14496-3：1999、「情報技術 - オーディオビジュアルオブジェクトのコーディング-Part3：Audio」。
4 ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part 2: Visual, Amendment 1: Visual extensions".
4 ISO/IEC 14496-2：1999/AMD.1：2000、「情報技術 - 視聴覚オブジェクトのコーディング - パート2：視覚、修正1：視覚拡張」。
5 ISO/IEC 14496-3:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part3: Audio, Amendment 1: Audio extensions".
5 ISO/IEC 14496-3：1999/AMD.1：2000、「情報技術 - オーディオビジュアルオブジェクトのコーディング-PART3：オーディオ、修正1：オーディオエクステンション」。
6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-visual objects - Part1: Systems".
6 ISO/IEC 14496-1：1999、「情報技術 - 視聴覚オブジェクトのコーディング-PART1：システム」。
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
7 Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996.
8 Schulzrinne、H.、Casner、S.、Frederick、R。and V. Jacobson "RTP：リアルタイムアプリケーション用の輸送プロトコル"、RFC 1889、1996年1月。
9 ISO/IEC 14496-2:1999/Cor.1:2000, "Information technology - Coding of audio-visual objects - Part2: Visual, Technical corrigendum 1".
9 ISO/IEC 14496-2：1999/cor.1：2000、「情報技術 - 視聴覚オブジェクトのコーディング-Part2：視覚、技術的コリゲンダム1」。
Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
ヨシヒロ・トソビカ・コーポレーション1、コムカイ・トーバチョチョ、聖書、川崎、212-8582、日本
EMail: yoshihiro.kikuchi@toshiba.co.jp
Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan
ヨシノリ松井松島電気産業株式会社1006、カドマ、カドマシ、大阪、日本
EMail: matsui@drl.mei.co.jp
Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
トシユキ遊野村NECコーポレーション4-1-1、宮崎、Miyamae-ku、川崎、日本
EMail: t-nomura@ccm.cl.nec.co.jp
Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
Shigeru Fukunaga Oki Electric Industry Co.、Ltd。1-2-27 Shiromi、Chuo-Ku、大阪540-6025日本。
EMail: fukunaga444@oki.co.jp
Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
Hideaki kimata Nippon Telegraph and Telephone Corporation 1-1、Hikari-no-oka、Yokosuka-shi、Kanagawa、Japan
EMail: kimata@nttvdt.hil.ntt.co.jp
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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 assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。