[要約] RFC 6416は、MPEG-4オーディオ/ビジュアルストリームのためのRTPペイロード形式に関する仕様です。このRFCの目的は、MPEG-4ストリームをRTPパケットにエンコードするための標準化と相互運用性の向上です。
Internet Engineering Task Force (IETF) M. Schmidt
Request for Comments: 6416 Dolby Laboratories
Obsoletes: 3016 F. de Bont
Category: Standards Track Philips Electronics
ISSN: 2070-1721 S. Doehla
Fraunhofer IIS
J. Kim
LG Electronics Inc.
October 2011
RTP Payload Format for MPEG-4 Audio/Visual Streams
MPEG-4オーディオ/ビジュアルストリームのRTPペイロード形式
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. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet-switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.
このドキュメントでは、MPEG-4システムを使用せずにMPEG-4オーディオおよびMPEG-4ビジュアルビットストリームを携帯するためのリアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットについて説明します。このドキュメントはRFC 3016を廃止します。RFC3016からの変更の要約が含まれており、RFC 3016への逆方向の互換性について説明します。これは、3GPPパケットスイッチストリーミングサービス（PSS）の仕様との不整合を修正するために、RFC 3016の必要な改訂です。MPEG-4オーディオ用のRTPペイロード形式。
For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations.
MPEG-4オーディオ/ビジュアルビットストリームをRTPパケットに直接マッピングする目的で、このドキュメントはRTPヘッダーフィールドの使用の仕様を提供し、フラグメンテーションルールも指定します。また、メディアタイプの登録とセッション説明プロトコル（SDP）の使用の仕様も提供します。このドキュメントで説明されているオーディオペイロード形式には、必要なマルチプレックス形式のオーディオコーデックパラメーターの信号に関連するいくつかの制限があります。したがって、新しいシステム設計では、これらの制限がないRFC 3640を利用する必要があります。それにもかかわらず、RFC 3016のこの改訂は、仕様を更新および完了し、相互運用可能な実装を有効にするために提供されます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6416.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6416で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. MPEG-4 Visual RTP Payload Format . . . . . . . . . . . . . 4
1.2. MPEG-4 Audio RTP Payload Format . . . . . . . . . . . . . 5
1.3. Interoperability with RFC 3016 . . . . . . . . . . . . . . 6
1.4. Relation with RFC 3640 . . . . . . . . . . . . . . . . . . 6
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
3. Clarifications on Specifying Codec Configurations for
MPEG-4 Audio . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. LATM Restrictions for RTP Packetization of MPEG-4 Audio
Bitstreams . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. RTP Packetization of MPEG-4 Visual Bitstreams . . . . . . . . 8
5.1. Use of RTP Header Fields for MPEG-4 Visual . . . . . . . . 9
5.2. Fragmentation of MPEG-4 Visual Bitstream . . . . . . . . . 10
5.3. Examples of Packetized MPEG-4 Visual Bitstream . . . . . . 11
6. RTP Packetization of MPEG-4 Audio Bitstreams . . . . . . . . . 15
6.1. RTP Packet Format . . . . . . . . . . . . . . . . . . . . 15
6.2. Use of RTP Header Fields for MPEG-4 Audio . . . . . . . . 16
6.3. Fragmentation of MPEG-4 Audio Bitstream . . . . . . . . . 17
7. Media Type Registration for MPEG-4 Audio/Visual Streams . . . 17
7.1. Media Type Registration for MPEG-4 Visual . . . . . . . . 17
7.2. Mapping to SDP for MPEG-4 Visual . . . . . . . . . . . . . 20
7.2.1. Declarative SDP Usage for MPEG-4 Visual . . . . . . . 20
7.3. Media Type Registration for MPEG-4 Audio . . . . . . . . . 21
7.4. Mapping to SDP for MPEG-4 Audio . . . . . . . . . . . . . 24
7.4.1. Declarative SDP Usage for MPEG-4 Audio . . . . . . . . 25
7.4.1.1. Example: In-Band Configuration . . . . . . . . . . 25
7.4.1.2. Example: 6 kbit/s CELP . . . . . . . . . . . . . . 25
7.4.1.3. Example: 64 kbit/s AAC LC Stereo . . . . . . . . . 26
7.4.1.4. Example: Use of the "SBR-enabled" Parameter . . . 26
7.4.1.5. Example: Hierarchical Signaling of SBR . . . . . . 27
7.4.1.6. Example: HE AAC v2 Signaling . . . . . . . . . . . 27
7.4.1.7. Example: Hierarchical Signaling of PS . . . . . . 28
7.4.1.8. Example: MPEG Surround . . . . . . . . . . . . . . 28
7.4.1.9. Example: MPEG Surround with Extended SDP
Parameters . . . . . . . . . . . . . . . . . . . . 28
7.4.1.10. Example: MPEG Surround with Single-Layer
Configuration . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Differences to RFC 3016 . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
The RTP payload formats described in this document specify how MPEG-4 Audio [14496-3] and MPEG-4 Visual streams [14496-2] are to be fragmented and mapped directly onto RTP packets.
このドキュメントで説明されているRTPペイロード形式は、MPEG-4オーディオ[14496-3]およびMPEG-4の視覚ストリーム[14496-2]を断片化し、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 [14496-1]. 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 [H323] 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 [H245]. The streams are directly mapped onto RTP packets without using the MPEG-4 Systems Sync Layer. Other examples are the Session Initiation Protocol (SIP) [RFC3261] and Real Time Streaming Protocol (RTSP) where media type and SDP are used. Media type 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 a 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; hence, other payload formats may be better suited to those applications.
これらのRTPペイロード形式は、MPEG-4システムの同期およびストリーム管理機能を使用せずにMPEG-4オーディオ/ビジュアルストリームの輸送を可能にします[14496-1]。このようなRTPペイロード形式は、本質的なストリーム管理機能を備えたシステムで使用され、したがってMPEG-4システムからのそのような機能を必要としません。 H.323 [H323]端子は、MPEG-4オーディオ/ビジュアルストリームがMPEG-4システムオブジェクト記述子によってはなく、H.245 [H245]によって管理されるこのようなシステムの例です。ストリームは、MPEG-4システム同期レイヤーを使用せずにRTPパケットに直接マッピングされます。その他の例は、セッション開始プロトコル（SIP）[RFC3261]と、メディアタイプとSDPが使用されるリアルタイムストリーミングプロトコル（RTSP）です。このドキュメントで説明されているRTPペイロード形式のメディアタイプと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 resiliency 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 features, including: high coding efficiency; high error resiliency; and multiple, arbitrary shape object-based coding [14496-2]. It covers a wide range of bitrates from scores of kbit/s to several Mbit/s. 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は、次のような多くの機能を備えた視覚的なコーディング標準です。高い誤差の弾力性;複数の任意の形状オブジェクトベースのコーディング[14496-2]。KBIT/sのスコアからいくつかのMBIT/sまで、広範囲のビットレートをカバーしています。また、エラーのないエラーレートのモバイルネットワークまで、ほぼエラーのないネットワークに及ぶさまざまなネットワークをカバーしています。
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"
このドキュメントで定義されているMPEG-4の視覚的ビットストリームのフラグメンテーションルールに関しては、MPEG-4ビジュアルはさまざまなネットワークに使用されるため、断片化にあまりにも多くの制限を適用しないことが望ましいです。「単一のビデオパケットは、常に単一のRTPパケットにマッピングされる必要があります」
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 resiliency functionalities of MPEG-4 Visual.
不適切かもしれません。一方、不注意なメディアに及ぶ断片化は、誤差と帯域幅の効率の劣化を引き起こす可能性があります。このドキュメントで説明されている断片化ルールは柔軟ですが、MPEG-4ビジュアルのエラー回復力機能を利用しながら、意味のない断片化を防ぐための最小ルールを定義することができます。
The fragmentation rule "Different Video Object Planes (VOPs) SHOULD be fragmented into different RTP packets" is made 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 5.2 and the descriptions of marker bit and timestamp in Section 5.1.)
フラグメンテーションルール「異なるビデオオブジェクトプレーン（VOPS）は、異なるRTPパケットに断片化する必要があります」が作成され、RTPタイムスタンプがVOPタイムフレーミングを一意に示すようにします。一方、MPEG-4ビデオは、VOPヘッダーのみを含む空のVOP（VOP_Coded = 0）の場合、少数のコーディングブロックを備えた任意の形状のVOPを含む非常に小さなサイズのVOPを生成する場合があります。そのような場合のオーバーヘッドを減らすために、フラグメンテーションルールは、RTPパケットで複数のVOPを連結することを許可します。（セクション5.2の断片化規則（4）と、セクション5.1のマーカービットとタイムスタンプの説明を参照してください。）
While the additional media-specific RTP header defined for such video coding tools as H.261 [H261] or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, MPEG-4 Visual already has error resiliency 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 Transport Stream, etc.). Therefore, no extra RTP header fields are defined in this MPEG-4 Visual RTP payload format.
H.261 [H261]またはMPEG-1/2などのビデオコーディングツールで定義された追加のメディア固有のRTPヘッダーは、パケット損失によって破損した画像ヘッダーの回復に効果的ですが、MPEG-4視覚にはすでにエラーの回復力機能がありますが破損したヘッダーを回復します。これらは、RTP/IPネットワークや他のネットワーク（H.223/Mobile、MPEG-2輸送ストリームなど）で使用できます。したがって、このMPEG-4 Visual RTPペイロード形式では、追加のRTPヘッダーフィールドは定義されていません。
MPEG-4 Audio is an 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 RTP packets without using MPEG-4 Systems.
MPEG-4オーディオは、さまざまな種類のオーディオコーディングツールを統合するオーディオ標準です。低オーバーヘッドMPEG-4オーディオトランスポートマルチプレックス（LATM）は、オーディオデータのシーケンスを比較的小さなオーバーヘッドで管理します。オーディオのみのアプリケーションでは、LATMベースのMPEG-4オーディオビットストリームがMPEG-4システムを使用せずにRTPパケットに直接マッピングすることが望ましいです。
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 [RFC5109] and Redundant Audio Data [RFC2198], MAY be applied to improve error resiliency.
MPEG-4オーディオコーディングツールの場合、他のオーディオコーダーに当てはまるように、ペイロードが単一のオーディオフレームである場合、パケット損失は隣接するパケットのデコード可能性を損ないません。したがって、MPEG-4オーディオには、回復エラーのための追加のメディア固有のヘッダーは必要ありません。ジェネリックフォワードエラー補正[RFC5109]や冗長なオーディオデータ[RFC2198]などの既存のRTP保護メカニズムを適用して、エラーの回復力を改善できます。
This specification is not backwards compatible with [RFC3016], as a binary incompatible LATM version is mandated. Existing implementations of RFC 3016 that use a recent LATM version may already comply to this specification and must be considered as not compliant with RFC 3016. The 3GPP PSS service [3GPP] is such an example, as a more recent LATM version is mandated in the 3GPP PSS specification. Existing implementations that use the LATM version as specified in RFC 3016 MUST be updated to comply with this specification.
この仕様は、バイナリの互換性のないLATMバージョンが義務付けられているため、[RFC3016]との逆方向に互換性がありません。最近のLATMバージョンを使用するRFC 3016の既存の実装は、すでにこの仕様に準拠している可能性があり、RFC 3016に準拠していないと見なされる必要があります。3GPPPSSサービス[3GPP]は、より最近のLATMバージョンがより義務付けられているため、そのような例です。3GPP PSS仕様。RFC 3016で指定されているLATMバージョンを使用する既存の実装は、この仕様に準拠するために更新する必要があります。
In this document a payload format for the transport of MPEG-4 Elementary Streams is specified. For MPEG-4 Audio streams "out-of-band" signaling is defined such that a receiver is not obliged to decode the payload data to determine the audio codec and its configuration. The signaling capabilities specified in this document are less explicit than those defined in [RFC3640]. But, the use of the MPEG-4 LATM in various transmission standards justifies its right to exist; see also Section 1.2.
このドキュメントでは、MPEG-4基本ストリームの輸送のためのペイロード形式が指定されています。MPEG-4オーディオストリームの場合、「バンド外」シグナル伝達が定義されているため、受信機はペイロードデータをデコードしてオーディオコーデックとその構成を決定する義務がありません。このドキュメントで指定されているシグナリング機能は、[RFC3640]で定義されているものよりも明示的ではありません。しかし、さまざまな伝送基準でのMPEG-4 LATMの使用は、存在する権利を正当化します。セクション1.2も参照してください。
This document makes use of terms, specified in [14496-2], [14496-3], and [23003-1]. In addition, the following terms are used in this document and have specific meaning within the context of this document.
この文書は、[14496-2]、[14496-3]、および[23003-1]で指定された用語を使用しています。さらに、このドキュメントでは次の用語が使用されており、このドキュメントのコンテキスト内で特定の意味を持っています。
Abbreviations:
略語：
AAC: Advanced Audio Coding
AAC：高度なオーディオコーディング
ASC: AudioSpecificConfig
ASC：audiospecificconfig
HE AAC: High Efficiency AAC
彼はAAC：高効率AAC
LATM: Low-overhead MPEG-4 Audio Transport Multiplex
LATM：低オーバーヘッドMPEG-4オーディオトランスポートマルチプレックス
PS: Parametric Stereo
PS：パラメトリックステレオ
SBR: Spectral Band Replication
SBR：スペクトルバンドの複製
VOP: Video Object Plane
VOP：ビデオオブジェクトプレーン
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
For MPEG-4 Audio [14496-3] streams, the decoder output configuration can differ from the core codec configuration depending of use of the SBR and PS tools.
MPEG-4オーディオ[14496-3]ストリームの場合、デコーダー出力構成は、SBRおよびPSツールの使用に応じてコアコーデック構成とは異なります。
The core codec sampling rate is the default audio codec sampling rate. When SBR is used, typically the double value of the core codec sampling rate will be regarded as the definitive sampling rate (i.e., the decoder's output sampling rate)
コアコーデックサンプリングレートは、デフォルトのオーディオコーデックサンプリングレートです。SBRを使用すると、通常、コアコーデックサンプリングレートの二重値は、決定的なサンプリングレート（つまり、デコーダーの出力サンプリングレート）と見なされます。
Note: The exception is down-sampled SBR mode, in which case the SBR sampling rate and core codec sampling rate are identical.
注：例外はダウンサンプリングされたSBRモードです。この場合、SBRサンプリングレートとコアコーデックサンプリングレートは同一です。
The core codec channel configuration is the default audio codec channel configuration. When PS is used, the core codec channel configuration indicates one channel (i.e., mono) whereas the definitive channel configuration is two channels (i.e. stereo). When MPEG Surround is used, the definitive channel configuration depends on the output of the MPEG Surround decoder.
コアコーデックチャネル構成は、デフォルトのオーディオコーデックチャネル構成です。PSを使用すると、コアコーデックチャネル構成は1つのチャネル（つまり、モノ）を示しますが、決定的なチャネル構成は2つのチャネル（つまり、ステレオ）です。MPEGサラウンドを使用すると、決定的なチャネル構成はMPEGサラウンドデコーダーの出力に依存します。
LATM has several multiplexing features as follows:
LATMには、次のようにいくつかの多重化機能があります。
o carrying configuration information with audio data,
o オーディオデータを使用して構成情報をキャリングし、
o concatenating multiple audio frames in one audio stream,
o 1つのオーディオストリームで複数のオーディオフレームを連結し、
o multiplexing multiple objects (programs), and
o 複数のオブジェクト（プログラム）を多重化します
o multiplexing scalable layers,
o 多重化スケーラブルなレイヤー、
However, 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 streams 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, the signaling mechanism as specified in [RFC5583] SHOULD be used (see Section 6.2).
スケーラブルなストリームを送信するには、各レイヤーのオーディオデータを異なるRTPストリームにパケット化して、例えば、何らかの差別化されたサービスを介して、IPレベルで異なるレイヤーを異なる方法で処理できるようにする必要があります。一方、スケーラブルストリームのすべての構成データは、1つのLATM構成データ「StreamMuxConfig」に含まれており、すべてのスケーラブルレイヤーがStreamMuxConfigを共有しています。各レイヤーとその構成データの間のマッピングは、オーディオデータに添付されたLATMヘッダー情報によって達成されます。スケーラブルストリームの依存関係情報を示すために、[RFC5583]で指定されているシグナル伝達メカニズムを使用する必要があります（セクション6.2を参照）。
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 Subclause 6.2.1, "Start codes", of [14496-2].) The configuration information MAY additionally be specified by some out-of-band means. If needed by systems using media type parameters and SDP parameters, e.g., SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information (see Sections 7.1 and 7.2).
このセクションでは、MPEG-4視覚コンテンツのRTPパケット化ルールを指定します。MPEG-4 Visual BitStreamは、追加のヘッダーフィールドを追加したり、視覚的構文要素を削除することなく、RTPパケットに直接マッピングされます。構成情報が基本ストリームと同じRTPポートに伝達されるように、構成/初等ストリームの組み合わせモードを使用する必要があります。（[14496-2]のsubclause 6.2.1、 "start codes"を参照してください。）構成情報は、いくつかの帯域外の手段でさらに指定される場合があります。メディアタイプパラメーターとSDPパラメーターを使用してシステムで必要な場合は、SIPやRTSPなど、オプションのパラメーター「構成」を使用して構成情報を指定する必要があります（セクション7.1および7.2を参照）。
When the short video header mode is used, the RTP payload format for H.263 SHOULD be used. (The format defined in [RFC4629] is RECOMMENDED, but the [RFC4628] format MAY be used for compatibility with older implementations.)
短いビデオヘッダーモードを使用する場合、H.263のRTPペイロード形式を使用する必要があります。（[RFC4629]で定義されている形式が推奨されますが、[RFC4628]形式は、古い実装との互換性に使用できます。）
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 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).
ペイロードタイプ（PT）：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでは指定されません。特定のクラスのアプリケーションのRTPプロファイルは、このエンコードにペイロードタイプを割り当てるか、またはそれが完了していない場合、ダイナミックレンジのペイロードタイプは、バンド外シグナリングによって選択されるものとすることが期待されます。プロトコル（例：H.245、SIP）。
Extension (X) bit: Defined by the RTP profile used.
拡張機能（x）ビット：使用されるRTPプロファイルによって定義されています。
Sequence Number: Incremented by 1 for each RTP data packet sent, starting, for security reasons, with a random initial value.
シーケンス番号：セキュリティ上の理由で、セキュリティの理由で、ランダムな初期値を使用して、送信された各RTPデータパケットに対して1×1で増加します。
Marker (M) bit: The marker bit is set to 1 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 1.
マーカー（M）ビット：マーカービットは1に設定されており、VOPの最後のRTPパケット（またはRTPパケットのみ）を示します。複数の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のサンプリングインスタンスを示します。ランダムな一定のオフセットがセキュリティ上の理由で追加されます。
o 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 is derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment).
o 複数のVOPが同じRTPパケットで運ばれると、タイムスタンプは、RTPパケットで運ばれるVOP内のVOP時間の初期の時間を示します。残りのVOPSのタイムスタンプ情報は、VOPヘッダーのタイムスタンプフィールド（modulo_time_baseおよびvop_time_increment）から派生しています。
o 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.
o RTPパケットに構成情報および/またはgroup_of_videOObjectplane（）フィールドのみが含まれている場合、コーディング順序の次のVOPのタイムスタンプが使用されます。
o 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.
o RTPパケットにVisual_object_sequence_end_code情報のみが含まれている場合、コーディング順序の直前のVOPのタイムスタンプが使用されます。
The resolution of the timestamp is set to its default value of 90 kHz, unless specified by out-of-band means (e.g., SDP parameter or media type parameter as defined in Section 7).
タイムスタンプの解像度は、帯域外の平均で指定されていない限り、デフォルト値90 kHzに設定されます（例：セクション7で定義されているSDPパラメーターまたはメディアタイプパラメーター）。
Other header fields are used as described in [RFC3550].
他のヘッダーフィールドは、[RFC3550]で説明されているように使用されます。
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.
断片化されたMPEG-4ビジュアルビットストリームは、追加のヘッダーフィールドを追加したり、視覚的構文要素を削除することなく、RTPペイロードに直接マッピングされます。
In the following, header means one of the following:
以下では、ヘッダーは次のいずれかを意味します。
o Configuration information (Visual Object Sequence Header, Visual Object Header, and Video Object Layer Header)
o 構成情報（Visual Object Sequence Header、Visual Object Header、およびビデオオブジェクトレイヤーヘッダー）
o visual_object_sequence_end_code
o Visual_object_sequence_end_code
o 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())
o 初等ストリーム（group_of_videOobjectplane（）のエントリポイント関数のヘッダーまたはvideo objectplane（）、video_plane_with_short_header（）、meshobject（）、またはfaceObject（）のヘッダー
o The video packet header (video_packet_header() excluding next_resync_marker())
o ビデオパケットヘッダー（video_packet_header（）を除くnext_resync_marker（））
o The header of gob_layer()
o gob_layer（）のヘッダー
o See Subclause 6.2.1 ("Start codes") of [14496-2] for the definition of the configuration information and the entry point functions.
o 構成情報とエントリポイント関数の定義については、[14496-2]のサブ6.2.1（ "Start Codes"）を参照してください。
The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation.
組み合わせた構成/初等ストリームモードが使用されます。断片化には、次の規則が適用されます。
(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 1 and the beginning of the RTP payload corresponds to a start code. (See the descriptions of timestamp and marker bit in Section 5.1.)
注：複数のVOPが1つのRTPペイロードで運ばれると、最初のVOPSのタイムスタンプはデコーダーによって計算されます。この操作は、マーカービットが1に等しく、RTPペイロードの開始が開始コードに対応するRTPパケットにのみ必要です。（セクション5.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. If 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, a VOP MAY be split at arbitrary byte positions.
(5) 単一のビデオパケットを単一のRTPパケットとして送信することをお勧めします。ビデオパケットのサイズは、結果のRTPパケットがPATH MTUよりも大きくないように調整する必要があります。ビデオパケットが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 Section 5.2
図2は、セクション5.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 Section 5.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 Payloadの先頭に視覚オブジェクトヘッダーとVideo Object Layer Header（Vo Header、vol Header）の先に配置されます。セクション5.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 VOP header and 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 subsequent VOP can be packetized into a single RTP packet.
(b) 構成情報を含むRTPパケットの別の例です。RTPパケットには、構成情報に従ってVOPにVOPヘッダーとビデオパケットも含まれているという点で、例（a）とは異なります。構成情報の長さは比較的短く（通常はバイトのスコア）、構成情報のみを含むRTPパケットがオーバーヘッドを増加させる可能性があるため、構成情報とその後の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, the following VOP (or a part of it) 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ヘッダーのオーバーヘッドの無駄です。したがって、次のVOP（またはその一部）は、（c）に示すのと同じRTPパケットに配置できます。
(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 bitrate 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 by considering the packet-loss rate and the bitrate 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.
(f) VOLヘッダーでRESYNC_MARKER_DISABLEを1に設定することにより、ビデオパケットが無効になっている場合の例です。この場合、VOPは任意のバイト位置で複数のRTPパケットに分割される場合があります。たとえば、VOPを固定長のパケットに分割することができます。この種のコーダー構成とRTPパケットフラグメンテーションは、基礎となるネットワークがエラーがないことが保証されている場合に使用できます。
Figure 3 shows examples of RTP packets prohibited by the criteria of Section 5.2.
図3は、セクション5.2の基準によって禁止されているRTPパケットの例を示しています。
Fragmentation of a header into multiple RTP packets, as in Figure 3(a), will not only increase the overhead of RTP/IP headers but also decrease the error resiliency. Therefore, it is prohibited by criterion (3).
図3（a）のように、ヘッダーの複数のRTPパケットへの断片化は、RTP/IPヘッダーのオーバーヘッドを増加させるだけでなく、エラーの弾力性を低下させます。したがって、基準（3）によって禁止されています。
When concatenating more than one video packet into an RTP packet, the VOP header or video_packet_header() is not allowed to be placed in the middle of the RTP payload. The packetization as in Figure 2(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ペイロードの中央に配置することは許可されていません。図2（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 | VOP |Video Packet|
|header|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
図3：MPEG-4ビジュアルの禁止されているRTPパケット化の例
This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams MUST be formatted LATM (Low-overhead MPEG-4 Audio Transport Multiplex) [14496-3] streams, and the LATM-based streams are then mapped onto RTP packets as described in the sections below.
このセクションでは、MPEG-4オーディオビットストリームのRTPパケット化ルールを指定します。MPEG-4オーディオストリームは、以下のセクションで説明されているように、LATMベースのストリームをRATMベースのストリームをRTPパケットにマッピングします。
LATM-based streams consist of a sequence of audioMuxElements that include one or more PayloadMux elements that carry the 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つ以上のPayloadMux要素を含む一連の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 out-of-band means. When SDP is utilized for this indication, the media type parameter "cpresent" corresponds to the muxConfigPresent information (see Section 7.3). The following restrictions apply:
audiOmuxelementをデコードするには、以下のmuxconfigpresent情報を帯域外の手段で示す必要があります。この表示にSDPが利用されると、メディア型パラメーター「cpresent」はmuxconfigpresent情報に対応します（セクション7.3を参照）。次の制限が適用されます。
o In the out-of-band configuration case, the number of PayloadMux elements contained in each audioMuxElement can only be set once. If more than one PayloadMux element is contained in each audioMuxElement, special care is required to ensure that the last RTP packet remains decodable.
o 帯域外構成の場合、各audioMuxelementに含まれるPayloadMux要素の数は1回しか設定できません。各AudiOmuxelementに複数のPayloadMux要素が含まれている場合、最後のRTPパケットがデコード可能なままであることを確認するために特別な注意が必要です。
o To construct the audioMuxElement in the in-band configuration case, non-octet-aligned configuration data is inserted immediately before the one or more PayloadMux elements. Since the generation of RTP payloads with non-octet-aligned data is not possible with RTP hint tracks, as defined by the MP4 file format [14496-12] [14496-14], this document does not support RTP hint tracks for the in-band configuration case.
o 帯域内構成の場合にaudiOmuxelementを構築するために、1つ以上のPayloadMux要素の直前に、オクセットに整合していない構成データが挿入されます。MP4ファイル形式[14496-12] [14496-14]で定義されているように、RTPヒントトラックでは、非オクテット整列データを使用したRTPペイロードの生成は不可能であるため、このドキュメントはRTPヒントトラックをサポートしていません。 - バンド構成ケース。
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-of-band mode), the StreamMuxConfig element is required to be transmitted by an out-of-band means. In case of SDP, the media type parameter "config" is utilized (see Section 7.3).
MuxConfigPresent：この値が1（インバンドモード）に設定されている場合、AudiOmuxElementには表示ビット「USESAMESTREAMMUX」が含まれ、オーディオ圧縮「StreamMuxConfig」の構成情報が含まれる場合があります。USESAMESTREAMMUXビットは、前のフレームのStreamMuxConfig要素が現在のフレームに適用されているかどうかを示します。UseSamestreamMuxビットが前のフレームからStreamMuxConfigを使用することを示しているが、前のフレームが失われた場合、現在のフレームがデコードできない場合があります。したがって、インバンドモードの場合、StreamMuxConfig要素は、ネットワーク条件に応じて繰り返し送信する必要があります。一方、MuxConfigPresentが0（帯域外モード）に設定されている場合、StreamMuxConfig要素は帯域外の手段で送信する必要があります。SDPの場合、メディアタイプパラメーター「構成」が利用されます（セクション7.3を参照）。
Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will only be restricted 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). In the dynamic assignment of RTP payload types for scalable streams, the server SHALL assign a different value to each layer. The dependency relationships between the enhanced layer and the base layer MUST be signaled as specified in [RFC5583]. An example of the use of such signaling for scalable audio streams can be found in [RFC5691].
ペイロードタイプ（PT）：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外であり、ここでのみ制限されます。特定のクラスのアプリケーションのRTPプロファイルは、このエンコードにペイロードタイプを割り当てるか、またはそれが完了していない場合、ダイナミックレンジのペイロードタイプは、バンド外シグナリングによって選択されるものとすることが期待されます。プロトコル（例：H.245、SIP）。スケーラブルなストリームのRTPペイロードタイプの動的割り当てでは、サーバーは各レイヤーに異なる値を割り当てるものとします。[RFC5583]で指定されているように、強化された層と基本層の間の依存関係を信号にする必要があります。スケーラブルなオーディオストリームにそのようなシグナリングを使用する例は、[RFC5691]に記載されています。
Marker (M) bit: The marker bit indicates audioMuxElement boundaries. It is set to 1 to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement.
マーカー（M）ビット：マーカービットは、オーディオムクサーメントの境界を示します。RTPパケットには完全なオーディオムクサーメントまたはaudiOmuxelementの最後のフラグメントが含まれていることを示すために1に設定されています。
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 1 for each RTP packet sent, starting, for security reasons, with a random value.
シーケンス番号：セキュリティ上の理由からランダムな値で、送信されたRTPパケットごとに1×1で増加します。
Other header fields are used as described in [RFC3550].
他のヘッダーフィールドは、[RFC3550]で説明されているように使用されます。
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 SHALL be fragmented and spread across multiple packets.
各RTPパケットに1つのAudiOmuxelementを入れることをお勧めします。AudiOmuxelementのサイズを十分に小さく保つことができ、それを含むRTPパケットのサイズがパスMTUのサイズを超えない場合、これは問題ありません。できない場合、AudiOmuxelementは断片化され、複数のパケットに広がるものとします。
The following sections describe the media type registrations for MPEG-4 Audio/Visual streams, which are registered in accordance with [RFC4855] and use the template of [RFC4288]. Media type registration and SDP usage for the MPEG-4 Visual stream are described in Sections 7.1 and 7.2, respectively, while media type registration and SDP usage for MPEG-4 Audio stream are described in Sections 7.3 and 7.4, respectively.
次のセクションでは、[RFC4855]に従って登録されており、[RFC4288]のテンプレートを使用するMPEG-4オーディオ/ビジュアルストリームのメディアタイプ登録について説明します。MPEG-4の視覚ストリームのメディアタイプの登録とSDPの使用は、それぞれセクション7.1と7.2で説明されていますが、MPEG-4オーディオストリームのメディアタイプの登録とSDPの使用は、それぞれセクション7.3および7.4で説明されています。
The receiver MUST ignore any unspecified parameter in order to ensure that additional parameters can be added in any future revision of this specification.
受信機は、この仕様の将来の改訂で追加のパラメーターを追加できるようにするために、不特定のパラメーターを無視する必要があります。
Type name: video
タイプ名：ビデオ
Subtype name: MP4V-ES
サブタイプ名：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 (90 kHz) is used.
「レート」：このパラメーターは、RTPトランスポートにのみ使用されます。RTPヘッダーのタイムスタンプフィールドの解像度を示します。このパラメーターが指定されていない場合、90000（90 kHz）のデフォルト値が使用されます。
"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 [14496-2]. This parameter MAY be used in the capability exchange or session setup procedure to indicate the 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」：[14496-2]の表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 [14496-2]. The configuration information is mapped onto the octet string most significant bit (MSB) first. 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 they exist), which may vary in the repeated configuration information inside an MPEG-4 Visual stream. (See Subclause 6.2.1, "Start codes", of [14496-2].)
「構成」：このパラメーターは、対応するMPEG-4 Visual BitStreamの構成を示すために使用するものとします。機能交換手順でコーデック機能を示すために使用してはなりません。これは、[14496-2]のサブ6.2.1（「開始コード」）で定義されているように、MPEG-4視覚構成情報を表すオクテット文字列の16進表現です。構成情報は、最初にOctet文字列の最も重要なビット（MSB）にマッピングされます。構成情報の最初のビットは、最初のオクテットのMSBに配置するものとします。このパラメーターで示されている構成情報は、First_Half_vbv_occupancyと後期_half_vvv_occupancy（存在する場合）を除き、対応するMPEG-4視覚ストリームの構成情報と同じでなければなりません。。（[14496-2]のsubclause 6.2.1、 "start codes"を参照してください。）
Published specification:
公開された仕様：
The specifications for MPEG-4 Visual streams are presented in [14496-2]. The RTP payload format is described in [RFC6416].
MPEG-4の視覚ストリームの仕様は[14496-2]に示されています。RTPペイロード形式は[RFC6416]で説明されています。
Encoding considerations:
考慮事項のエンコード：
Video bitstreams MUST be generated according to MPEG-4 Visual specifications [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 [RFC6416].
ビデオビットストリームは、MPEG-4の視覚仕様[14496-2]に従って生成する必要があります。ビデオビットストリームはバイナリデータであり、非バイナリトランスポート用にエンコードする必要があります（電子メールの場合、Base64エンコードで十分です）。このタイプは、RTPを介した転送用にも定義されています。RTPパケットは、[RFC6416]で定義されているMPEG-4 Visual RTPペイロード形式に従ってパケット化する必要があります。
Security considerations:
セキュリティ上の考慮事項：
See Section 10 of [RFC6416].
[RFC6416]のセクション10を参照してください。
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つ以上のレベルが設定されます。プロファイル@レベルの組み合わせにより：
* 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
* 同じ組み合わせに含まれる他のMPEG-4デバイスとのインターワーキングを維持しながら、必要な標準のサブセットのみを実装するためのコーデックビルダーと
* checking whether MPEG-4 devices comply with the standard ('conformance testing').
* 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" or by arranging a capability exchange/announcement procedure for this parameter.
視覚ストリームは、パラメーター「プロファイルレベルID」で指定されたMPEG-4 Visual Profile@レベルに準拠するものとします。送信者と受信機の間の相互運用性は、パラメーター「プロファイルレベルID」を指定するか、このパラメーターの機能交換/アナウンス手順を配置することによって達成できます。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio and visual streaming and conferencing tools
オーディオおよびビジュアルストリーミングおよび会議ツール
Additional information: none
追加情報：なし
Person and email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
See Authors' Addresses section at the end of [RFC6416].
[RFC6416]の最後にある著者のアドレスセクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Author:
著者：
See Authors' Addresses section at the end of [RFC6416].
[RFC6416]の最後にある著者のアドレスセクションを参照してください。
Change controller:
コントローラーの変更：
IETF Audio/Video Transport Payloads working group delegated from the IESG.
IETFオーディオ/ビデオトランスポートペイロードIESGから委任されたワーキンググループ。
The media type video/MP4V-ES string is mapped to fields in SDP [RFC4566], as follows:
メディアタイプのビデオ/MP4V-ES文字列は、次のように、SDP [RFC4566]のフィールドにマッピングされます。
o The media type (video) goes in SDP "m=" as the media name.
o メディアタイプ（ビデオ）は、メディア名としてSDP "M ="で入手します。
o The Media subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding name.
o メディアサブタイプ（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 string, in the form of a semicolon-separated list of parameter=value pairs.
o オプションのパラメーター「プロファイルレベルID」と「構成」は、それぞれ「A = FMTP」行に移動し、それぞれコーダーの機能と構成を示します。これらのパラメーターは、パラメーター=値のペアの半象徴的なリストの形式で、文字列として表されます。
Example usages for the "profile-level-id" parameter are: 1 : MPEG-4 Visual Simple Profile/Level 1 34 : MPEG-4 Visual Core Profile/Level 2 145: MPEG-4 Visual Advanced Real Time Simple Profile/Level 1
「プロファイルレベルID」パラメーターの使用例は次のとおりです。1：MPEG-4ビジュアルシンプルプロファイル/レベル1 34：MPEG-4ビジュアルコアプロファイル/レベル2 145：MPEG-4ビジュアルアドバンスリアルタイムシンプルプロファイル/レベル1
The following are some examples of media representations in SDP:
以下は、SDPのメディア表現の例です。
Simple Profile/Level 1, rate=90000(90 kHz), "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=000001B001000001B50900000100000
00120008440FA282C2090A21F
Core Profile/Level 2, rate=90000(90 kHz), "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(90 kHz),
"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
The receiver MUST ignore any unspecified parameter, to ensure that additional parameters can be added in any future revision of this specification.
受信者は、この仕様の将来の改訂で追加のパラメーターを追加できるように、不特定のパラメーターを無視する必要があります。
Type name: audio
タイプ名：オーディオ
Subtype name: MP4A-LATM
サブタイプ名：MP4A-LATM
Required parameters:
必要なパラメーター：
"rate": the "rate" parameter indicates the RTP timestamp "clock rate". The default value is 90000. Other rates MAY be indicated only if they are set to the same value as the audio sampling rate (number of samples per second).
「レート」：「レート」パラメーターは、RTPタイムスタンプ「クロックレート」を示します。デフォルト値は90000です。その他のレートは、オーディオサンプリングレート（秒あたりのサンプル数）と同じ値に設定されている場合にのみ示される場合があります。
In the presence of SBR, the sampling rates for the core encoder/ decoder and the SBR tool are different in most cases. Therefore, this parameter SHALL NOT be considered as the definitive sampling rate. If this parameter is used, the server must follow the rules below:
SBRの存在下では、コアエンコーダー/デコーダーとSBRツールのサンプリングレートは、ほとんどの場合異なります。したがって、このパラメーターは、決定的なサンプリングレートと見なされません。このパラメーターを使用する場合、サーバーは以下のルールに従う必要があります。
* When the presence of SBR is not explicitly signaled by the optional SDP parameters such as "object", "profile-level-id", or "config", this parameter SHALL be set to the core codec sampling rate.
* SBRの存在が、「オブジェクト」、「プロファイルレベルID」、または「config」などのオプションのSDPパラメーターによって明示的にシグナルがない場合、このパラメーターはコアコーデックサンプリングレートに設定されます。
* When the presence of SBR is explicitly signaled by the optional SDP parameters such as "object", "profile-level-id", or "config", this parameter SHALL be set to the SBR sampling rate.
* SBRの存在が、「オブジェクト」、「プロファイルレベルID」、または「config」などのオプションのSDPパラメーターによって明示的に信号を送られる場合、このパラメーターはSBRサンプリングレートに設定されます。
NOTE: The optional parameter "SBR-enabled" in SDP "a=fmtp" is useful for implicit HE AAC / HE AAC v2 signaling. But the "SBR-enabled" parameter can also be used in the case of explicit HE AAC / HE AAC v2 signaling. Therefore, its existence (in itself) is not the criteria to determine whether or HE AAC / HE AAC v2 signaling is explicit.
注：SDPのオプションパラメーター「SBR対応」 "a = fmtp"は、暗黙のHe Aac / He Aac V2シグナル伝達に役立ちます。ただし、「SBR対応」パラメーターは、明示的なHE AAC / HE AAC V2シグナル伝達の場合にも使用できます。したがって、その存在は（それ自体）存在は、aac / he aac v2シグナル伝達が明示的かどうかを判断する基準ではありません。
Optional parameters:
オプションのパラメーター：
"profile-level-id": a decimal representation of MPEG-4 Audio Profile Level indication value defined in [14496-3]. 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」：[14496-3]で定義されているMPEG-4オーディオプロファイルレベルの表示値の10進表現。このパラメーターは、デコーダーが使用できるMPEG-4オーディオツールサブセットを示します。このパラメーターが機能交換またはセッションのセットアップ手順で指定されていない場合、そのデフォルト値は30（ナチュラルオーディオプロファイル/レベル1）が使用されます。
"MPS-profile-level-id": a decimal representation of the MPEG Surround Profile Level indication as defined in [14496-3]. This parameter indicates the support of the MPEG Surround profile and level by the decoder to be capable to decode the stream.
「MPS-Profile-Level-ID」：[14496-3]で定義されているMPEGサラウンドプロファイルレベルの表示の小数表現。このパラメーターは、MPEGサラウンドプロファイルのサポートとデコーダーによるレベルを示し、ストリームをデコードできるようにします。
"object": a decimal representation of the MPEG-4 Audio Object Type value defined in [14496-3]. This parameter specifies the tool to be used by the decoder. It CAN be used to limit the capability within the specified "profile-level-id".
「オブジェクト」：[14496-3]で定義されているMPEG-4オーディオオブジェクトタイプ値の10進表現。このパラメーターは、デコーダーが使用するツールを指定します。指定された「プロファイルレベルID」内の機能を制限するために使用できます。
"bitrate": the data rate for the audio bitstream.
「Bitrate」：オーディオビットストリームのデータレート。
"cpresent": a boolean parameter that indicates whether audio payload configuration data has been multiplexed into an RTP payload (see Section 6.1). A 0 indicates the configuration data has not been multiplexed into an RTP payload, and in that case, the "config" parameter MUST be present; a 1 indicates that it has been multiplexed. The default if the parameter is omitted is 1. If this parameter is set to 1 and the "config" parameter is present, the multiplexed configuration data and the value of the "config" parameter SHALL be consistent.
「cpresent」：オーディオペイロード構成データがRTPペイロードに多重化されているかどうかを示すブールパラメーター（セクション6.1を参照）。0は、構成データがRTPペイロードに多重化されていないことを示し、その場合、「構成」パラメーターが存在する必要があります。A 1は、それが多重化されていることを示します。パラメーターが省略されている場合のデフォルトは1です。このパラメーターが1に設定され、「config」パラメーターが存在する場合、多重化された構成データと「config」パラメーターの値は一貫しています。
"config": a hexadecimal representation of an octet string that expresses the audio payload configuration data "StreamMuxConfig", as defined in [14496-3]. 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. Senders MUST set the StreamMuxConfig elements taraBufferFullness and latmBufferFullness to their largest respective value, indicating that buffer fullness measures are not used in SDP. Receivers MUST ignore the value of these two elements contained in the "config" parameter.
「構成」：[14496-3]で定義されているように、オーディオペイロード構成データ「StreamMuxConfig」を表現するオクテット文字列の16進表現。構成データは、MSBファーストベースでOctet文字列にマッピングされます。構成データの最初のビットは、最初のオクテットのMSBに配置するものとします。最後のオクテットでは、必要に応じてゼロパディングビットが構成データに従うものとします。送信者は、StreamMuxConfig要素をタラバッファフルネスとラテンバッファフルネスを最大の値に設定する必要があります。受信機は、「構成」パラメーターに含まれるこれら2つの要素の値を無視する必要があります。
"MPS-asc": a hexadecimal representation of an octet string that expresses audio payload configuration data "AudioSpecificConfig", as defined in [14496-3]. If this parameter is not present, the relevant signaling is performed by other means (e.g., in-band or contained in the "config" string).
「MPS-ASC」：[14496-3]で定義されているように、オーディオペイロード構成データ「AudiospecificConfig」を表現するオクテット文字列の16進表現。このパラメーターが存在しない場合、関連するシグナル伝達は他の手段によって実行されます（たとえば、帯域内または「config」文字列に含まれます）。
The same mapping rules as for the "config" parameter apply.
「構成」パラメーターと同じマッピングルールが適用されます。
"ptime": duration of each packet in milliseconds.
「PTIME」：各パケットの期間はミリ秒単位で。
"SBR-enabled": a boolean parameter that indicates whether SBR-data can be expected in the RTP-payload of a stream. This parameter is relevant for an SBR-capable decoder if the presence of SBR cannot be detected from an out-of-band decoder configuration (e.g., contained in the "config" string).
「SBR対応」：SBR-DATAがストリームのRTPペイロードで予想されるかどうかを示すブールパラメーター。このパラメーターは、SBRの存在を帯域外デコーダー構成（たとえば、「config」文字列に含まれる）から検出できない場合、SBR対応デコーダーに関連しています。
If this parameter is set to 0, a decoder MAY expect that SBR is not used. If this parameter is set to 1, a decoder CAN up-sample the audio data with the SBR tool, regardless of whether or not SBR data is present in the stream.
このパラメーターが0に設定されている場合、デコーダーはSBRが使用されないことを期待する場合があります。このパラメーターが1に設定されている場合、SBRデータがストリームに存在するかどうかに関係なく、デコーダーはSBRツールでオーディオデータをアップサンプリングできます。
If the presence of SBR cannot be detected from out-of-band configuration and the "SBR-enabled" parameter is not present, the parameter defaults to 1 for an SBR-capable decoder. If the resulting output sampling rate or the computational complexity is not supported, the SBR tool can be disabled or run in down-sampled mode.
SBRの存在を帯域外構成から検出できず、「SBR対応」パラメーターが存在しない場合、SBR対応デコーダーのパラメーターはデフォルト1になります。結果の出力サンプリングレートまたは計算の複雑さがサポートされていない場合、SBRツールを無効にしたり、ダウンサンプリングモードで実行したりできます。
The timestamp resolution at the RTP layer is determined by the "rate" parameter.
RTPレイヤーのタイムスタンプ解像度は、「レート」パラメーターによって決定されます。
Published specification:
公開された仕様：
Encoding specifications are provided in [14496-3]. The RTP payload format specification is described in [RFC6416].
エンコード仕様は[14496-3]に記載されています。RTPペイロード形式の仕様は[RFC6416]で説明されています。
Encoding considerations:
考慮事項のエンコード：
This type is only defined for transfer via RTP.
このタイプは、RTPを介した転送に対してのみ定義されます。
Security considerations:
セキュリティ上の考慮事項：
See Section 10 of [RFC6416].
[RFC6416]のセクション10を参照してください。
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 7.1).
MPEG-4オーディオは、オーディオオブジェクトのコーディング用の大規模でリッチなツールセットを提供します。標準の効果的な実装のために、MPEG-4ビジュアルで使用されるものと同様のMPEG-4オーディオツールセットのサブセットが提供されています（セクション7.1を参照）。
The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ Level specified by the parameters "profile-level-id" and "MPS-profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameters "profile-level-id" and "MPS-profile-level-id" or by arranging in the capability exchange procedure to set this parameter mutually
オーディオストリームは、パラメーター「プロファイルレベルID」および「MPS-Profile-Level-ID」で指定されたMPEG-4オーディオプロファイル@レベルに準拠するものとします。送信者とレシーバー間の相互運用性は、パラメーター「プロファイルレベルID」と「MPS-Profile-Level-ID」を指定するか、このパラメーターを相互に設定する機能交換手順を配置することにより、達成できます。
to the same value. Furthermore, the "object" parameter can be used to limit the capability within the specified Profile@Level in the capability exchange.
同じ値に。さらに、「オブジェクト」パラメーターを使用して、機能交換の指定されたプロファイル@レベル内の機能を制限できます。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio and video streaming and conferencing tools.
オーディオおよびビデオストリーミングおよび会議ツール。
Additional information: none
追加情報：なし
Personal and email address to contact for further information:
詳細については、お問い合わせの個人およびメールアドレス：
See Authors' Addresses section at the end of [RFC6416].
[RFC6416]の最後にある著者のアドレスセクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Author:
著者：
See Authors' Addresses section at the end of [RFC6416].
[RFC6416]の最後にある著者のアドレスセクションを参照してください。
Change controller:
コントローラーの変更：
IETF Audio/Video Transport Payloads working group delegated from the IESG.
IETFオーディオ/ビデオトランスポートペイロードIESGから委任されたワーキンググループ。
The media type audio/MP4A-LATM string is mapped to fields in SDP [RFC4566], as follows:
メディアタイプのオーディオ/MP4A-LATM文字列は、次のように、SDP [RFC4566]のフィールドにマッピングされます。
o The media type (audio) goes in SDP "m=" as the media name.
o メディアタイプ（オーディオ）は、メディア名としてSDP "M ="で入ります。
o The Media subtype (MP4A-LATM) goes in SDP "a=rtpmap" as the encoding name.
o メディアサブタイプ（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 parameters "profile-level-id", "MPS-profile-level-id", and "object" go in the "a=fmtp" line to indicate the coder capability.
o オプションのパラメーター「プロファイルレベルID」、「MPS-Profile-Level-ID」、および「オブジェクト」は、「A = FMTP」行に移動して、コーダーの機能を示します。
The following are some examples of the "profile-level-id" value: 1 : Main Audio Profile Level 1 9 : Speech Audio Profile Level 1 15: High Quality Audio Profile Level 2 30: Natural Audio Profile Level 1 44: High Efficiency AAC Profile Level 2 48: High Efficiency AAC v2 Profile Level 2 55: Baseline MPEG Surround Profile (see ISO/IEC 23003-1) Level 3
以下は、「プロファイルレベルID」値の例：1：メインオーディオプロファイルレベル1 9：スピーチオーディオプロファイルレベル1 15：高品質のオーディオプロファイルレベル2 30：ナチュラルオーディオプロファイルレベル1 44：高効率AACプロファイルレベル2 48：高効率AAC V2プロファイルレベル2 55：ベースラインMPEGサラウンドプロファイル（ISO/IEC 23003-1を参照）レベル3
The optional payload-format-specific parameters "bitrate", "cpresent", "config", "MPS-asc", and "SBR-enabled" also go in the "a=fmtp" line. These parameters are expressed as a string, in the form of a semicolon-separated list of parameter=value pairs.
オプションのペイロード形式固有のパラメーター「ビットレート」、「cpresent」、「config」、「mps-asc」、および「sbr対応」も「A = fmtp」行に移動します。これらのパラメーターは、パラメーター=値のペアの半象徴的なリストの形式で、文字列として表されます。
The following sections contain some examples of the media representation in SDP.
次のセクションには、SDPのメディア表現の例がいくつか含まれています。
Note that the "a=fmtp" line in some of the examples has been wrapped to fit the page; they would comprise a single line in the SDP file.
いくつかの例の「a = fmtp」行は、ページに適合するようにラップされていることに注意してください。それらは、SDPファイルの単一行を構成します。
In this example, the audio configuration data appears in the RTP payload exclusively (i.e., the MPEG-4 audio configuration is known when a StreamMuxConfig element appears within the RTP payload).
この例では、オーディオ構成データはRTPペイロードのみに表示されます（つまり、MPEG-4オーディオ構成は、RTPペイロード内にStreamMuxConfig要素が表示されるときに知られています）。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 object=2; cpresent=1
The "clock rate" is set to 90 kHz. This is the default value, and the real audio sampling rate is known when the audio configuration data is received.
「クロックレート」は90 kHzに設定されています。これはデフォルト値であり、オーディオ構成データを受信したときに実際のオーディオサンプリングレートがわかっています。
This example shows a 6 kbit/s CELP (Code-Excited Linear Prediction) bitstream (with an audio sampling rate of 8 kHz).
この例は、6 kbit/s CELP（コード励起線形予測）ビットストリーム（オーディオサンプリングレート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=40008B18388380
a=ptime:20
In this example, 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.
この例では、オーディオ構成データはRTPペイロードに多重化されておらず、SDPでのみ説明されています。さらに、「クロックレート」はオーディオサンプリングレートに設定されます。
This example shows a 64 kbit/s AAC LC stereo bitstream (with an audio sampling rate of 24 kHz).
この例は、64 Kbit/s AAC LCステレオビットストリーム（24 kHzのオーディオサンプリングレートを含む）を示しています。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000/2
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
object=2; config=400026203fc0
In this example, 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.
この例では、オーディオ構成データはRTPペイロードに多重化されておらず、SDPでのみ説明されています。さらに、「クロックレート」はオーディオサンプリングレートに設定されます。
In this example, the presence of SBR cannot be determined by the SDP parameter set. The "clock rate" represents the core codec sampling rate. An SBR-enabled decoder can use the SBR tool to up-sample the audio data if the complexity and resulting output sampling rate permit.
この例では、SBRの存在はSDPパラメーターセットでは決定できません。「クロックレート」は、コアコーデックサンプリングレートを表します。SBR対応デコーダーは、SBRツールを使用して、複雑さと結果の出力サンプリングレート許可の場合、オーディオデータをアップサンプリングできます。
These two examples are identical to the example above with the exception of the "SBR-enabled" parameter. The presence of SBR is not signaled by the SDP parameters "object", "profile-level-id", and "config", but instead the "SBR-enabled" parameter is present. The "rate" parameter and the StreamMuxConfig contain the core codec sampling rate.
これらの2つの例は、「SBR対応」パラメーターを除き、上記の例と同じです。SBRの存在は、SDPパラメーター「オブジェクト」、「プロファイルレベルID」、および「config」ではなく、「SBR対応」パラメーターが存在します。「レート」パラメーターとStreamMuxConfigには、コアコーデックサンプリングレートが含まれています。
This example shows "SBR-enabled=0", with definitive and core codec sampling rates of 24 kHz.
この例は、24 kHzの決定的およびコアコーデックサンプリングレートを持つ「SBR対応= 0」を示しています。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000/2
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
SBR-enabled=0; config=400026203fc0
This example shows "SBR-enabled=1", with core codec sampling rate of 24 kHz, and definitive and SBR sampling rates of 48 kHz:
この例は、コアコーデックサンプリングレートが24 kHzで、48 kHzの決定的およびSBRサンプリングレートを持つ「SBR対応= 1」を示しています。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000/2
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
SBR-enabled=1; config=400026203fc0
In this example, the "clock rate" is still 24000, and this information is used for RTP timestamp calculation. The value of 24000 is used to support old AAC decoders. This makes the decoder supporting only AAC understand the HE AAC coded data, although only plain AAC is supported. A HE AAC decoder is able to generate output data with the SBR sampling rate.
この例では、「クロックレート」はまだ24000であり、この情報はRTPタイムスタンプの計算に使用されます。24000の値は、古いAACデコーダーをサポートするために使用されます。これにより、AACのみをサポートするデコーダーがHE AACコード化されたデータを理解しますが、プレーンAACのみがサポートされています。A He AACデコーダーは、SBRサンプリングレートで出力データを生成できます。
When the presence of SBR is explicitly signaled by the SDP parameters "object", "profile-level-id", or "config", as in the example below, the StreamMuxConfig contains both the core codec sampling rate and the SBR sampling rate.
SBRの存在が、以下の例のように、SDPパラメーター「オブジェクト」、「プロファイルレベルID」、または「config」によって明示的にシグナルとされる場合、StreamMuxConfigにはコアコーデックサンプリングレートとSBRサンプリングレートの両方が含まれています。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000/2
a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0;
config=40005623101fe0; SBR-enabled=1
This "config" string uses the explicit signaling mode 2.A (hierarchical signaling; see [14496-3]. This means that the AOT (Audio Object Type) is SBR (5) and SFI (Sampling Frequency Index) is 6 (24000 Hz), which refers to the underlying core codec sampling frequency. CC (Channel Configuration) is stereo (2), and the ESFI (Extension Sampling Frequency Index)=3 (48000) is referring to the sampling frequency of the extension tool (SBR).
この「構成」文字列は、明示的なシグナル伝達モード2を使用します（階層シグナル伝達; [14496-3]を参照してください。これは、AOT（オーディオオブジェクトタイプ）がSBR（5）およびSFI（サンプリング周波数インデックス）が6（24000）であることを意味します。Hz）は、基礎となるコアコーデックサンプリング周波数を指します。CC（チャネル構成）はステレオ（2）であり、ESFI（拡張サンプリング周波数インデックス）= 3（48000）は、拡張ツールのサンプリング周波数を指します（SBR（SBR））。
HE AAC v2 decoders are required to always produce a stereo signal from a mono signal. Hence, there is no parameter necessary to signal the presence of PS.
HE AAC V2デコーダは、モノ信号から常にステレオ信号を生成する必要があります。したがって、PSの存在を知らせるために必要なパラメーターはありません。
This example shows "SBR-enabled=1" with 1 channel signaled in the "a=rtpmap" line and within the "config" parameter. The core codec sampling rate is 24 kHz; the definitive and SBR sampling rates are 48 kHz. The core codec channel configuration is mono; the PS channel configuration is stereo.
この例は、「a = rtpmap」行および「config」パラメーター内で1つのチャネルが信号を送られた「sbr-exabled = 1」を示しています。コアコーデックサンプリングレートは24 kHzです。決定的およびSBRサンプリングレートは48 kHzです。コアコーデックチャネルの構成はモノです。PSチャネル構成はステレオです。
m=audio 49230 RTP/AVP 110
a=rtpmap:110 MP4A-LATM/24000/1
a=fmtp:110 profile-level-id=15; object=2; cpresent=0;
config=400026103fc0; SBR-enabled=1
This example shows 48 kHz stereo audio input.
この例は、48 kHzステレオオーディオ入力を示しています。
m=audio 49230 RTP/AVP 110
a=rtpmap:110 MP4A-LATM/48000/2
a=fmtp:110 profile-level-id=48; cpresent=0; config=4001d613101fe0
The "config" parameter indicates explicit hierarchical signaling of PS and SBR. This configuration method is not supported by legacy AAC an HE AAC decoders, and these are therefore unable to decode the coded data.
「構成」パラメーターは、PSおよびSBRの明示的な階層シグナル伝達を示します。この構成方法は、Legacy AAC an He AACデコーダーによってサポートされていないため、これらはコード化されたデータをデコードできません。
The following examples show how MPEG Surround configuration data can
be signaled using SDP. The configuration is carried within the
"config" string in the first example by using two different layers.
The general parameters in this example are: AudioMuxVersion=1;
allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0;
numLayer=1. The first layer describes the HE AAC payload and signals
the following parameters: ascLen=25; audioObjectType=2 (AAC LC);
extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=6 (24 kHz);
extensionSamplingFrequencyIndex=3 (48 kHz); channelConfiguration=2
(2.0 channels). The second layer describes the MPEG Surround payload
and specifies the following parameters: ascLen=110;
AudioObjectType=30 (MPEG Surround); samplingFrequencyIndex=3 (48
kHz); channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1;
SpatialSpecificConfig=(48 kHz; 32 slots; 525 tree; ResCoding=1;
ResBands=[7,7,7,7]).
In this example, the signaling is carried by using two different LATM layers. The MPEG Surround payload is carried together with the AAC payload in a single layer as indicated by the sacPayloadEmbedding Flag.
この例では、2つの異なるLATMレイヤーを使用してシグナル伝達が運ばれます。MPEGサラウンドペイロードは、SACPAYLOADEMBEDDINGフラグで示されているように、単一層のAACペイロードと一緒に運ばれます。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
SBR-enabled=1;
config=8FF8004192B11880FF0DDE3699F2408C00536C02313CF3CE0FF0
The following example is an extension of the configuration given above by the MPEG-Surround-specific parameters. The "MPS-asc" parameter specifies the MPEG Surround Baseline Profile at Level 3 (PLI55), and the "MPS-asc" string contains the hexadecimal
次の例は、MPEG-Surround固有のパラメーターによって上記の構成の拡張です。「MPS-ASC」パラメーターは、レベル3（PLI55）のMPEGサラウンドベースラインプロファイルを指定し、「MPS-ASC」文字列には16進数が含まれています。
representation of the MPEG Surround ASC [audioObjectType=30 (MPEG
Surround); samplingFrequencyIndex=0x3 (48 kHz);
channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1;
SpatialSpecificConfig=(48 kHz; 32 slots; 525 tree; ResCoding=1;
ResBands=[0,13,13,13])].
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000
a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0;
config=40005623101fe0; MPS-profile-level-id=55;
MPS-asc=F1B4CF920442029B501185B6DA00;
The following example shows how MPEG Surround configuration data can
be signaled using the SDP "config" parameter. The configuration is
carried within the "config" string using a single layer. The general
parameters in this example are: AudioMuxVersion=1;
allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0;
numLayer=0. The single layer describes the combination of HE AAC and
MPEG Surround payload and signals the following parameters:
ascLen=101; audioObjectType=2 (AAC LC); extensionAudioObjectType=5
(SBR); samplingFrequencyIndex=7 (22.05 kHz);
extensionSamplingFrequencyIndex=7 (44.1 kHz); channelConfiguration=2
(2.0 channels). A backward-compatible extension according to
[14496-3/Amd.1] signals the presence of MPEG Surround payload data
and specifies the following parameters: SpatialSpecificConfig=(44.1
kHz; 32 slots; 525 tree; ResCoding=0).
In this example, the signaling is carried by using a single LATM layer. The MPEG Surround payload is carried together with the HE AAC payload in a single layer.
この例では、シグナリングは単一のLATM層を使用して運ばれます。MPEGサラウンドペイロードは、単一層のHe AACペイロードと一緒に運ばれます。
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/44100
a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0;
SBR-enabled=1; config=8FF8000652B920876A83A1F440884053620FF0;
MPS-profile-level-id=55
This document updates the media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in Sections 7.1 and 7.3 of this document.
このドキュメントは、RFC 3016のメディアサブタイプ「MP4A-LATM」と「MP4V-ES」を更新します。新しい登録は、このドキュメントのセクション7.1および7.3にあります。
The authors would like to thank Yoshihiro Kikuchi, Yoshinori Matsui, Toshiyuki Nomura, Shigeru Fukunaga, and Hideaki Kimata for their work on RFC 3016, and Ali Begen, Keith Drage, Roni Even, and Qin Wu for their valuable input and comments on this document.
著者は、RFC 3016、アリ・ベゲン、キース・ドレイジ、ロニ・均一、そしてキン・ウーのコメントについて、この文書でのコメントとコメントについて、アリ・ベゲン、キース・ドレイジ、キン・ドレイジ、そしてキス・ドレイジの仕事をしてくれたヨシヒロ・キクチ、松井吉井、野郎、福田清、ムイガーキ・キマタに感謝したいと思います。。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this document are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload, and integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. A cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and (at least) source authentication capable of determining whether or not an RTP packet is from a member of the RTP session.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]および該当するRTPプロファイルで説明されているセキュリティに関する考慮事項の対象となります。このドキュメント内で定義されているRTPペイロードフォーマットを運ぶRTPパケットの主なセキュリティ上の考慮事項は、機密性、整合性、およびソースの信頼性です。機密性は、RTPペイロードの暗号化によって達成され、RTPパケットの整合性は、適切な暗号整合性保護メカニズムを通じて達成されます。暗号化システムは、ペイロードのソースの認証を可能にする場合があります。このRTPペイロード形式の適切なセキュリティメカニズムは、RTPパケットがRTPセッションのメンバーからのものであるかどうかを判断できる機密性、整合性保護、および（少なくとも）ソース認証を提供する必要があります。
Note that most MPEG-4 codecs define an extension mechanism to transmit extra data within a stream that is gracefully skipped by decoders that do not support this extra data. This may be used to transmit unwanted data in an otherwise valid stream.
ほとんどのMPEG-4コーデックは、この追加データをサポートしていないデコーダーによって優雅にスキップされるストリーム内で追加のデータを送信する拡張メカニズムを定義していることに注意してください。これは、それ以外の場合は有効なストリームで不要なデータを送信するために使用できます。
The appropriate mechanism to provide security to RTP and payloads following this may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although, if suitable, the usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (e.g., for RTP over TCP), but other alternatives may also exist.
これに続くRTPとペイロードにセキュリティを提供する適切なメカニズムは異なる場合があります。アプリケーション、輸送、および採用されたシグナルプロトコルに依存します。したがって、単一のメカニズムは十分ではありませんが、適切な場合、安全なリアルタイム輸送プロトコル（SRTP）[RFC3711]の使用法が推奨されます。使用できる他のメカニズムは、IPSEC [RFC4301]および輸送層セキュリティ（TLS）[RFC5246]（たとえば、TCPを超えるRTPの場合）ですが、他の選択肢も存在する可能性があります。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. 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.
このRTPペイロード形式とそのメディアデコーダーは、パケット処理のためにレシーバー側の計算の複雑さに有意な不均一性を示さないため、病理学的データの受領によりサービス拒否の脅威をもたらすことはほとんどありません。完全なMPEG-4システムにより、Javaアプレット（MPEG-J）やスクリプトなど、幅広いコンテンツを輸送できます。このペイロード形式はオーディオおよびビデオストリームに制限されているため、このようなアクティブなコンテンツをこの形式で輸送することはできません。
The RTP payload format for MPEG-4 Audio as specified in RFC 3016 is used by the 3GPP PSS service [3GPP]. However, there are some misalignments between RFC 3016 and the 3GPP PSS specification that are addressed by this update:
RFC 3016で指定されているMPEG-4オーディオ用のRTPペイロード形式は、3GPP PSSサービス[3GPP]で使用されています。ただし、RFC 3016とこのアップデートで扱われる3GPP PSS仕様の間には、いくつかの不整合があります。
o The audio payload format (LATM) referenced in this document is the newer format specified in [14496-3], which is binary compatible to the format used in [3GPP]. This newer format is not binary compatible with the LATM referenced in RFC 3016, which is specified in [14496-3:1999/Amd.1:2000].
o このドキュメントで参照されているオーディオペイロード形式（LATM）は、[14496-3]で指定された新しい形式であり、[3GPP]で使用される形式に互換性があります。この新しい形式は、[14496-3：1999/AMD.1：2000]で指定されているRFC 3016で参照されているLATMとバイナリ互換性がありません。
o The audio signaling format (StreamMuxConfig) referenced in this document is binary compatible to the format used in [3GPP]. The StreamMuxConfig element has also been revised by MPEG since RFC 3016.
o このドキュメントで参照されているオーディオシグナリング形式（StreamMuxConfig）は、[3GPP]で使用される形式と互換性があります。StreamMuxConfig要素は、RFC 3016以来MPEGによって改訂されています。
o The use of an audio parameter "SBR-enabled" is now defined in this document, which is used by 3GPP implementations [3GPP]. RFC 3016 does not define this parameter.
o オーディオパラメーター「SBR対応」の使用は、3GPP実装[3GPP]で使用されるこのドキュメントで定義されています。RFC 3016はこのパラメーターを定義しません。
o The "rate" parameter is defined unambiguously in this document for the case of presence of SBR (Spectral Band Replication). In RFC 3016, the definition of the "rate" parameter is ambiguous.
o 「レート」パラメーターは、SBRの存在の場合（スペクトルバンドレプリケーション）について、このドキュメントで明確に定義されています。RFC 3016では、「レート」パラメーターの定義はあいまいです。
o The number of audio channels parameter is defined unambiguously in this document for the case of presence of PS (Parametric Stereo). At the time RFC 3016 was written, PS was not yet defined.
o Audio Channelsパラメーターの数は、PS（パラメトリックステレオ）の存在の場合、このドキュメントで明確に定義されています。RFC 3016が書かれた時点で、PSはまだ定義されていませんでした。
Furthermore, some comments have been addressed and signaling support for MPEG Surround [23003-1] was added.
さらに、いくつかのコメントに対処されており、MPEGサラウンド[23003-1]のシグナリングサポートが追加されました。
Below is a summary of the changes in requirements by this update:
以下は、このアップデートによる要件の変更の概要です。
o In the dynamic assignment of RTP payload types for scalable MPEG-4 Audio streams, the server SHALL assign a different value to each layer.
o スケーラブルなMPEG-4オーディオストリームのRTPペイロードタイプの動的割り当てでは、サーバーは各レイヤーに異なる値を割り当てるものとします。
o The dependency relationships between the enhanced layer and the base layer for scalable MPEG-4 Audio streams MUST be signaled as specified in [RFC5583].
o [RFC5583]で指定されているように、スケーラブルなMPEG-4オーディオストリームの拡張レイヤーとベースレイヤー間の依存関係の関係を信号する必要があります。
o If the size of an audioMuxElement is so large that the size of the RTP packet containing it does exceed the size of the Path MTU, the audioMuxElement SHALL be fragmented and spread across multiple packets.
o AudiOmuxelementのサイズが非常に大きいため、それを含むRTPパケットのサイズがパスMTUのサイズを超える場合、AudiOmuxelementは断片化され、複数のパケットに広がります。
o The receiver MUST ignore any unspecified parameter in order to ensure that additional parameters can be added in any future revision of this specification.
o 受信機は、この仕様の将来の改訂で追加のパラメーターを追加できるようにするために、不特定のパラメーターを無視する必要があります。
[14496-2] MPEG, "ISO/IEC International Standard 14496-2 - Coding of audio-visual objects, Part 2: Visual", 2003.
[14496-2] MPEG、「ISO/IEC International Standard 14496-2-オーディオビジュアルオブジェクトのコーディング、パート2：Visual」、2003。
[14496-3] MPEG, "ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio", 2009.
[14496-3] MPEG、「ISO/IEC International Standard 14496-3-オーディオビジュアルオブジェクトのコーディング、パート3オーディオ」、2009年。
[14496-3/Amd.1] MPEG, "ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3: Audio, Amendment 1: HD-AAC profile and MPEG Surround signaling", 2009.
[14496-3/AMD.1] MPEG、「ISO/IEC International Standard 14496-3-オーディオビジュアルオブジェクトのコーディング、パート3：オーディオ、修正1：HD-AACプロファイルおよびMPEGサラウンドシグナリング」、2009。
[23003-1] MPEG, "ISO/IEC International Standard 23003-1 - MPEG Surround (MPEG D)", 2007.
[23003-1] MPEG、「ISO/IEC International Standard 23003-1-MPEGサラウンド（MPEG D）」、2007年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007.
[RFC4629] Ott、H.、Bormann、C.、Sullivan、G.、Wenger、S。、およびR.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[RFC5583] Schierl、T。およびS. Wenger、「セッション説明プロトコル（SDP）のシグナリングメディアデコード依存関係」、RFC 5583、2009年7月。
[14496-1] MPEG, "ISO/IEC International Standard 14496-1 - Coding of audio-visual objects, Part 1 Systems", 2004.
[14496-1] MPEG、「ISO/IEC International Standard 14496-1-オーディオビジュアルオブジェクトのコーディング、パート1システム」、2004年。
[14496-12] MPEG, "ISO/IEC International Standard 14496-12 - Coding of audio-visual objects, Part 12 ISO base media file format".
[14496-12] MPEG、「ISO/IEC International Standard 14496-12-オーディオビジュアルオブジェクトのコーディング、パート12 ISOベースメディアファイル形式」。
[14496-14] MPEG, "ISO/IEC International Standard 14496-14 - Coding of audio-visual objects, Part 12 MP4 file format".
[14496-14] MPEG、「ISO/IEC International Standard 14496-14-視聴覚オブジェクトのコーディング、パート12 MP4ファイル形式」。
[14496-3:1999/Amd.1:2000] MPEG, "ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio, Amendment 1: Audio extensions", 2000.
[14496-3：1999/AMD.1：2000] MPEG、「ISO/IEC International Standard 14496-3-オーディオビジュアルオブジェクトのコーディング、パート3オーディオ、修正1：オーディオエクステンション」、2000。
[3GPP] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (Release 9)", 3GPP TS 26.234 V9.5.0, December 2010.
[3GPP] 3GPP、「第3世代パートナーシッププロジェクト、技術仕様グループサービスとシステムの側面、透明なエンドツーエンドパケットスイッチストリーミングサービス（PSS）、プロトコルとコーデック（リリース9）」、3GPP TS 26.234 V9.5.0、2010年12月。
[H245] International Telecommunication Union, "Control protocol for multimedia communication", ITU Recommendation H.245, December 2009.
[H245] International Telecommunication Union、「マルチメディアコミュニケーションのための制御プロトコル」、ITU推奨H.245、2009年12月。
[H261] International Telecommunication Union, "Video codec for audiovisual services at p x 64 kbit/s", ITU Recommendation H.261, March 1993.
[H261] International Telecommunication Union、「P x 64 Kbit/sでの視聴覚サービスのビデオコーデック」、ITU推奨H.261、1993年3月。
[H323] International Telecommunication Union, "Packet-based multimedia communications systems", ITU Recommendation H.323, December 2009.
[H323] International Telecommunication Union、「パケットベースのマルチメディア通信システム」、ITU推奨H.323、2009年12月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTPペイロード冗長なオーディオデータの場合」、RFC 2198、1997年9月。
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000.
[RFC3016] Kikuchi、Y.、Nomura、T.、Fukunaga、S.、Matsui、Y.、およびH. kimata、「MPEG-4オーディオ/ビジュアルストリームのRTPペイロード形式」、RFC 3016、2000年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3640] van der Meer、J.、Mackie、D.、Swaminathan、V.、Singer、D。、およびP. Gentric、「MPEG-4小川の輸送用のRTPペイロード形式」、RFC 3640、2003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to Historic Status", RFC 4628, January 2007.
[RFC4628] Even、R。、「H.263のRTPペイロードフォーマットRFC 2190を歴史的ステータスに移動する」、RFC 4628、2007年1月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109] Li、A。、「ジェネリックフォワードエラー補正のRTPペイロード形式」、RFC 5109、2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5691] de Bont, F., Doehla, S., Schmidt, M., and R. Sperschneider, "RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio", RFC 5691, October 2009.
[RFC5691] de Bont、F.、Doehla、S.、Schmidt、M。、およびR. Sperschneider、「MPEGサラウンドマルチチャネルオーディオを備えた基本ストリームのRTPペイロード形式」、RFC 5691、2009年10月。
Authors' Addresses
著者のアドレス
Malte Schmidt Dolby Laboratories Deutschherrnstr. 15-19 90537 Nuernberg DE
Malte Schmidt Dolby Laboratories Deutschherrnstr。15-19 90537 Nuernberg de
Phone: +49 911 928 91 42
EMail: malte.schmidt@dolby.com
Frans de Bont Philips Electronics High Tech Campus 36 5656 AE Eindhoven NL
Frans de Bont Philips Electronicsハイテクキャンパス36 5656 AE Eindhoven NL
Phone: +31 40 2740234
EMail: frans.de.bont@philips.com
Stefan Doehla Fraunhofer IIS Am Wolfmantel 33 91058 Erlangen DE
Stefan Doehla Fraunhofer IIS Am Wolfmantel 33 91058 Erlangen de
Phone: +49 9131 776 6042
EMail: stefan.doehla@iis.fraunhofer.de
Jaehwan Kim LG Electronics Inc. VCS/HE, 16Fl. LG Twin Towers Yoido-Dong, YoungDungPo-Gu, Seoul 150-721 Korea
Jaehwan Kim LG Electronics Inc. VCS/HE、16FL。LGツインタワーズYoido-Dong、Youngdungpo-gu、ソウル150-721韓国
Phone: +82 10 6225 0619
EMail: kjh1905m@naver.com