RFC3016 日本語訳
3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi,T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: TXT=47070 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループY.菊池の要求をネットワークでつないでください: 3016年の東芝カテゴリ: 標準化過程T.野村日本電気S.Fukunaga Oki Y.松井Matsushita H.Kimata NTT2000年11月
RTP Payload Format for MPEG-4 Audio/Visual Streams
MPEG-4つのオーディオの、または、視覚のストリームのためのRTP有効搭載量形式
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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-4Systemsを使用しないでそれぞれのMPEG-4AudioとMPEG-4Visual bitstreamsを運ぶためにレアル-時間Transportプロトコル(RTP)ペイロード形式について説明します。直接MPEG-4Audio/視覚のbitstreamsをRTPパケットに写像する目的として、それは、RTPヘッダーフィールドの使用のための仕様を提供して、また、断片化規則を指定します。 また、それはSession記述プロトコル(SDP)のタイプ登録証明書と使用をマルチパーパスインターネットメールエクステンション(MIME)のための仕様に提供します。
1. Introduction
1. 序論
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-4Audio[3][5]とMPEG-4Visualストリーム[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
これらのRTPペイロード形式は同期を使用することのないMPEG-4Audio/視覚のストリームの輸送とMPEG-4Systems[6]のストリーム管理の機能性を可能にします。 そのようなRTPペイロード形式は本質的なストリーム管理を持っているシステムで使用されるでしょう。
Kikuchi, et al. Standards Track [Page 1] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[1ページ]RFC3016RTP有効搭載量形式
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.
(そこでは、MPEG-4Systems Object Descriptorsによって管理されるのではなく、MPEG-4Audio/視覚のストリームはH.245によって管理されます)。したがって、MPEG-4Systemsからのどんなそのような機能性も必要としないでください。そして、機能性、H.323端末はそのようなシステムに関する例です。 MPEG-4Systems Sync Layerを使用しないで、ストリームは直接RTPパケットに写像されます。 他の例は、MIMEとSDPが使用されているSIPとRTSPです。 本書では説明されたRTPペイロード形式のMIMEの種類とSDP用法は、直接MPEG-4Systemsを使用しないでAudio/視覚のストリーム(例えば、メディアタイプ、packetization形式、およびコーデック構成)の属性を指定するために定義されます。明白な利益は非MPEGの4コーデックのために定義されたそれらの書式と共にこれらのMPEG-4Audio/視覚のRTPペイロード形式を統一された方法で扱うことができるということです。 不都合が環境がMPEG-4Systemsを使用している相互運用性が難しいかもしれないということである、他のペイロード形式はそれらのアプリケーションに合うほうがよいです。
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.
MPEG-4つのAudio/画像データ要素との協会を含むケースが明確に定義されるために必要とするそのようなもののRTPヘッダーの意味論。 さらに、MPEG-4つのVideoストリームのためにRTPパケットの断片化規則を定義するのは、MPEG-4Videoストリームで提供された誤り弾力ツールを利用することによって誤りの弾性を高めるのに有益です。
1.1 MPEG-4 Visual RTP payload format
1.1 MPEG-4Visual 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-4Visualは多くの新機能がある視覚コーディング標準です: 高いコード化効率。 高い誤りの弾性。 倍数、任意形状のオブジェクトベースのコード化。 など [2]. それは何十Kbpsから数個のMbpsまでさまざまなbitratesをカバーしています。 また、それはさまざまなネットワークをカバーしています、高い誤り率のためにモバイルネットワークにほとんどエラーのなくなるように保証されて、それらから変化して。
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-4Visualがさまざまなネットワークに使用されるので本書では定義されたMPEG-4Visual bitstreamのための断片化規則に関して、断片化のあまりに多くの制限を適用しないのが望ましく、「単一のビデオパケットは単一のRTPパケットの上でいつも写像などにされるものとすることなど」の断片化規則が不適当であるかもしれません。 他方では、不注意であることで、断片化がそうするかもしれないのを気づかないメディアは退行の間違った弾性と帯域幅効率を引き起こします。 本書では説明された断片化規則は、フレキシブルですが、何とかMPEG-4Visualの誤り弾力の機能性を利用している間、無意味な断片化を防ぐための最小の規則を定義します。
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が、RTPパケットで1つ以上を写像しないことを勧めると裁決するので、RTPタイムスタンプは唯一VOP時間縁どりを示します。 他方では、MPEG-4ビデオは非常に小さいサイズのVOPsを生成するかもしれません、空のVOP(_がコード化したvop=0)が含んでいる場合だけで
Kikuchi, et al. Standards Track [Page 2] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[2ページ]RFC3016RTP有効搭載量形式
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.)
VOPヘッダーか少ない数のコード化ブロックがある任意の形成VOP。 そのような場合のためにオーバーヘッドを下げるために、断片化規則は、RTPパケットの複数のVOPsを連結することを許可します。 (セクション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.
特定のRTPヘッダーが画像ヘッダーを回収するのを助けるようなH.261かMPEG-1/2が有効であるビデオコーディング・ツールのために定義した追加メディアはパケット損失で買収されましたが、MPEG-4Visualには、不正なヘッダーを回収するための誤り弾力の機能性が既にあります、そして、RTP/IPネットワークの上と、そして、他のネットワーク(H.223/モバイル、MPEG-2/TSなど)の上でこれらは使用できます。 したがって、どんな付加的なRTPヘッダーフィールドもこのMPEG-4Visual RTPペイロード形式で定義されません。
1.2 MPEG-4 Audio RTP payload format
1.2 MPEG-4Audio 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-4Audioは多くの異なったタイプのオーディオコーディング・ツールを統合する新しい種類のオーディオ規格です。 低いオーバーヘッドMPEG-4Audio Transport Multiplex(LATM)は比較的わずかなオーバーヘッドでオーディオデータの系列を管理します。 オーディオだけアプリケーションでは、その時、LATMベースのMPEG-4Audio bitstreamsが直接MPEG-4Systemsを使用しないで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つの特徴の必要は全くありません。 したがって、このドキュメントによって指定されたRTP packetizationに基づくアプリケーションでこれらの2つの特徴を使用してはいけません。 LATMがすなわち、統合ツールでないためにツールをコード化する自然なオーディオだけのために開発されたので、LATMでStructured Audio(SA)データとTextをSpeech Interface(TTSI)データに送るのは難しく思えます。 したがって、SAデータとTTSIデータはRTP packetizationによって本書では輸送されてはいけません。
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
スケーラブルなストリームの送信のために、それぞれに関するオーディオデータはSHOULDを層にします。異なった層がIPレベルで異なって扱われるのを例えば、差別化されたサービスのいくつかの手段で許容しながら、異なったRTPパケットにpacketizedされます。 他方では、スケーラブルなストリームに関するすべてのコンフィギュレーション・データが"StreamMuxConfig"という1つのLATMコンフィギュレーション・データに含まれています、そして、あらゆる登れる層がStreamMuxConfigを共有します。各層とそのコンフィギュレーション・データの間のマッピングは情報が付いたLATMヘッダーによって達成されます。
Kikuchi, et al. Standards Track [Page 3] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[3ページ]RFC3016RTP有効搭載量形式
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).
オーディオデータ。 スケーラブルなストリームの依存情報を示すために、制限はペイロードタイプのダイナミックな課題規則に適用された(太平洋標準時の)値(セクション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-4Audioに関しては、パケット損失は隣接しているパケットのdecodabilityを損なわないでしょう。 したがって、誤りを回復するための追加メディア詳細ヘッダーはMPEG-4Audioに必要でないでしょう。 Generic Forward Error Correction(RFC2733)やRedundant Audio Dataなどの既存のRTP保護メカニズム(RFC2198)は、誤りの弾性を改良するために適用されるかもしれません。
2. Conventions used in this document
2. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[7]で説明されるように本書では解釈されることであるべきですか?
3. RTP Packetization of MPEG-4 Visual bitstream
3. MPEG-4Visual bitstreamのRTP Packetization
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-4Visual内容にRTP packetization規則を指定します。 MPEG-4Visual bitstreamは付加的なヘッダーフィールドの追加かVisual構文要素の少しも取り外しなしで直接RTPパケットに写像されます。 設定情報が基本のストリームと同じRTPポートまで運ばれるように、Combined Configuration/基本のストリームモードを使用しなければなりません。 (ISO/IEC14496-2[2][9][4])の6.2.1「スタートコード」を見てください。 設定情報はいくつかのバンドで出ている手段でさらに、指定されるかもしれません。 H.323端末に必要であるなら、このためにH.245 codepoint"decoderConfigurationInformation"を使用しなければなりません。 システムがMIME content typeと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).
短いビデオヘッダーモードは使用されています、RTPペイロード形式。いつ、H.263 SHOULDには、使用されてくださいか(RFC2429で定義された書式はRECOMMENDEDですが、RFC2190形式は、より古い実装との互換性に使用されるかもしれません)。
Kikuchi, et al. Standards Track [Page 4] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[4ページ]RFC3016RTP有効搭載量形式
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| RTP+++++++++++++++++++++++++++++++++| タイムスタンプ| ヘッダー+++++++++++++++++++++++++++++++++| 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | RTP| MPEG-4Visualストリーム(バイトは並びました)| 支払ってください。| | 負荷| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - An RTP packet for MPEG-4 Visual stream
図1--MPEG-4VisualストリームのためのRTPパケット
3.1 Use of RTP header fields for MPEG-4 Visual
3.1 RTPヘッダーフィールドのMPEG-4Visualの使用
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).
有効搭載量タイプ(太平洋標準時の): この新しいパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 による、特定のクラスのアプリケーションのためのRTPプロフィールがこのコード化のためのペイロードタイプを選任すると予想するか、またはダイナミックレンジSHALLの当時のaペイロードタイプにそれをしないなら選んでください、バンドシグナリングから、(例えば、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)は噛み付きました: 1つにマーカービットがVOPの最後のRTPパケット(または、RTPパケットだけ)を示すように設定されます。 複数のVOPsが同じ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
- 複数のVOPsが同じRTPパケットで運ばれるとき、タイムスタンプはRTPパケットで運ばれたVOPsの中に最も早いVOP時間を示します。 残りのタイムスタンプ情報
Kikuchi, et al. Standards Track [Page 5] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[5ページ]RFC3016RTP有効搭載量形式
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ヘッダー(_時間_ベースとvop_時間_が増加する法)のタイムスタンプ分野からVOPsを得ます。 - RTPパケットが_VideoObjectPlane()分野の設定情報、そして/または、Group_だけを含んでいるなら、コード化オーダーにおける次のVOPのタイムスタンプは使用されています。 - RTPパケットが視覚_オブジェクト_系列_終わり_コード情報だけを含んでいるなら、コード化オーダーにおけるすぐに前の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).
タイムスタンプの解決は90kHzのデフォルト値に設定されます、バンドで出ている手段(セクション5で定義される例えば、SDPパラメタかMIMEパラメタ)で指定されない場合。
Other header fields are used as described in RFC 1889 [8].
他のヘッダーフィールドはRFC1889[8]で説明されるように使用されています。
3.2 Fragmentation of MPEG-4 Visual bitstream
3.2 MPEG-4Visual bitstreamの断片化
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-4Visual bitstreamは付加的なヘッダーフィールドのどんな追加かVisual構文要素の少しも取り外しなしでも直接RTPペイロードに写像されます。 Combined Configuration/基本のストリームモードは使用されています。 以下の規則は断片化に申し込みます。
In the following, header means one of the following:
以下では、ヘッダーは以下の1つを言っています:
- 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.
- 設定情報(視覚Object Sequence Header、Visual Object Header、およびVideo Object Layer Header)--視覚_オブジェクト_系列_終わり_コード--エントリー・ポイントのヘッダーは基本のストリームのために機能します。(_VideoObjectPlane()の_かVideoObjectPlane()のヘッダーを分類してください、_脆い_ヘッダー()、MeshObject()またはFaceObject())とビデオ_飛行機_--、ビデオパケットのヘッダー、(次の_のresync_マーカー())を除いたビデオ_パケット_ヘッダー()--かたまり_層()のヘッダーは6を見ます; 2.1 設定情報とエントリーの定義のためのISO/IEC14496-2 294の「スタートコード」は機能を指します。
(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) _VideoObjectPlane()の設定情報とGroup_はSHALLをさばきます。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) 1個以上のヘッダーがRTPペイロードに存在しているなら、RTPペイロードSHALLはシンタクス上最も高い機能のヘッダーと共に始まります。 以下に注意してください。 視覚_オブジェクト_系列_終わり_コードは最も低い機能と見なされます。
Kikuchi, et al. Standards Track [Page 6] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[6ページ]RFC3016RTP有効搭載量形式
(3) A header SHALL NOT be split into a plurality of RTP packets.
(3) ヘッダーSHALL NOT、多くの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) 異なったVOPs SHOULDが1つのRTPパケットがユニークなVOP時間インスタンス(すなわち、RTPパケットのヘッダーのタイムスタンプ分野で、示される)に関連しているデータ・バイトから成るように異なったRTPパケットに断片化されて、VOPsのサイズが小さいなら、例外で、そんなに複数の連続した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.)
以下に注意してください。 複数のVOPsが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パケットとして単一のビデオパケットを送るのは、RECOMMENDEDです。 サイズ、aビデオパケットSHOULDでは、結果として起こるRTPパケットが経路-MTUほど大きくないような方法で調整されてください。 以下に注意してください。 ビデオパケットが符号化器構成(_マーカー_が無効にする「再-同時性」を1へのVOLヘッダーにはめ込むのによる)の近く、または、ビデオパケットがサポートされないコーディング・ツールで無効にされるとき、規則(5)は適用されません。 この場合VOP MAY、任意のバイト位置で分けられてください。
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ヘッダーかビデオパケットのヘッダーから始めて、動き_形の_織地()に従って続いて、次の_「再-同時性」_マーカー()か次の_スタート_コード()で終わります。
3.3 Examples of packetized MPEG-4 Visual bitstream
3.3 packetized MPEG-4Visual bitstreamに関する例
Figure 2 shows examples of RTP packets generated based on the criteria described in 3.2
RTPパケットに関する例が生成した3.2で説明された評価基準に基づく図2ショー
(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-4Visual bitstreamのランダムアクセス先が設定情報を含んでいますか? 評価基準(1)によると、Visual Object Sequence Header(VSヘッダー)はRTPペイロードの始めに置かれます、Visual Object HeaderとVideo Object Layer Header(VOヘッダー、VOLヘッダー)に先行して。 3.2で定義された断片化規則が、視覚_オブジェクト_系列_始め_コードから始まって、設定情報がいつもRTPペイロードの始めに置かれるのを保証するので、RTPペイロードの最初の32ビットの分野が視覚_オブジェクト_系列_始め_コードであるかどうかチェックすることによって、RTP受信機はランダムアクセスポイントを検出できます。
Kikuchi, et al. Standards Track [Page 7] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[7ページ]RFC3016RTP有効搭載量形式
(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パケットがオーバーヘッド、設定情報、およびすぐに次のGOVを増強するかもしれない、(aが離れている、)、この例のように単一のRTPパケットにVOPをpacketizedされることができます。
(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) _VideoObjectPlane(GOV)のGroup_を含むRTPパケットが例がありますか? 評価基準(1)に続いて、GOVはRTPペイロードの始めに置かれます。 それは、長さが7バイトであるGOVだけを含むRTPパケットを生成するためにはRTP/IPヘッダーオーバーヘッドの浪費でしょう。 したがって、(aが離れている、)、(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パケットにpacketizedされるところに例がありますか? 基本的なネットワークのパケット損失率が高いときに、packetizationのこの種類はお勧めです。 VOPヘッダーを含むRTPパケットがパケット損失で捨てられるときさえ、ビデオパケットのヘッダーでHEC(ヘッダーExtension Code)情報を使用することによって、他の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つ以上のビデオパケットが1つのRTPパケットにpacketizedされるところに例がありますか? packetizationのこの種類は、基本的なネットワークのビット伝送速度が低いときに、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.
ビデオパケットが_マーカー_が無効にする「再-同時性」をVOLヘッダーにはめ込むことによって1に無効にされるとき、(f)はケースに関する例です。 この場合、VOPは任意のバイト位置の多くのRTPパケットに分割されるかもしれません。 例えば、VOPを固定長パケットに分割するのは可能です。 基本的なネットワークがエラーのなくなるように保証されるとき、この種類の符号化器構成とRTPパケット断片化は使用されるかもしれません。 他方では、貧しいパケット損失の弾性だけを提供するので、誤り傾向がある環境でそれを使用することは勧められません。
Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.
図3は3.2の評価基準によって禁止されたRTPパケットに関する例を示しています。
Kikuchi, et al. Standards Track [Page 8] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[8ページ]RFC3016RTP有効搭載量形式
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).
複数のRTPパケットへのヘッダーの断片化はRTP/IPヘッダーのオーバーヘッドを増強するだけではなく、(a)のように誤りの弾性を減少もさせるでしょう。 したがって、それは評価基準(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).
1つ以上のビデオパケットをRTPパケットに連結するとき、VOPヘッダーかビデオ_パケット_ヘッダー()をRTPペイロードの中央に置かないものとします。 誤りの弾性の局面のため(b)に評価基準(2)によって許容されていないpacketization。 2つのビデオパケットがどちらの場合も、2つのRTPパケットに写像されますが、図2(d)とこの例を比べて、パケット損失の弾性は同じではありません。 すなわち、2番目のRTPパケットが無くなるなら、両方のビデオパケット1と2は図3(b)の場合で失われていますが、ビデオパケット2だけが図2(d)の場合で失われています。
+------+------+------+------+
(a) | RTP | VS | VO | VOL |
|header|header|header|header|
+------+------+------+------+
+------+------+------+------+ (a)| RTP| V| VO| VOL| |ヘッダー|ヘッダー|ヘッダー|ヘッダー| +------+------+------+------+
+------+------+------+------+------------+
(b) | RTP | VS | VO | VOL |Video Packet|
|header|header|header|header| |
+------+------+------+------+------------+
+------+------+------+------+------------+ (b)| RTP| V| VO| VOL|ビデオパケット| |ヘッダー|ヘッダー|ヘッダー|ヘッダー| | +------+------+------+------+------------+
+------+-----+------------------+
(c) | RTP | GOV |Video Object Plane|
|header| | |
+------+-----+------------------+
+------+-----+------------------+ (c)| RTP| GOV|ビデオ対物面| |ヘッダー| | | +------+-----+------------------+
+------+------+------------+ +------+------+------------+
(d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet|
|header|header| (1) | |header|header| (2) |
+------+------+------------+ +------+------+------------+
+------+------+------------+ +------+------+------------+ (d)| RTP| VOP|ビデオパケット| | RTP| VP|ビデオパケット| |ヘッダー|ヘッダー| (1) | |ヘッダー|ヘッダー| (2) | +------+------+------------+ +------+------+------------+
+------+------+------------+------+------------+------+------------+
(e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet|
|header|header| (1) |header| (2) |header| (3) |
+------+------+------------+------+------------+------+------------+
+------+------+------------+------+------------+------+------------+ (e)| RTP| VP|ビデオパケット| VP|ビデオパケット| VP|ビデオパケット| |ヘッダー|ヘッダー| (1) |ヘッダー| (2) |ヘッダー| (3) | +------+------+------------+------+------------+------+------------+
+------+------+------------+ +------+------------+
(f) | RTP | VOP |VOP fragment| | RTP |VOP fragment|
|header|header| (1) | |header| (2) | ___
+------+------+------------+ +------+------------+
+------+------+------------+ +------+------------+ (f)| RTP| VOP|VOP断片| | RTP|VOP断片| |ヘッダー|ヘッダー| (1) | |ヘッダー| (2) | ___ +------+------+------------+ +------+------------+
Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream
図2--RTP packetized MPEG-4Visual bitstreamに関する例
Kikuchi, et al. Standards Track [Page 9] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[9ページ]RFC3016RTP有効搭載量形式
+------+-------------+ +------+------------+------------+
(a) | RTP |First half of| | RTP |Last half of|Video Packet|
|header| VP header | |header| VP header | |
+------+-------------+ +------+------------+------------+
+------+-------------+ +------+------------+------------+ (a)| RTP|前半| | RTP|半分を持続します。|ビデオパケット| |ヘッダー| VPヘッダー| |ヘッダー| VPヘッダー| | +------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+
(b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet|
|header|header| of VP(1) | |header| of VP(1)|header| (2) |
+------+------+----------+ +------+---------+------+------------+
+------+------+----------+ +------+---------+------+------------+ (b)| RTP| VOP|前半| | RTP|最後の半分| VP|ビデオパケット| |ヘッダー|ヘッダー| VP(1)について| |ヘッダー| VP(1)について|ヘッダー| (2) | +------+------+----------+ +------+---------+------+------------+
Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream
図3--MPEG-4Visual bitstreamのための禁止されたRTP packetizationに関する例
4. RTP Packetization of MPEG-4 Audio bitstream
4. MPEG-4Audio bitstreamのRTP Packetization
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-4Audio bitstreamsにRTP packetization規則を指定します。LATM(頭上で低いMPEG-4Audio Transport Multiplex)ツール[5]でMPEG-4つのAudioストリームをフォーマットしなければなりません、そして、下の3つのセクションについて説明するとき、次に、LATMのベースのストリームはRTPパケットに写像されます。
4.1 RTP Packet Format
4.1 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の系列から成ります。 AはaudioMuxElementか部分を完成します。1SHALLでは、audioMuxElement構文要素の取り外しなしでどんな直接RTPペイロードに写像されてください(図4を見てください)。 最初のバイト、各audioMuxElement SHALLでは、RTPパケットにおける最初のペイロード位置に位置してください。
Kikuchi, et al. Standards Track [Page 10] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[10ページ]RFC3016RTP有効搭載量形式
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号|RTP+++++++++++++++++++++++++++++++++| タイムスタンプ|ヘッダー+++++++++++++++++++++++++++++++++| 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |RTP: audioMuxElement(バイトは並んだ):Payload| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - An RTP packet for MPEG-4 Audio
図4--MPEG-4Audioのための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 SHALLは指示ビット"useSameStreamMux"を含んでいます、そして、音声圧縮のための"StreamMuxConfig"という設定情報を含むかもしれません。 useSameStreamMuxビットは、前のフレームのStreamMuxConfig要素が現在のフレームで適用されるかどうかを示します。 useSameStreamMuxビットがStreamMuxConfigを前のフレームから使用に示しますが、前のフレームがなくされたなら、現在のフレームは解読可能でないかもしれません。 したがって、バンドにおけるモードの場合のStreamMuxConfig要素SHOULD、繰り返してネットワーク条件によって、伝えられてください。 他方では、muxConfigPresentが0(出ているバンドモード)に用意ができているなら、アウトによってStreamMuxConfig要素が伝えられなければならない、-、バンド手段について。 SDPの場合には、「コンフィグ」というMIMEパラメタは利用されています(セクション5.3を見てください)。
4.2 Use of RTP Header Fields for MPEG-4 Audio
4.2 RTPヘッダーフィールドのMPEG-4オーディオの使用
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,
有効搭載量タイプ(太平洋標準時の): この新しいパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 特定のクラスのアプリケーションのためのRTPプロフィールがこのコード化のためのペイロードタイプを選任すると予想されます。
Kikuchi, et al. Standards Track [Page 11] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[11ページ]RFC3016RTP有効搭載量形式
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.
による、または、それが完了していないならダイナミックレンジにおけるペイロードタイプが選ばれるものとする、バンドシグナリングから、(例えば、H.245、SIPなど)について議定書の中で述べてください。 RTPペイロードのダイナミックな課題で、SHOULDはスケーラブルなストリーム、異価のためにタイプしています。各層に割り当てられます。 SHOULDの順にある割り当てられた値は層の依存を高めます。そこでは、基層が持っています中で値最も小さい。
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)は噛み付きました: マーカービットはaudioMuxElement境界を示します。 1つにそれが、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.
バンドで出ている手段で指定されない場合、タイムスタンプの解決は90kHzのデフォルト値に設定されます。
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].
他のヘッダーフィールドはRFC1889[8]で説明されるように使用されています。
4.3 Fragmentation of MPEG-4 Audio bitstream
4.3 MPEG-4Audio bitstreamの断片化
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パケットに1audioMuxElementを入れるRECOMMENDEDです。 それを含むRTPパケットのサイズが経路-MTUのサイズを超えていないほど小さくaudioMuxElementのサイズを保つことができると、これはどんな問題にもならないでしょう。 そうすることができないなら、audioMuxElementは複数のパケットの向こう側に断片化されて、広げられるかもしれません。
5. MIME type registration for MPEG-4 Audio/Visual streams
5. MPEG-4Audio/視覚のストリームのためのMIMEの種類登録
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-4Audio/視覚のストリームのためのMIMEの種類登録証明書について説明します。MPEG-4AudioストリームのためのMIMEの種類登録とSDP用法はセクション5.3と5.4でそれぞれ説明されますが、MPEG-4VisualストリームのためのMIMEの種類登録とSDP用法はセクション5.1と5.2でそれぞれ説明されます。
5.1 MIME type registration for MPEG-4 Visual
5.1 MPEG-4VisualのためのMIMEの種類登録
MIME media type name: video
MIMEメディア型名: ビデオ
MIME subtype name: MP4V-ES
MIME「副-タイプ」は以下を命名します。 MP4V-ES
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
Kikuchi, et al. Standards Track [Page 12] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[12ページ]RFC3016RTP有効搭載量形式
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.
平らなイドの輪郭を描いてください: MPEG-4Visual ProfileとLevel指示価値(プロフィール_と_レベル_指示)の10進表現はTableでISO/IEC第一部14496-2[2][4]を定義しました。 このパラメタは、MPEG-4VisualコーデックができるMPEG-4Visual ProfileとLevel組み合わせを示すのに能力交換かセッションセットアップ手順で使用されるかもしれません。 このパラメタが手順で指定されないなら、1(簡単なProfile/レベル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).
コンフィグ: このパラメタSHALL、使用されて、対応するMPEG-4Visual bitstreamの構成を示してください。 それ、SHALL NOT、使用されて、能力交換手順によるコーデック能力を示してください。 それはMPEG-4Visual設定情報を言い表す八重奏ストリングの16進表現です、ISO/IEC14496-2[2][4][9]の「副-節」6.2.1のStartコードで定義されるように。 設定情報は最初にMSB基礎で八重奏ストリングに写像されます。 1番目は設定情報SHALLに噛み付きました。最初の八重奏のMSBでは、位置しています。 設定情報は、このパラメタSHALLで対応するMPEG-4Visualストリームにおける設定情報と同じであるように示しました、最初の_半分_vbv_占有と後者_半分_vbv_占有を除いて存在してください、たびたびの設定情報でMPEG-4Visualストリームにおいて異なるかもしれないどれ(ISO/IEC14496-2の6.2の.1Startコードを見てください)。
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。 プロフィール平らなイドの=1
- MPEG-4 Visual Core Profile/Level 2:
Content-type: video/mp4v-es; profile-level-id=34
- MPEG-4の視覚コアプロフィール/レベル2: 文書内容: ビデオ/mp4v-es。 プロフィール平らなイドの=34
- MPEG-4 Visual Advanced Real Time Simple Profile/Level 1:
Content-type: video/mp4v-es; profile-level-id=145
- MPEG-4の視覚高度なリアルタイムの簡単なプロフィール/レベル1: 文書内容: ビデオ/mp4v-es。 プロフィール平らなイドの=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つのVisualストリームのための仕様はISO/IEC14469-2[2][4][9]に提示されます。 RTPペイロード形式はRFC3016で説明されます。
Kikuchi, et al. Standards Track [Page 13] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[13ページ]RFC3016RTP有効搭載量形式
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つのVisual仕様(ISO/IEC14496-2)通りにビデオbitstreamsを生成しなければなりません。 ビデオbitstreamをバイナリ・データであり、非バイナリー輸送のためにコード化しなければなりません(メールでは、Base64コード化は十分です)。 また、このタイプは転送のためにRTPを通して定義されます。 RFC3016で定義されたMPEG-4Visual RTPペイロード書式によると、RTPパケットをpacketizedしなければなりません。
Security considerations:
See section 6 of RFC 3016.
セキュリティ問題: RFC3016のセクション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-4Visualは大きくて豊かなセットのツールを視覚オブジェクトのコード化に提供します。 規格の有効な実装において、MPEG-4つのVisualツール・セットの部分集合を特定のアプリケーションにおける使用に提供しました。 これらの部分集合、呼ばれた'プロフィール'は実装するデコーダが必要であるツール・セットのサイズを制限します。 計算量を制限するために、1Levelsが各Profileに用意ができています。 Profile@Level 組み合わせは以下を許容します。
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.
視覚はSHALLを流します。MPEG-4Visual Profile@Level が「プロフィールレベルイド」というパラメタによって指定されている状態で、言いなりになってください。 送付者と受信機の間の相互運用性は、互いに同じ値にこのパラメタを設定するためにパラメタMIME内容、または能力で手配するのによる「平らなイドの輪郭を描いてください」という交換/発表手順を指定することによって、達成されるかもしれません。
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.)
詳細のために連絡する人とEメールアドレス: RFC3016の作者。 (セクション8を見てください。)
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
The authors of RFC 3016. (See section 8.)
コントローラを書くか、または変えてください: RFC3016の作者。 (セクション8を見てください。)
Kikuchi, et al. Standards Track [Page 14] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[14ページ]RFC3016RTP有効搭載量形式
5.2 SDP usage of MPEG-4 Visual
5.2 MPEG-4VisualのSDP使用法
The MIME media type video/MP4V-ES string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
メディアタイプビデオ/MP4V-ESが結ぶMIMEは以下の通りSession記述プロトコル(SDP)、RFC2327の分野に写像されます:
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 それぞれ「プロフィールレベルイド」と「コンフィグ」が符号化器能力と構成を示しに"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
簡単なProfile/レベル1、レート=90000(90kHz)、「プロフィールレベルイド」、および「コンフィグ」は"a=fmtp"系列で存在しています: mはビデオ49170/2RTP/AVP98a=rtpmapと等しいです: 98MP4V-ES/90000a=fmtp: 98のプロフィール平らなイド=1、コンフィグは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
コアProfile/レベル2、レート=90000(90kHz)、「プロフィールレベルイド」は"a=fmtp"系列で存在しています: ビデオ49170/2RTP/AVP98m=a=rtpmap: 98MP4V-ES/90000a=fmtp: 98のプロフィール平らなイド=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
レアルTime Simple Profile/レベル1、レート=90000(90kHz)を進めてください、そして、「プロフィールレベルイド」は"a=fmtp"系列で存在しています: ビデオ49170/2RTP/AVP98m=a=rtpmap: 98MP4V-ES/90000a=fmtp: 98のプロフィール平らなイド=145
5.3 MIME type registration of MPEG-4 Audio
5.3 MPEG-4AudioのMIMEの種類登録
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME subtype name: MP4A-LATM
MIME「副-タイプ」は以下を命名します。 MP4A-LATM
Kikuchi, et al. Standards Track [Page 15] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[15ページ]RFC3016RTP有効搭載量形式
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).
必要なパラメタ: 以下を評価してください。 レートパラメタはRTPタイムスタンプクロックレートを示します。 デフォルト値は90000です。 それらがオーディオ標本抽出率(1秒あたりのサンプルの数)と同じ値に設定される場合にだけ、他のレートは指定されるかもしれません。
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.
任意のパラメタ: 平らなイドの輪郭を描いてください: ISO/IEC14496-1([6]で定義されたMPEG-4Audio Profile Level指示価値の10進表現とその修正) このパラメタは、デコーダがどのMPEG-4つのAudioツール部分集合を使用できるかを示します。 このパラメタが能力交換かセッションセットアップ手順で指定されないなら、30(自然なAudio Profile/レベル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/IEC14496-3[5]で定義されたMPEG-4Audio Object Type価値の10進表現。 このパラメタは、符号化器によって使用されるためにツールを指定します。 「平らなイドの輪郭を描いてください」という指定の中で能力を制限するのに使用されて、ことであるかもしれません。
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/IEC14496-3[5](セクション4.1を見る)で定義されるように"StreamMuxConfig"というオーディオペイロードコンフィギュレーション・データを言い表す八重奏ストリングの16進表現。 コンフィギュレーション・データは最初にMSB基礎で八重奏ストリングに写像されます。 1番目はコンフィギュレーション・データSHALLに噛み付きました。最初の八重奏のMSBでは、位置しています。 必要なら、最後の八重奏、無詰め物ビットでは、SHALLはコンフィギュレーション・データに従います。
ptime: RECOMMENDED duration of each packet in milliseconds.
ptime: ミリセカンドで表現されるそれぞれのパケットのRECOMMENDED持続時間。
Published specification:
Payload format specifications are described in this document.
Encoding specifications are provided in ISO/IEC 14496-3 [3][5].
広められた仕様: 有効搭載量書式仕様は本書では説明されます。 ISO/IEC14496-3[3][5]にコード化仕様を提供します。
Encoding considerations:
This type is only defined for transfer via RTP.
問題をコード化します: このタイプは転送のためにRTPを通して定義されるだけです。
Security considerations:
See Section 6 of RFC 3016.
セキュリティ問題: RFC3016のセクション6を見てください。
Kikuchi, et al. Standards Track [Page 16] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[16ページ]RFC3016RTP有効搭載量形式
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-4Audioは大きくて豊かなセットのツールをオーディオオブジェクトのコード化に提供します。 規格の有効な実装において、それらと同様のツール・セットがMPEG-4Visualで使用するMPEG-4Audioの部分集合を提供しました(セクション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.
オーディオはSHALLを流します。MPEG-4Audio Profile@Level が「プロフィールレベルイド」というパラメタによって指定されている状態で、言いなりになってください。 MIMEにおける「平らなイドの輪郭を描いてください」というパラメタを指定して、内容、または互いに同じ値にこのパラメタを設定するように能力交換手順で手配することによって、送付者と受信機の間の相互運用性は達成されるかもしれません。 その上、指定された Profile@Level の中で能力交換が能力を制限するのに「オブジェクト」パラメタを使用できます。
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.
詳細のために連絡するパーソナルとEメールアドレス: RFC3016のセクション8を見てください。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
See Section 8 of RFC 3016.
コントローラを書くか、または変えてください: RFC3016のセクション8を見てください。
5.4 SDP usage of MPEG-4 Audio
5.4 MPEG-4AudioのSDP使用法
The MIME media type audio/MP4A-LATM string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
オーディオ/MP4A-LATMが結ぶMIMEメディアタイプは以下の通りSession記述プロトコル(SDP)、RFC2327の分野に写像されます:
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 「プロフィールレベルイド」という任意のパラメタは、符号化器能力を示すために"a=fmtp"系列に入ります。 「オブジェクト」パラメタは"a=fmtp"属性に入ります。 ペイロード形式詳細パラメタ
Kikuchi, et al. Standards Track [Page 17] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[17ページ]RFC3016RTP有効搭載量形式
"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"、および「コンフィグ」は"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
9128B1071070 a=ptime: 6kb/s CELP bitstreams(8kHzのオーディオ標本抽出率がある)、9;オブジェクト=8; cpresent=0; m=オーディオの49230RTP/AVP96a=rtpmap: 96MP4A-LATM/8000a=fmtp: 96のプロフィール平らなイド=コンフィグ=20のために
For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of 24 kHz),
64kb/s AAC LCステレオbitstreams(24kHzのオーディオ標本抽出率がある)のために
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
m=オーディオの49230RTP/AVP96a=rtpmap: 96 MP4A-LATM/24000a=fmtp: 96 プロフィール平らなイドの=1。 bitrate=64000。 cpresent=0。 コンフィグ=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
オーディオの49230RTP/AVP96m=a=rtpmap: 96 MP4A-LATM/90000a=fmtp: 96 オブジェクト=8。 cpresent=0。 コンフィグは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
オーディオの49230RTP/AVP96m=a=rtpmap: 96 MP4A-LATM/90000a=fmtp: 96 オブジェクト=2。 cpresent=1
6. Security Considerations
6. セキュリティ問題
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つの操作の間には、闘争が全くありません。
Kikuchi, et al. Standards Track [Page 18] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[18ページ]RFC3016RTP有効搭載量形式
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.
Javaアプレット(MPEG-J)とスクリプトを含んでいて、完全なMPEG-4システムはさまざまな内容の輸送を考慮します。 このペイロード形式がオーディオとビデオストリームに制限されるので、この形式でそのようなアクティブな内容を輸送するのは可能ではありません。
7. References
7. 参照
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
1 ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-
visual objects - Part2: Visual".
2 ISO/IEC14496-2:1999、「情報技術--オーディオの視覚オブジェクトのコード化--Part2:、」 「視覚です」。
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-
visual objects - Part3: Audio".
3 ISO/IEC14496-3:1999、「情報技術--オーディオの視覚オブジェクトのコード化--Part3:、」 「オーディオ。」
4 ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding
of audio-visual objects - Part 2: Visual, Amendment 1: Visual
extensions".
4ISO/IEC14496-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".
5ISO/IEC14496-3: 1999/Amd、.1:2000、「情報技術(視聴覚のオブジェクトのコード化)Part3:」 オーディオ、修正1: 「オーディオ拡大。」
6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-
visual objects - Part1: Systems".
6 ISO/IEC14496-1:1999、「情報技術--オーディオの視覚オブジェクトのコード化--Part1:、」 「システム。」
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7 ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A
Transport Protocol for Real Time Applications", RFC 1889, January
1996.
8Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
9 ISO/IEC 14496-2:1999/Cor.1:2000, "Information technology - Coding
of audio-visual objects - Part2: Visual, Technical corrigendum 1".
9ISO/IEC14496-2: 1999/心臓、.1:2000、「情報技術(視聴覚のオブジェクトのコード化)Part2:」 視覚Technical間違い、1インチ。
Kikuchi, et al. Standards Track [Page 19] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[19ページ]RFC3016RTP有効搭載量形式
8. Authors' Addresses
8. 作者のアドレス
Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
芳広菊池東芝会社1、Komukai東芝町、幸区、212-8582、川崎(日本)
EMail: yoshihiro.kikuchi@toshiba.co.jp
メール: yoshihiro.kikuchi@toshiba.co.jp
Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan
義紀松井松下電器産業社のLtd.1006、門真、門真市、大阪、日本
EMail: matsui@drl.mei.co.jp
メール: matsui@drl.mei.co.jp
Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
野村NEC4-1-1、宮崎、敏幸ミヤマエ区川崎(日本)
EMail: t-nomura@ccm.cl.nec.co.jp
メール: 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沖電気工業株式会社1-2-27Shiromi、中央区、日本大阪540-6025。
EMail: fukunaga444@oki.co.jp
メール: fukunaga444@oki.co.jp
Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
Hideaki Kimata NTT1-1、光ノー、がokaしている横須賀市、神奈川、日本
EMail: kimata@nttvdt.hil.ntt.co.jp
メール: kimata@nttvdt.hil.ntt.co.jp
Kikuchi, et al. Standards Track [Page 20] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual November 2000
菊池、他 2000年11月のオーディオの、または、視覚のMPEG-4のための標準化過程[20ページ]RFC3016RTP有効搭載量形式
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Kikuchi, et al. Standards Track [Page 21]
菊池、他 標準化過程[21ページ]
一覧
スポンサーリンク
