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