Network Working Group R. Finlayson
Request for Comments: 5219 Live Networks, Inc.
Obsoletes: 3119 February 2008
Category: Standard Track
A More Loss-Tolerant RTP Payload Format for MP3 Audio
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices.
この文書では、MPEG（動画像専門家グループ）（一般に「MP3」として知られている）1または2、レイヤーIIIの音声を輸送するためのRTP（リアルタイムプロトコル）ペイロード形式について説明します。このフォーマットは、RFC 2250に記載されているものに代わるものであり、パケット損失がある場合に良好に機能します。この文書では、「SDP使い方」および擬似コード付録に誤植訂正、RFC 3119を時代遅れ。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The Structure of MP3 Frames .....................................3
4. A New Payload Format ............................................4
4.1. ADU Frames .................................................4
4.2. ADU Descriptors ............................................4
4.3. Packing Rules ..............................................5
4.4. RTP Header Fields ..........................................6
4.5. Handling Received Data .....................................6
5. Handling Multiple MPEG Audio Layers .............................6
6. Frame Packetizing and Depacketizing .............................7
7. ADU Frame Interleaving ..........................................8
8. IANA Considerations ............................................10
9. SDP Usage ......................................................11
10. Security Considerations .......................................11
11. Acknowledgements ..............................................11
12. Normative References ..........................................12
Appendix A. Translating between "MP3 Frames" and "ADU Frames" .....13
A.1. Converting a Sequence of "MP3 Frames"
to a Sequence of "ADU Frames" .............................14
A.2. Converting a Sequence of "ADU Frames"
to a Sequence of "MP3 Frames" .............................15
Appendix B. Interleaving and Deinterleaving .......................18
B.1. Interleaving a Sequence of "ADU Frames" ...................18
B.2. Deinterleaving a Sequence of (Interleaved) "ADU Frames" ...19
Appendix C. Changes from RFC 3119 .................................20
While the RTP payload format defined in RFC 2250 [1] is generally applicable to all forms of MPEG audio or video, it is sub-optimal for MPEG-1 or 2, layer III audio (commonly known as "MP3"). The reason for this is that an MP3 frame is not a true "Application Data Unit" -- it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss.
RTPペイロードフォーマットは、RFC 2250で定義されている間、[1] MPEGオーディオやビデオの全ての形態に適用可能であり、それは（一般に「MP3」としても知られる）MPEG-1又は2、レイヤIIIオーディオ用のサブ最適です。この理由は、MP3フレームが真の「アプリケーション・データ・ユニット」ではないということです - それは、以前のフレーム内のデータへのバックポインタが含まれており、その独立してこれらの以前のフレームのデコードすることはできません。 RFC 2250は、パケット境界がフレームの境界と一致することを規定しているのでMP3データを搬送する際に、それは非効率的にパケットロスを処理します。以前の（または将来）は役に立たないフレームでMP3フレームの損失は、彼らが損失することなく受信しても、いくつかのデータをレンダリングします。
In this document, we define an alternative RTP payload format for MP3 audio. This format uses a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 "Application Data Units", which can also (optionally) be rearranged in an interleaving pattern. This new format is therefore more data efficient than RFC 2250 in the face of packet loss.
この文書では、我々は、MP3オーディオのための代替のRTPペイロードフォーマットを定義します。パケット境界は今も（オプションで）インターリーブパターンに再配置することができる真MP3「アプリケーションデータユニット」と一致するように、このフォーマットは、元のMPEGフレームのデータ保存再配置を使用します。この新しいフォーマットは、パケット損失に直面してRFC 2250よりも効率的なので、多くのデータです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
In this section we give a brief overview of the structure of an MP3 frame. (For a more detailed description, see the MPEG-1 audio [3] and MPEG-2 audio [4] specifications.)
このセクションでは、MP3フレームの構造の概要を与えます。 （詳細な説明については、MPEG-1オーディオ[3]、MPEG-2オーディオ[4]の仕様を参照）。
Each MPEG audio frame begins with a 4-byte header. Information defined by this header includes:
各MPEGオーディオフレームは、4バイトのヘッダで始まります。このヘッダによって定義される情報を含みます：
- Whether the audio is MPEG-1 or MPEG-2. - Whether the audio is layer I, II, or III. (The remainder of this document assumes layer III, i.e., "MP3" frames.) - Whether the audio is mono or stereo. - Whether or not there is a 2-byte CRC field following the header. - (indirectly) The size of the frame.
- オーディオはMPEG-1またはMPEG-2であるかどうか。 - オーディオレイヤーI、II、またはIIIであるかどうか。 （この文書の残りの部分は、層III、すなわち、「MP3」フレームを想定している。） - オーディオはモノまたはステレオであるかどうか。 - ヘッダに続く2バイトのCRCフィールドが存在するか否か。 - フレームの（間接的に）サイズ。
The following structures appear after the header:
以下の構造は、ヘッダの後に表示されます。
- (optionally) A 2-byte Cyclic Redundancy Check (CRC) field - A "side info" structure. This has the following length: - 32 bytes for MPEG-1 stereo - 17 bytes for MPEG-1 mono, or for MPEG-2 stereo - 9 bytes for MPEG-2 mono - Encoded audio data, plus optional ancillary data (filling out the rest of the frame)
- （オプション）2バイトの巡回冗長検査（CRC）フィールド - 「サイド情報」構造。記入エンコードされたオーディオデータに加え、オプションの補助データ（ - MPEG-1ステレオのための32バイト - - MPEG-1モノため、またはMPEG-2のステレオのための17バイト - 9 MPEG-2モノのバイト：これは、以下の長さを有していますフレームの残りの部分）
For the purpose of this document, the "side info" structure is the most important, because it defines the location and size of the "Application Data Unit" (ADU) that an MP3 decoder will process. In particular, the "side info" structure defines:
それはMP3デコーダが処理することを「アプリケーション・データ・ユニット」（ADU）の位置とサイズを定義するため、このドキュメントの目的のために、「サイド情報」構造は、最も重要です。具体的には、「サイド情報」構造が定義されています。
- "main_data_begin": This is a back-pointer (in bytes) to the start of the ADU. The back-pointer is counted from the beginning of the frame, and counts only encoded audio data and any ancillary data (i.e., ignoring any header, CRC, or "side info" fields).
- 「main_data_begin」：これは、ADUの開始バックポインタ（バイト単位）です。バックポインタは、フレームの先頭から数えて、カウントはオーディオデータのみと任意の補助データを符号化される（すなわち、任意のヘッダ、CRC、または「サイド情報」フィールドを無視します）。
An MP3 decoder processes each ADU independently. The ADUs will generally vary in length, but their average length will, of course, be that of the of the MP3 frames (minus the length of the header, CRC, and "side info" fields). (In MPEG literature, this ADU is sometimes referred to as a "bit reservoir".)
MP3デコーダは、それぞれ独立しADUを処理します。 ADUは、一般的に長さが変化することになるが、その平均長さは、当然のことながら、MP3フレーム（マイナスヘッダの長さ、CRC、及び「サイド情報」フィールド）のものであろう。 （MPEG文献では、このADUは、時には、「ビットリザーバ」と呼びます。）
As noted in [5], a payload format should be designed so that packet boundaries coincide with "codec frame boundaries" -- i.e., with ADUs. In the RFC 2250 payload format for MPEG audio [1], each RTP packet payload contains MP3 frames. In this new payload format for MP3 audio, however, each RTP packet payload contains "ADU frames", each preceded by an "ADU descriptor".
ADUと、すなわち - で述べたように、パケット境界は「コーデックフレーム境界」に一致するように[5]、ペイロードフォーマットが設計されなければなりません。 MPEGオーディオ[1]のためのRFC 2250ペイロード形式で、各RTPパケットのペイロードは、MP3のフレームを含みます。 MP3オーディオのためのこの新しいペイロードフォーマットでは、しかし、各RTPパケットのペイロードには、「ADUフレーム」、「ADU記述子」が先行それぞれが含まれています。
An "ADU frame" is defined as:
「ADUフレーム」は次のように定義されます
- The 4-byte MPEG header (the same as the original MP3 frame, except that the first 11 bits are (optionally) replaced by an "Interleaving Sequence Number", as described in Section 7 below) - The optional 2-byte CRC field (the same as the original MP3 frame) - The "side info" structure (the same as the original MP3 frame) - The complete sequence of encoded audio data (and any ancillary data) for the ADU (i.e., running from the start of this MP3 frame's "main_data_begin" back-pointer, up to the start of the next MP3 frame's back-pointer)
- 4バイトのMPEGヘッダ（以下のセクション7で説明したように最初の11ビットは（任意に）、「インターリービングシーケンス番号」で置き換えられていることを除いて、元のMP3フレームと同じ） - オプション2バイトのCRCフィールド（オリジナルのMP3フレームと同じ） - 「サイド情報」構造（オリジナルMP3フレームと同じ） - （ADUのための符号化された音声データ（および任意の補助データ）の完全な配列は、すなわち、開始から実行していますこのMP3フレームの「main_data_begin」バックポインタ、次のMP3フレームのバックポインタの開始まで）
Note that there is a one-to-one mapping between MP3 frames and ADU frames. Because MP3 frames are self-describing, with the bitrate (and sampling frequency) encoded within the 4-byte MPEG header, the same is true for ADU frames. Therefore, as with MP3 streams, the bitrate can change within a stream and may be used for congestion control.
MP3フレームとADUフレームの間に1対1のマッピングがあることに注意してください。 MP3フレームは自己記述、ビットレート（サンプリング周波数）と4バイトのMPEGヘッダ内に符号化されるので、同じことがADUフレームについても同様です。したがって、MP3ストリームと同様に、ビットレートは、ストリーム内で変化することができ、輻輳制御のために使用することができます。
Within each RTP packet payload, each "ADU frame" is preceded by a 1- or 2-byte "ADU descriptor", which gives the size of the ADU and indicates whether or not this packet's data is a continuation of the previous packet's data. (This occurs only when a single "ADU descriptor" + "ADU frame" is too large to fit within an RTP packet.)
各RTPパケットのペイロード内に、各「ADUフレームは、」ADUのサイズを与え、このパケットのデータが以前のパケットのデータの続きであるか否かを示す1または2バイトの「ADU記述子」によって先行されます。 （これは、単一の「ADU記述子」+「ADUフレーム」がRTPパケット内に収まるように大きすぎる場合にのみ発生します。）
An ADU descriptor consists of the following fields:
ADU記述子には、次のフィールドで構成されています。
- "C": Continuation flag (1 bit): 1, if the data following the ADU descriptor is a continuation of an ADU frame that was too large to fit within a single RTP packet; 0 otherwise.
- 「C」：継続フラグ（1ビット）：1、ADU記述子以下のデータを単一のRTPパケット内に収まるように大きすぎたADUフレームの継続である場合、それ以外の場合は0。
- "T": Descriptor Type flag (1 bit): 0 if this is a 1-byte ADU descriptor; 1 if this is a 2-byte ADU descriptor.
- 「T」：記述子タイプフラグ（1ビット）：0これは1バイトのADU記述子である場合、 1これは2バイトのADU記述子である場合。
- "ADU size" (6 or 14 bits): The size (in bytes) of the ADU frame that will follow this ADU descriptor (i.e., NOT including the size of the descriptor itself). A 2-byte ADU descriptor (with a 14-bit "ADU size" field) is used for ADU frame sizes of 64 bytes or more. For smaller ADU frame sizes, senders MAY alternatively use a 1-byte ADU descriptor (with a 6-bit "ADU size" field). Receivers MUST be able to accept an ADU descriptor of either size.
- 「ADUサイズ」（6または14ビット）：（即ち、ディスクリプタ自体の大きさを含まない）このADU記述子に続くADUフレームのサイズ（バイト単位）。 （14ビットの「ADUサイズ」フィールドを持つ）2バイトのADU記述子は64バイト以上のADUフレームサイズのために使用されます。小さいADUフレームサイズのために、送信者は、代わりに（6ビットの「ADUサイズ」フィールドを有する）1バイトのADU記述子を使用するかもしれません。レシーバは、いずれかのサイズのADU記述子を受け入れることができなければなりません。
Thus, a 1-byte ADU descriptor is formatted as follows:
次のようにこのように、1バイトのADU記述子がフォーマットされます：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|0| ADU size |
+-+-+-+-+-+-+-+-+
and a 2-byte ADU descriptor is formatted as follows:
次のように2バイトのADU記述子がフォーマットされます：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|1| ADU size (14 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each RTP packet payload begins with an "ADU descriptor", followed by "ADU frame" data. Normally, this "ADU descriptor" + "ADU frame" will fit completely within the RTP packet. In this case, more than one successive "ADU descriptor" + "ADU frame" MAY be packed into a single RTP packet, provided that they all fit completely.
各RTPパケットのペイロードには、「ADUフレーム」データに続く「ADU記述子」で始まります。通常、この「ADU記述子は」+「ADUフレーム」RTPパケット内に完全にフィットします。この場合、複数の連続した「ADU記述子」+「ADUフレーム」は、単一のRTPパケットに詰め、それら全てが完全に収まることを提供することができます。
If, however, a single "ADU descriptor" + "ADU frame" is too large to fit within an RTP packet, then the "ADU frame" is split across two or more successive RTP packets. Each such packet begins with an ADU descriptor. The first packet's descriptor has a "C" (continuation) flag of 0; the following packets' descriptors each have a "C" flag of 1. Each descriptor, in this case, has the same "ADU size" value: the size of the entire "ADU frame" (not just the portion that will fit within a single RTP packet). Each such packet (even the last one) contains only one "ADU descriptor".
しかし、シングル「ADU記述子」+「ADUフレーム」は、RTPパケット内に収まるには大きすぎるし、「ADUフレーム」とは、2つの以上の連続したRTPパケットに分割されている場合。ような各パケットは、ADUの記述から始まります。最初のパケットの記述子は、0の「C」（継続）フラグを有しています。全体 『ADUフレーム』内に収まる（だけでなく、部分の大きさ：以下のパケットの記述子各々は、この場合、各記述子1の 『C』フラグを持って、同じ 『ADUサイズ』の値を有します単一RTPパケット）。それぞれのそのようなパケット（でも最後のものは）唯一の「ADU記述子」が含まれています。
Payload Type: The (static) payload type 14 that was defined for MPEG audio [6] MUST NOT be used. Instead, a different, dynamic payload type MUST be used -- i.e., one within the range [96..127].
ペイロードタイプ：MPEGオーディオ用に定義された（静的な）ペイロードタイプ14 [6]を使用してはいけません。代わりに、異なる、ダイナミックペイロードタイプを使用しなければならない - すなわち、範囲[96..127]内の一つ。
M bit: This payload format defines no use for this bit. Senders SHOULD set this bit to zero in each outgoing packet.
Mビット：このペイロード形式は、このビットのための使用を定義していません。送信者は、各発信パケットにゼロにこのビットを設定する必要があります。
Timestamp: This is a 32-bit, 90 kHz timestamp, representing the presentation time of the first ADU packed within the packet.
タイムスタンプ：これはパケット内にパックされた最初のADUのプレゼンテーション時間を示す、32ビット、90 kHzのタイムスタンプです。
Note that no information is lost by converting a sequence of MP3 frames to a corresponding sequence of "ADU frames", so a receiving RTP implementation can either feed the ADU frames directly to an appropriately modified MP3 decoder, or convert them back into a sequence of MP3 frames, as described in Appendix A.2 below.
そう受信RTP実装はADUは適宜変更MP3デコーダに直接フレームを供給するか、または背面の配列に変換し、何も情報が「ADUフレーム」の対応する配列にMP3フレームのシーケンスを変換することによって失われないことに注意してくださいMP3フレーム、下記の付録A.2で説明したように。
The RTP payload format described here is intended only for MPEG-1 or 2, layer III audio ("MP3"). In contrast, layer I and layer II frames are self-contained, without a back-pointer to earlier frames. However, it is possible (although unusual) for a sequence of audio frames to consist of a mixture of layer III frames, and layer I or II frames. When such a sequence is transmitted, only layer III frames are converted to ADUs; layer I or II frames are sent 'as is' (except for the prepending of an "ADU descriptor"). Similarly, the receiver of a sequence of frames -- using this payload format -- leaves layer I and II frames untouched (after removing the prepended "ADU descriptor"), but converts layer III frames from "ADU frames" to regular MP3 frames. (Recall that each frame's layer is identified from its 4-byte MPEG header.)
ここで説明したRTPペイロードフォーマットは、MPEG-1、または2、レイヤIIIオーディオ（「MP3」）のためにのみ意図されています。対照的に、層IとIIフレーム層は、以前のフレームへのバックポインタなしで、自己完結型です。しかし、オーディオ・フレームのシーケンスが層IIIフレームの混合物からなることのために（珍しいが）可能であり、層IまたはIIフレーム。そのようなシーケンスが送信されると、唯一の層IIIのフレームがのADUに変換されます。 （「ADU記述子」のプリペンディングを除く）「そのまま」層IまたはIIのフレームが送信されます。同様に、フレームのシーケンスの受信機 - このペイロードフォーマットを使用しては - （プリペンド「ADU記述子」を除去した後）、そのまま層I及びIIフレームを残すが、定期的なMP3フレームに「ADUフレーム」からレイヤIIIのフレームを変換します。 （各フレームの層は、その4バイトのMPEGヘッダから識別されることを想起されたいです。）
If you are transmitting a stream consisting *only* of layer I or layer II frames (i.e., without any MP3 data), then there is no benefit to using this payload format, *unless* you are using the interleaving mechanism described in Section 7 below.
あなただけの*層のIまたは層IIのフレーム（すなわち、任意のMP3データなし）*からなるストリームを送信している場合、このペイロード形式を使用する利点はありません、*あなたは第7節で説明したインターリーブ・メカニズムを使用しています*ない限り、未満。
The transmission of a sequence of MP3 frames takes the following steps:
MP3フレームのシーケンスの送信は、以下の手順を実行します。
MP3 frames
-1-> ADU frames
-2-> interleaved ADU frames
-3-> RTP packets
Step 1 is the conversion of a sequence of MP3 frames to a corresponding sequence of ADU frames, and takes place as described in Sections 3 and 4.1 above. (Note also the pseudo-code in Appendix A.1.)
ステップ1 ADUは、フレームの対応する配列にMP3フレームのシーケンスの変換であり、そして上記セクション3および4.1に記載のように行われます。 （また、付録A.1に擬似コードに注意してください。）
Step 2 is the reordering of the sequence of ADU frames in an (optional) interleaving pattern, prior to packetization, as described in section 7 below. (Note also the pseudo-code in Appendix B.1.) Interleaving helps reduce the effect of packet loss by distributing consecutive ADU frames over non-consecutive packets. (Note that because of the back-pointer in MP3 frames, interleaving can be applied -- in general -- only to ADU frames. Thus, interleaving was not possible for RFC 2250.)
ステップ2は、以下のセクション7に記載されるようにADUの配列の並べ替えは、前パケットに、（オプション）インターリーブパターンのフレームです。 （また、付録B.1における擬似コードに注意してください。）インターリービングは、非連続的なパケットにわたって連続ADUフレームを分配することによりパケット損失の影響を減らすことができます。 （ - 一般的には - 理由MP3フレームにおけるバックポインタ、インタリーブを適用することができるだけADUにフレームしたがって、インターリービングは、RFC 2250のために不可能でした。）
Step 3 is the packetizing of a sequence of (interleaved) ADU frames into RTP packets -- as described in section 4.3 above. Each packet's RTP timestamp is the presentation time of the first ADU that is packed within it. Note that if interleaving was done in step 2, the RTP timestamps on outgoing packets will not necessarily be monotonically nondecreasing.
上記セクション4.3に記載したように - ステップ3（インターリーブ）ADUがRTPパケットにフレームのシーケンスのパケットです。各パケットのRTPタイムスタンプは、その中に詰め込まれている最初のADUのプレゼンテーション時間です。インターリーブステップ2で行われた場合、発信パケットにRTPタイムスタンプは必ずしも単調非減少ではないことに注意してください。
Similarly, a sequence of received RTP packets is handled as follows:
以下同様に、受信したRTPパケットのシーケンスが処理されます。
RTP packets
-4-> RTP packets ordered by RTP sequence number
-5-> interleaved ADU frames
-6-> ADU frames
-7-> MP3 frames
Step 4 is the usual sorting of incoming RTP packets using the RTP sequence number.
ステップ4は、RTPシーケンス番号を使用して、着信RTPパケットの通常の分類です。
Step 5 is the depacketizing of ADU frames from RTP packets -- i.e., the reverse of step 3. As part of this process, a receiver uses the "C" (continuation) flag in the ADU descriptor to notice when an ADU frame is split over more than one packet (and to discard the ADU frame entirely if one of these packets is lost).
ステップ5は、ADUのデパケタイズは、RTPパケットからフレームである - すなわち、ステップ3の逆このプロセスの一部として、受信機は、ADUフレームが分割されるときに気づくことADU記述子の「C」（継続）フラグを使用して複数のパケットを超える（およびこれらのパケットの1つが失われた場合、完全にADUフレームを廃棄します）。
Step 6 is the rearranging of the sequence of ADU frames back to its original order (except for ADU frames missing due to packet loss), as described in Section 7 below. (Note also the pseudo-code in Appendix B.2.)
ステップ6は、以下のセクション7に記載されるようにADUの配列の並び替えは、（パケット損失に欠落フレームADUを除く）元の順にフレームです。 （また、付録B.2における擬似コードに注意してください。）
Step 7 is the conversion of the sequence of ADU frames into a corresponding sequence of MP3 frames -- i.e., the reverse of step 1. (Note also the pseudo-code in Appendix A.2.) With an appropriately modified MP3 decoder, an implementation may omit this step; instead, it could feed ADU frames directly to the (modified) MP3 decoder.
ステップ7は、ADUの配列の変換は、MP3フレームの対応する配列にフレームである - すなわち、ステップ1の逆（また付録A.2に擬似コードに注意してください。）適切に修飾MP3デコーダ、ANと実装は、このステップを省略してもよいです。代わりに、ADUは、（変性）MP3デコーダに直接フレームを供給できました。
In MPEG audio frames (MPEG-1 or 2; all layers), the high-order 11 bits of the 4-byte MPEG header ('syncword') are always all-one (i.e., 0xFFE). When reordering a sequence of ADU frames for transmission, we reuse these 11 bits as an "Interleaving Sequence Number" (ISN). (Upon reception, they are replaced with 0xFFE once again.)
MPEGオーディオフレーム（MPEG-1又は2であり;全ての層）に、4バイトのMPEGヘッダの上位11ビット（ '同期語'）は、常にすべてオン（即ち、0xFFE）です。 ADUのシーケンスを再順序付けする送信のためにフレームとき、我々は、「インターリービングシーケンス番号」（ISN）のように、これらの11ビットを再利用します。 （受信すると、彼らは再び0xFFEに置き換えられます。）
The structure of the ISN is (a,b), where:
ISNの構造は（a、b）は、ここで：
- a == bits 0-7: 8-bit Interleave Index (within Cycle)
- b == bits 8-10: 3-bit Interleave Cycle Count
That is, the 4-byte MPEG header is reused as follows:
つまり、次のように4バイトのMPEGヘッダが再利用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Interleave Idx |CycCt| The rest of the original MPEG header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example: Consider the following interleave cycle (of size 8):
例：（サイズ8）以下のインターリーブサイクルを考慮してください。
1,3,5,7,0,2,4,6
１、３、５、７、０、２、４、６
(This particular pattern has the property that any loss of up to four consecutive ADUs in the interleaved stream will lead to a deinterleaved stream with no gaps greater than one.) This produces the following sequence of ISNs:
（この特定のパターンは、インターリーブドストリームで最大4つの連続のADUの損失が1より大きいないギャップのデインターリーブストリームにつながる特性を有している。）これはISNの次のシーケンスを生成します。
(1,0) (3,0) (5,0) (7,0) (0,0) (2,0) (4,0) (6,0) (1,1) (3,1) (5,1) etc.
（1,0）（3,0）（5,0）（7,0）（0,0）（2,0）（4,0）（6,0）（1,1）（3,1） （5,1）等
So, in this example, a sequence of ADU frames
したがって、この例では、ADUのシーケンスは、フレーム
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 (etc.)
F0、F1、F2、F3、F4、F5 F6 F7 F8 F9（など）
would get reordered, in step 2, into:
ステップ2で、並べ替えになるだろう：
(1,0)f1 (3,0)f3 (5,0)f5 (7,0)f7 (0,0)f0 (2,0)f2 (4,0)f4 (6,0)f6 (1,1)f9 (3,1)f11 (5,1)f13 (etc.)
（1,0）F1（3,0）F3（5,0）F5（7,0）、F7（0,0）F0（2,0）、F2（4,0）F4（6,0）、F6（1 、1）F9（3,1）、F11（5,1）、F13（等）
and the reverse reordering (along with replacement of the 0xFFE) would occur upon reception.
及び（0xFFEの交換に伴って）逆並べ替えは、受信時に起こります。
The reason for breaking the ISN into "Interleave Cycle Count" and "Interleave Index" (rather than just treating it as a single 11-bit counter) is to give receivers a way of knowing when an ADU frame should be 'released' to the ADU->MP3 conversion process (step 7 above), rather than waiting for more interleaved ADU frames to arrive. For instance, in the example above, when the receiver sees a frame with ISN (<something>,1), it knows that it can release all previously seen frames with ISN (<something>,0), even if some other (<something>,0) frames remain missing due to packet loss. An 8-bit Interleave Index allows interleave cycles of size up to 256.
「インターリーブサイクル・カウント」と「インターリーブインデックス」にISNを壊す（だけではなく、単一の11ビットカウンタとしてそれを処理する）理由は、受信機にADUフレームがに「をリリース」されなければならない時に知る方法を提供することですADU-> MP3変換処理（上記ステップ7）、むしろ到達するよりインターリーブADUフレームを待っているより。例えば、受信機はISNを有するフレーム見たとき、上記の例では、（<何か>を、1）、それはISNを持つすべての以前に見られるフレームを放出することができることを知っている（<何か> 0）場合であっても（いくつかの他の<何か>、0）のフレームは、パケット損失に行方不明のまま。 8ビットインターリーブ指数は256にサイズアップのインターリーブサイクルを可能にします。
The choice of an interleaving order can be made independently of RTP packetization. Thus, a simple implementation could choose an interleaving order first, reorder the ADU frames accordingly (step 2), then simply pack them sequentially into RTP packets (step 3). However, the size of ADU frames -- and thus the number of ADU frames that will fit in each RTP packet -- will typically vary in size, so a more optimal implementation would combine steps 2 and 3, by choosing an interleaving order that better reflected the number of ADU frames packed within each RTP packet.
インターリーブ順序の選択は、独立したRTPパケットで作ることができます。したがって、単純な実装は、単に順次RTPパケット（ステップ3）にそれらをパックし、ADUはそれに応じてフレーム（ステップ2）を並べ替え、最初のインターリーブ順序を選ぶことができます。ただし、ADUのサイズは、フレーム - 、したがって、各RTPパケットに収まるADUフレームの数が - 典型的には、これより最適な実装がより良いことをインターリーブ順序を選択することにより、ステップ2及び3を組み合わせてなり、サイズが変化することになります各RTPパケット内にパックされたADUフレームの数を反映しています。
Each receiving implementation of this payload format MUST recognize the ISN and be able to perform deinterleaving of incoming ADU frames (step 6). However, a sending implementation of this payload format MAY choose not to perform interleaving -- i.e., by omitting step 2. In this case, the high-order 11 bits in each 4-byte MPEG header would remain at 0xFFE. Receiving implementations would thus see a sequence of identical ISNs (all 0xFFE). They would handle this in the same way as if the Interleave Cycle Count changed with each ADU frame, by simply releasing the sequence of incoming ADU frames sequentially to the ADU->MP3 conversion process (step 7), without reordering. (Note also the pseudo-code in Appendix B.2.)
このペイロード形式の各受信実装はISNを認識し、着信ADUフレーム（ステップ6）のデインタリーブを行うことができなければなりません。すなわち、この場合には、ステップ2を省略することによって、各4バイトのMPEGヘッダ内の上位11ビットが0xFFEのままであろう - しかし、このペイロード形式の送信の実装は、インターリービングを実行しないことを選んでもよいです。受信の実装は、このように、同一のISN（すべて0xFFE）の配列を見るであろう。インターリーブサイクルは単に着信ADUの配列並べ替えずに、ADU-> MP3変換処理（ステップ7）へ順次フレームを解放することによって、各ADUフレームで変更カウントかのように、彼らは同じようにこれを処理することになります。 （また、付録B.2における擬似コードに注意してください。）
Media type name: audio
メディアタイプ名：オーディオ
Media subtype: mpa-robust
メディアサブタイプ：MPA-堅牢
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: This type is defined only for transfer via RTP, as specified in RFC 5219.
エンコードの考慮事項：RFC 5219で指定されている。このタイプは、RTP経由でのみ転送のために定義されています。
Security considerations: See the "Security Considerations" section of RFC 5219.
セキュリティに関する考慮事項：RFC 5219の「セキュリティの考慮事項」を参照してください。
Interoperability considerations: This encoding is incompatible with both the "audio/mpa" and "audio/mpeg" media types.
相互運用性に関する注意事項：このエンコーディングは、「オーディオ/ MPA」と「オーディオ/ mpegの」メディアタイプの両方と互換性がありません。
Published specification: The ISO/IEC MPEG-1 [3] and MPEG-2 [4] audio specifications, and RFC 5219.
公開された仕様：ISO / IEC MPEG-1 [3]、MPEG-2 [4]オーディオ仕様、およびRFC 5219。
Applications that use this media type: Audio streaming tools (transmitting and receiving)
このメディアタイプを使用するアプリケーション：オーディオストリーミングツール（送受信）
Additional information: none
追加情報：なし
Person & email address to contact for further information: Ross Finlayson finlayson@live555.com
人とEメールアドレスは、詳細についての問い合わせ先：ロス・フィンレイソンfinlayson@live555.com
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Author: Ross Finlayson Change controller: IETF AVT Working Group
著者/変更コントローラ：著者：ロス・フィンレイソンの変更コントローラ：IETF AVT作業部会
When conveying information by SDP [7], the encoding name SHALL be "mpa-robust" (the same as the media subtype). An example of the media representation in SDP is:
SDP [7]によって情報を伝達する際に、符号化名は、「MPA-ロバスト」（メディアサブタイプと同じ）でなければなりません。 SDP内のメディア表現の例です。
m=audio 49000 RTP/AVP 121
a=rtpmap:121 mpa-robust/90000
Note that the RTP timestamp frequency MUST be 90000.
RTPタイムスタンプの周波数は90000でなければならないことに注意してください。
If a session using this payload format is being encrypted, and interleaving is being used, then the sender SHOULD ensure that any change of encryption key coincides with a start of a new interleave cycle. Apart from this, the security considerations for this payload format are identical to those noted for RFC 2250 [1].
このペイロード形式を使用して、セッションが暗号化されている、とインターリーブが使用されている場合は、送信者は、暗号化キーの変更は、新しいインターリーブサイクルの開始と一致することを確認してください。これとは別に、このペイロード形式のためのセキュリティ上の考慮事項[1] RFC 2250のために述べたものと同一です。
The suggestion of adding an interleaving option (using the first bits of the MPEG 'syncword' -- which would otherwise be all-ones -- as an interleaving index) is due to Dave Singer and Stefan Gewinner. In addition, Dave Singer provided valuable feedback that helped clarify
（ - そうでなければすべてのものであろう - MPEG「同期ワード」の最初のビットを用いてインターリービングインデックスとして）インタリーブオプションを追加する提案がデイブ歌手とステファンGewinnerによるものです。また、デイブ・シンガーは明確に役立った貴重なフィードバックを提供しました
and improve the description of this payload format. Feedback from Chris Sloan led to the addition of an "ADU descriptor" preceding each ADU frame in the RTP packet.
このペイロード形式の記述を改善します。クリス・スローンからのフィードバックは、RTPパケット内の各ADUフレームの前の「ADU記述子」のほかにつながりました。
[1] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[1]ホフマン、D.、フェルナンド、G.、Goyal氏、V.、およびM. Civanlar、 "MPEG1 / MPEG2ビデオのためのRTPペイロードフォーマット"、RFC 2250、1998年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] ISO/IEC International Standard 11172-3; "Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbits/s -- Part 3: Audio", 1993.
[3] ISO / IEC国際規格11172-3。 「およそ1.5メガビット/秒までのデジタル記憶媒体のための画像と関連したオーディオを動かすのコーディング - パート3：オーディオ」、1993年。
[4] ISO/IEC International Standard 13818-3; "Generic coding of moving pictures and associated audio information -- Part 3: Audio", 1998.
[4] ISO / IEC国際規格13818-3。 「映画と関連オーディオ情報のジェネリックコーディング - パート3：オーディオ」、1998年。
[5] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[5]ハンドリー、M.とC.パーキンス、 "RTPペイロードフォーマット仕様の作家のためのガイドライン"、BCP 36、RFC 2736、1999年12月に。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
Appendix A. Translating between "MP3 Frames" and "ADU Frames"
「MP3のフレーム」と「ADUフレーム」との付録A.翻訳
The following 'pseudo code' describes how a sender using this payload format can translate a sequence of regular "MP3 Frames" to "ADU Frames", and how a receiver can perform the reverse translation: from "ADU Frames" to "MP3 Frames".
「ADUフレーム」から「MP3のフレーム」に次の「疑似コード」は、このペイロード形式を使用して、送信者が「ADUフレーム」に、通常の「MP3のフレーム」のシーケンスを翻訳することができ、そしてどのように受信機は逆の変換を実行する方法について説明します。
We first define the following abstract data structures:
私たちは、最初に次の抽象データ構造を定義します。
- "Segment": A record that represents either a "MP3 Frame" or an "ADU Frame". It consists of the following fields: - "header": the 4-byte MPEG header - "headerSize": a constant (== 4) - "sideInfo": the 'side info' structure, *including* the optional 2-byte CRC field, if present - "sideInfoSize": the size (in bytes) of the above structure - "frameData": the remaining data in this frame - "frameDataSize": the size (in bytes) of the above data - "backpointer": the value (expressed in bytes) of the backpointer for this frame - "aduDataSize": the size (in bytes) of the ADU associated with this frame. (If the frame is already an "ADU Frame", then aduDataSize == frameDataSize) - "mp3FrameSize": the total size (in bytes) that this frame would have if it were a regular "MP3 Frame". (If it is already a "MP3 Frame", then mp3FrameSize == headerSize + sideInfoSize + frameDataSize) Note that this size can be derived completely from "header".
- 「セグメント」：「MP3フレーム」または「ADUフレーム」のいずれかを表すレコード。それは、以下のフィールドからなる： - 「ヘッダ」：4バイトのMPEGヘッダ - 「headerSize」：定数（== 4） - 「SIDEINFO」：「サイド情報」構造、*など*任意の2バイトCRCフィールドは、存在する場合 - 「sideInfoSize」：上記構造体のサイズ（バイト単位） - 「frameData」：このフレームの残りのデータ - 「frameDataSize」：上記データのサイズ（バイト単位） - 「バックポインタ」このフレームのバックポインタの（バイト単位）値 - 「aduDataSize」：このフレームに関連付けられているADUのサイズ（バイト単位）。 （フレームはすでに「ADUフレーム」、そしてaduDataSize == frameDataSizeある場合） - 「mp3FrameSize」：合計サイズ（バイト）、それは通常の「MP3フレーム」であれば、このフレームは持っているだろうと。 （それは既に「MP3フレーム」である場合、mp3FrameSize == headerSize + sideInfoSize + frameDataSize）このサイズは、「ヘッダ」から完全に誘導することができることに留意されたいです。
- "SegmentQueue": A FIFO queue of "Segments", with operations - void enqueue(Segment) - Segment dequeue() - Boolean isEmpty() - Segment head() - Segment tail() - Segment previous(Segment): returns the segment prior to a given one - Segment next(Segment): returns the segment after a given one - unsigned totalDataSize(): returns the sum of the "frameDataSize" fields of each entry in the queue
- "SegmentQueue"：操作で、 "セグメント"、のFIFOキュー - 無効エンキュー（セグメント） - セグメントデキュー（） - ブールのisEmpty（） - セグメント頭（） - セグメント尾（） - セグメント前回（セグメント）：返します与えられたものと前のセグメント - セグメント次（セグメント） - ：キュー内の各エントリの「frameDataSize」フィールドの合計を返し符号なしtotalDataSize（）指定されたものの後のセグメントを返します
A.1. Converting a Sequence of "MP3 Frames" to a Sequence of "ADU Frames"
A.1。 「ADUフレーム」のシーケンスに「MP3のフレーム」のシーケンスを変換します
SegmentQueue pendingMP3Frames; // initially empty while (1) { // Enqueue new MP3 Frames, until we have enough data to // generate the ADU for a frame: do { int totalDataSizeBefore = pendingMP3Frames.totalDataSize();
SegmentQueue pendingMP3Frames; //最初は空ながら、（1）{//エンキュー新しいMP3のフレーム、私たちは//フレームのためにADUを生成するための十分なデータが得られるまで：DO {int型totalDataSizeBefore = pendingMP3Frames.totalDataSize（）;
Segment newFrame = 'the next MP3 Frame';
pendingMP3Frames.enqueue(newFrame);
int totalDataSizeAfter
= pendingMP3Frames.totalDataSize();
} while (totalDataSizeBefore < newFrame.backpointer ||
totalDataSizeAfter < newFrame.aduDataSize);
// We now have enough data to generate the ADU for the most // recently enqueued frame (i.e., the tail of the queue). // (The earlier frames in the queue -- if any -- must be // discarded, as we don't have enough data to generate // their ADUs.) Segment tailFrame = pendingMP3Frames.tail();
//私たちは今、最も//最近エンキューフレームのADUを生成するための十分なデータを持っている（すなわち、キューの末尾）。 //（キュー内に以前のフレーム - もしあれば - 私たちは//自分のADUを生成するための十分なデータを持っていないとして、//、廃棄しなければならない。））（セグメントtailFrame = pendingMP3Frames.tail。
// Output the header and side info:
output(tailFrame.header);
output(tailFrame.sideInfo);
// Go back to the frame that contains the start of our
// ADU data:
int offset = 0;
Segment curFrame = tailFrame;
int prevBytes = tailFrame.backpointer;
while (prevBytes > 0) {
curFrame = pendingMP3Frames.previous(curFrame);
int dataHere = curFrame.frameDataSize;
if (dataHere < prevBytes) {
prevBytes -= dataHere;
} else {
offset = dataHere - prevBytes;
break;
}
}
// Dequeue any frames that we no longer need: while (pendingMP3Frames.head() != curFrame) {
//デキュー任意のフレームを、私たちはもはや必要性：中（！pendingMP3Frames.head（）= curFrame）{
pendingMP3Frames.dequeue(); }
pendingMP3Frames.dequeue（）; }
// Output, from the remaining frames, the ADU data that
// we want:
int bytesToUse = tailFrame.aduDataSize;
while (bytesToUse > 0) {
int dataHere = curFrame.frameDataSize - offset;
int bytesUsedHere
= dataHere < bytesToUse ? dataHere :
bytesToUse;
output("bytesUsedHere" bytes from
curFrame.frameData, starting from "offset");
bytesToUse -= bytesUsedHere;
offset = 0;
curFrame = pendingMP3Frames.next(curFrame);
}
}
A.2. Converting a Sequence of "ADU Frames" to a Sequence of "MP3 Frames"
A.2。 「MP3のフレーム」のシーケンスに「ADUフレーム」のシーケンスを変換します
SegmentQueue pendingADUFrames; // initially empty
while (1) {
while (needToGetAnADU()) {
Segment newADU = 'the next ADU Frame';
pendingADUFrames.enqueue(newADU);
insertDummyADUsIfNecessary();
}
generateFrameFromHeadADU(); }
generateFrameFromHeadADU（）; }
Boolean needToGetAnADU() { // Checks whether we need to enqueue one or more new ADUs // before we have enough data to generate a frame for the // head ADU. Boolean needToEnqueue = True;
ブールneedToGetAnADU（）{//我々は//ヘッドADUのためのフレームを生成するための十分なデータを持って前に// 1つ以上の新しいのADUをエンキューする必要があるかどうかをチェックします。ブールneedToEnqueue =真;
if (!pendingADUFrames.isEmpty()) {
Segment curADU = pendingADUFrames.head();
int endOfHeadFrame = curADU.mp3FrameSize
- curADU.headerSize - curADU.sideInfoSize;
int frameOffset = 0;
while (1) {
int endOfData = frameOffset
- curADU.backpointer +
curADU.aduDataSize;
if (endOfData >= endOfHeadFrame) {
// We have enough data to generate a
// frame.
needToEnqueue = False;
break;
}
frameOffset += curADU.mp3FrameSize
- curADU.headerSize
- curADU.sideInfoSize;
if (curADU == pendingADUFrames.tail()) break;
curADU = pendingADUFrames.next(curADU);
}
}
return needToEnqueue; }
needToEnqueueを返します。 }
void generateFrameFromHeadADU() { Segment curADU = pendingADUFrames.head();
ボイドgenerateFrameFromHeadADU（）{セグメントキュレーション= pendingADUFrames.head（）。
// Output the header and side info:
output(curADU.header);
output(curADU.sideInfo);
// Begin by zeroing out the rest of the frame, in case the
// ADU data doesn't fill it in completely:
int endOfHeadFrame = curADU.mp3FrameSize
- curADU.headerSize - curADU.sideInfoSize;
output("endOfHeadFrame" zero bytes);
// Fill in the frame with appropriate ADU data from this and
// subsequent ADUs:
int frameOffset = 0;
int toOffset = 0;
while (toOffset < endOfHeadFrame) {
int startOfData = frameOffset - curADU.backpointer;
if (startOfData > endOfHeadFrame) {
break; // no more ADUs are needed
}
int endOfData = startOfData + curADU.aduDataSize;
if (endOfData > endOfHeadFrame) {
endOfData = endOfHeadFrame;
}
｝
int fromOffset;
if (startOfData <= toOffset) {
fromOffset = toOffset - startOfData;
startOfData = toOffset;
if (endOfData < startOfData) {
endOfData = startOfData;
}
} else {
fromOffset = 0;
// leave some zero bytes beforehand: toOffset = startOfData; }
//残すいくつかのゼロバイト予め：toOffset = startOfData。 }
int bytesUsedHere = endOfData - startOfData;
output(starting at offset "toOffset", "bytesUsedHere"
bytes from "&curADU.frameData[fromOffset]");
toOffset += bytesUsedHere;
frameOffset += curADU.mp3FrameSize
- curADU.headerSize - curADU.sideInfoSize;
curADU = pendingADUFrames.next(curADU);
}
pendingADUFrames.dequeue(); }
pendingADUFrames.dequeue（）; }
void insertDummyADUsIfNecessary() { // The tail segment (ADU) is assumed to have been recently // enqueued. If its backpointer would overlap the data // of the previous ADU, then we need to insert one or more // empty, 'dummy' ADUs ahead of it. (This situation // should occur only if an intermediate ADU was missing // -- e.g., due to packet loss.) while (1) { Segment tailADU = pendingADUFrames.tail(); int prevADUend; // relative to the start of the tail ADU
空insertDummyADUsIfNecessary（）{//尾セグメント（ADU）は、最近//エンキューされているものとします。そのバックポインタが//以前ADUのデータを重複したとすると、私たちは、一つ以上の//空の、それより前の「ダミー」のADUを挿入する必要があります。 （この状況//中間ADUが//欠落した場合にのみ起こるべきである - 例えば、パケット損失に。）一方、（1）{セグメントtailADU = pendingADUFrames.tail（）。 int型prevADUend; //テールADUの開始からの相対
if (pendingADUFrames.head() != tailADU) {
// there is a previous ADU
Segment prevADU
= pendingADUFrames.previous(tailADU);
prevADUend
= prevADU.mp3FrameSize +
prevADU.backpointer
- prevADU.headerSize
- prevADU.sideInfoSize;
if (prevADU.aduDataSize > prevADUend) {
// this shouldn't happen if the
// previous ADU was well-formed
prevADUend = 0;
} else {
prevADUend -= prevADU.aduDataSize;
}
} else {
prevADUend = 0;
}
if (tailADU.backpointer > prevADUend) { // Insert a 'dummy' ADU in front of the tail. // This ADU can have the same "header" (and thus, // "mp3FrameSize") as the tail ADU, but should // have a "backpointer" of "prevADUend", and // an "aduDataSize" of zero. The simplest // way to do this is to copy the "sideInfo" from // the tail ADU, replace the value of // "main_data_begin" with "prevADUend", and set // all of the "part2_3_length" fields to zero. } else { break; // no more dummy ADUs need to be // inserted } } }
（tailADU.backpointer> prevADUendは）{//尾の前で「ダミー」ADUを挿入した場合。 //ゼロの「aduDataSize」このADUは、テールADUと同じ「ヘッダ」（したがって、//「mp3FrameSize」）を有することができるが、//「はprevADUend」の「バックポインタ」を有するべきであり、//。これを実行する最も簡単な方法は、//、//テールADUから「SIDEINFOを」コピー「prevADUend」と//「main_data_begin」の値を交換して、ゼロに//「part2_3_length」すべてのフィールドを設定することです。 }他{破ります。 //これ以上ダミーのADUが//挿入する必要が}}}
Appendix B. Interleaving and Deinterleaving
付録B.インターリーブとデインターリーブ
The following 'pseudo code' describes how a sender can reorder a sequence of "ADU Frames" according to an interleaving pattern (step 2), and how a receiver can perform the reverse reordering (step 6).
以下「擬似コード」は、送信者がインターリーブパターン（ステップ2）によれば「ADUフレーム」の順序を並べ替えることができ、どの受信機が逆並び替え（ステップ6）を実行する方法について説明します。
B.1. Interleaving a Sequence of "ADU Frames"
B.1。 「ADUフレーム」のシーケンスをインターリーブ
We first define the following abstract data structures:
私たちは、最初に次の抽象データ構造を定義します。
- "interleaveCycleSize": an integer in the range [1..256] -- "interleaveCycle": an array, of size "interleaveCycleSize", containing some permutation of the integers from the set [0 .. interleaveCycleSize-1] e.g., if "interleaveCycleSize" == 8, "interleaveCycle" might contain: 1,3,5,7,0,2,4,6 - "inverseInterleaveCycle": an array containing the inverse of the permutation in "interleaveCycle" -- i.e., such that interleaveCycle[inverseInterleaveCycle[i]] == i - "ii": the current Interleave Index (initially 0) - "icc": the current Interleave Cycle Count (initially 0) - "aduFrameBuffer": an array, of size "interleaveCycleSize", of ADU Frames that are awaiting packetization
- "interleaveCycleSize"：範囲内の整数[1..256] - "interleaveCycle"：セットから整数のいくつかの順列を含むサイズの配列、 "interleaveCycleSize"、[0 .. interleaveCycleSize-1]例えば、場合は、「interleaveCycleSize」== 8は、「interleaveCycle」が含まれる場合があります。1,3,5,7,0,2,4,6 - 「inverseInterleaveCycleを」：「interleaveCycle」の順列の逆を含む配列 - すなわち、その結果interleaveCycle [inverseInterleaveCycle [I]] == I - "II"：現在のインターリーブインデックス（最初は0） - "ICC"：現在のインターリーブサイクル数（初期値は0） - "aduFrameBuffer"：サイズのアレイ、「パケットを待っているADUフレームのinterleaveCycleSize」、
while (1) {
int positionOfNextFrame = inverseInterleaveCycle[ii];
aduFrameBuffer[positionOfNextFrame] = the next ADU frame;
replace the high-order 11 bits of this frame's MPEG header
with (ii,icc);
// Note: Be sure to leave the remaining 21 bits
// as is
if (++ii == interleaveCycleSize) {
// We've finished this cycle, so pass all
// pending frames to the packetizing step
for (int i = 0; i < interleaveCycleSize; ++i) {
pass aduFrameBuffer[i] to the packetizing step;
}
ii = 0;
icc = (icc+1)%8;
}
}
B.2. Deinterleaving a Sequence of (Interleaved) "ADU Frames"
B.2。 （インターリーブ）「ADUフレーム」のシーケンスをデインタリーブ
We first define the following abstract data structures:
私たちは、最初に次の抽象データ構造を定義します。
- "ii": the Interleave Index from the current incoming ADU frame - "icc": the Interleave Cycle Count from the current incoming ADU frame - "iiLastSeen": the most recently seen Interleave Index (initially, some integer *not* in the range [0..255]) - "iccLastSeen": the most recently seen Interleave Cycle Count (initially, some integer *not* in the range [0..7]) - "aduFrameBuffer": an array, of size 256, of (pointers to) ADU Frames that have just been depacketized (initially, all entries are NULL)
- 「II」：現在の着信ADUフレームからインターリーブインデックス - 「ICC」：インターリーブサイクルは、現在の着信ADUフレームからカウント - 「iiLastSeen」：最初に、最近見インターリーブ指数（、いくつかの整数*ない*で範囲[0 255]） - 「iccLastSeen」：最近見たインターリーブサイクルカウント範囲[0..7]）で（最初は、いくつかの整数*ない* - 「aduFrameBuffer」：サイズ256のアレイ、ちょうどパケット解除されました（へのポインタ）ADUフレームは（最初は、すべてのエントリはNULLです）
while (1) {
aduFrame = the next ADU frame from the depacketizing step;
(ii,icc) = "the high-order 11 bits of aduFrame's MPEG
header"; "the high-order 11 bits of aduFrame's MPEG
header" = 0xFFE;
// Note: Be sure to leave the remaining 21 bits
// as is
if (icc != iccLastSeen || ii == iiLastSeen) {
// We've started a new interleave cycle
// (or interleaving was not used). Release all
// pending ADU frames to the ADU->MP3 conversion
// step:
for (int i = 0; i < 256; ++i) {
if (aduFrameBuffer[i] != NULL) {
release aduFrameBuffer[i];
aduFrameBuffer[i] = NULL;
}
}
}
iiLastSeen = ii;
iccLastSeen = icc;
aduFrameBuffer[ii] = aduFrame;
}
Appendix C. Changes from
付録C.変更から
The primary change from RFC 3119 is to correct the encoding name in the "SDP usage" section. The correct encoding name is "mpa-robust". Also, the term "media type" replaces "mime type". Finally, some minor bug fixes and clarifications were made to the (non-normative) pseudo code in Appendix A and Appendix B.
RFC 3119からの一次変化「SDP使い方」でエンコーディング名を修正することです。正しいエンコーディング名は、「MPA-堅牢」です。また、用語「メディアタイプは、」「MIMEタイプ」を置き換えます。最後に、いくつかのマイナーなバグ修正と明確化は、付録Aおよび付録Bに（非規範的）擬似コードに行われました
Author's Address
著者のアドレス
Ross Finlayson, Live Networks, Inc. 650 Castro St., suite 120-196 Mountain View, CA 94041 USA
ロス・フィンレイソン、ライブネットワークス株式会社650カストロ聖、スイート120から196マウンテンビュー、CA 94041 USA
EMail: finlayson@live555.com URI: http://www.live555.com/
電子メール：finlayson@live555.com URI：http://www.live555.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。