Network Working Group R. Finlayson
Request for Comments: 3119 LIVE.COM
Category: Standards Track June 2001
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes a 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.
この文書では、MPEG（動画像専門家グループ）（一般に「MP3」として知られている）1または2、レイヤーIIIの音声を輸送するためのRTP（リアルタイムプロトコル）ペイロード形式について説明します。このフォーマットは、RFC 2250に記載されているものに代わるものであり、パケット損失がある場合に良好に機能します。
While the RTP payload format defined in RFC 2250 [2] 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.
RFC 2250で定義されたRTPペイロードフォーマットは、[2] MPEGオーディオやビデオの全ての形態に適用可能であるが、MPEG 1または2層（一般に「MP3」として知られている）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より。
In this section we give a brief overview of the structure of a MP3 frame. (For 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.
- オーディオレイヤI、II、又はIIIであるかどうか - オーディオかどうかMPEG 1またはMPEG 2です。 （この文書の残りの部分は、層III、すなわち、「MP3」フレームを想定） - オーディオはモノまたはステレオであるかどうか。 - ヘッダに続く2バイトのCRCフィールドが存在するか否か。 - フレームの（間接的に）サイズ。
The following structures appear after the header:
以下の構造は、ヘッダの後に表示されます。
- (optionally) A 2-byte 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)
- （任意に）A 2バイトのCRCフィールド - "サイド情報" 構造。これは、以下の長さを有している： - MPEG 2モノ9バイト - - MPEG 1つのモノため、またはMPEG 2ステレオのための17バイト - MPEG 1ステレオのための32バイトエンコードされたオーディオデータに加え、オプションの補助データ（フレームの残りの部分を記入）
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 [2], 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オーディオ[2]の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 6 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ヘッダ（以下のセクション6で説明したように最初の11ビットは（任意に）、「インターリービングシーケンス番号」で置き換えられていることを除いて、元のMP3フレームと同じ） - オプション2バイトのCRCフィールド（オリジナルのMP3フレームと同じ） - 「サイド情報」構造（オリジナルMP3フレームと同じ） - （ADUのための符号化された音声データ（および任意の補助データ）の完全な配列は、すなわち、開始から実行していますこのMP3フレームの「main_data_begin」バックポインタ、次の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 a 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. - "T": Descriptor Type flag (1 bit): 0 if this is a 1-byte ADU descriptor; 1 if this is a 2-byte ADU descriptor. - "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 frames 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.
- 「C」：継続フラグ（1ビット）：1 ADU記述子以下のデータを単一のRTPパケット内に収まるように大きすぎたADUフレームの継続である場合、それ以外の場合は0。 - 「T」：記述子タイプフラグ（1ビット）：0これは1バイトのADU記述子である場合、 1これは2バイトのADU記述子である場合。 - 「ADUサイズ」（6または14ビット）：（即ち、ディスクリプタ自体の大きさを含まない）このADU記述子に続くADUフレームのサイズ（バイト単位）。 ADUに使用される（14ビットの「ADUサイズ」フィールドを持つ）2バイトのADU記述子は64バイト以上のサイズをフレーム。小さい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 a "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 in the range [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のフレームが送信されます。同様に、フレームのシーケンスの受信機 - このペイロードフォーマットを使用しては - （プリペンド除去した後、そのまま層I及びIIフレームを残す「ADU記述子）が、からレイヤIIIフレーム変換 『正規MP3フレームにADUフレーム』（思い出しています。各フレームの層は、その4バイトのMPEGヘッダから識別されます。）
If you are transmitting a stream consists *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.
もしストリームを送信している場合のみ*（即ち、任意のMP3データなし）層Iまたは層IIフレームの*から成り、このペイロードフォーマットを使用する利点はありません、*あなたがインターリーブ機構を使用していない場合。
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, the conversion of a sequence of MP3 frames to a corresponding sequence of ADU frames, takes place as described in sections 2 and 3.1 above. (Note also the pseudo-code in appendix A.1.)
セクション2と上記3.1に記載したように、ステップ1、ADUフレームの対応する配列にMP3フレームのシーケンスの変換が行われます。 （付録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 6 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は、以下のセクション6で説明したように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 3.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.
上記セクション3.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 6 below. (Note also the pseudo-code in appendix B.2.)
ステップ6は、以下のセクション6で説明したように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.
すなわち、ステップ1の逆（また付録A.2に擬似コードに注意してください。）適切に修飾MP3デコーダと、インプリメンテーション - ステップ7 ADUの配列の変換は、MP3フレームの対応する配列にフレームでありますこのステップを省略してもよいです。代わりに、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
I.e., 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): 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 [7].) This produces the following sequence of ISNs:
例：（サイズ8）以下のインターリーブサイクルを検討：1,3,5,7,0,2,4,6（この特定のパターンは、インターリーブドストリームで最大4つの連続のADUの損失をもたらす性質を有します。1より大きいないギャップのデインターリーブストリーム〜[7]）これは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. E.g., 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. A 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にも擬似コードに注意してください。）
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype: mpa-robust
MIMEサブタイプ：MPA-堅牢
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: This type is defined only for transfer via RTP as specified in "RFC 3119".
エンコードの考慮事項：「RFC 3119」で指定されている。このタイプは唯一のRTPを介した転送のために定義されています。
Security considerations: See the "Security Considerations" section of "RFC 3119".
セキュリティの考慮事項：「RFC 3119」の「セキュリティの考慮事項」を参照してください。
Interoperability considerations: This encoding is incompatible with both the "audio/mpa" and "audio/mpeg" mime types.
相互運用性に関する注意事項：このエンコーディングは、「オーディオ/ MPA」と「オーディオ/ mpegの」MIMEタイプの両方と互換性がありません。
Published specification: The ISO/IEC MPEG-1 [3] and MPEG-2 [4] audio specifications, and "RFC 3119".
公開された仕様：ISO / IEC MPEG-1 [3]、MPEG-2 [4]オーディオ仕様、及び "RFC 3119"。
Applications which use this media type: Audio streaming tools (transmitting and receiving)
このメディアタイプを使用するアプリケーション：オーディオストリーミングツール（送受信）
Additional information: none
追加情報：なし
Person & email address to contact for further information: Ross Finlayson finlayson@live.com
人とEメールアドレスは、詳細についての問い合わせ先：ロス・フィンレイソンfinlayson@live.com
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Author: Ross Finlayson Change controller: IETF AVT Working Group
著者/変更コントローラ：著者：ロス・フィンレイソンの変更コントローラ：IETF AVT作業部会
When conveying information by SDP [8], the encoding name SHALL be "mp3" (the same as the MIME subtype). An example of the media representation in SDP is:
SDP [8]によって情報を伝達する際に、符号化名は、「mp3」（MIMEサブタイプと同じ）でなければなりません。 SDP内のメディア表現の例です。
m=audio 49000 RTP/AVP 121
a=rtpmap:121 mpa-robust/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 [2].
このペイロード形式を使用して、セッションが暗号化されている、とインターリーブが使用されている場合は、送信者は、暗号化キーの変更は、新しいインターリーブサイクルの開始と一致することを確認してください。これとは別に、このペイロード形式のためのセキュリティ問題は、[2] 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 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.
（ - そうでなければすべてのものであろう - MPEG「同期ワード」の最初のビットを用いてインターリービングインデックスとして）インタリーブオプションを追加する提案がデイブ歌手とステファンGewinnerによるものです。また、デイブ歌手このペイロードフォーマットの説明を明確にし、改善する助け貴重なフィードバックを提供しました。クリス・スローンからのフィードバックは、RTPパケット内の各ADUフレームの前の「ADU記述子」のほかにつながりました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[2]ホフマン、D.、フェルナンド、G.、Goyal氏、V.とM. Civanlar、 "MPEG1 / MPEG2ビデオのためのRTPペイロードフォーマット"、RFC 2250、1998年1月。
[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., "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[5]ハンドリー、M.、 "RTPペイロードフォーマット仕様の作家のためのガイドライン"、BCP 36、RFC 2736、1999年12月。
[6] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[6] Schulzrinneと、H.、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 1890、1996年1月。
[7] Marshall Eubanks, personal communication, December 2000.
[7]マーシャルユーバンクス、私信、2000年12月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
ロス・フィンレイソン、ライブネットワークス株式会社（LIVE.COM）
EMail: finlayson@live.com WWW: http://www.live.com/
電子メール：finlayson@live.com WWW：http://www.live.com/
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 size (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 "Segment"s, 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"： "セグメント" SのFIFOキュー、操作で - 空エンキュー（セグメント） - セグメントデキュー（） - ブールのisEmpty（） - セグメント頭（） - セグメント尾（） - セグメント前回（セグメント）：リターン与えられたものと前のセグメント - セグメント次（セグメント） - ：キュー内の各エントリの「frameDataSize」フィールドの合計を返し符号なしtotalDataSize（）指定されたものの後のセグメントを返します
A.1 Converting a sequence of "MP3 Frames" to a sequence of "ADU Frames":
「ADUフレーム」の配列に「MP3のフレーム」のシーケンスを変換A.1：
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.dequeue(); }
//デキュー任意のフレームを、我々はもはや必要性：中（！pendingMP3Frames.head（）= curFrame）{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":
「MP3のフレーム」の配列に「ADUフレーム」のシーケンスを変換するA.2：
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
- curADU.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; }
}}エルス{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 an "aduDataSize" of zero. The simplest // way to do this is to copy the "sideInfo" from // the tail ADU, and zero out the // "main_data_begin" and all of the // "part2_3_length" fields. } else { break; // no more dummy ADUs need to be inserted } } }
（tailADU.backpointer> prevADUendは）{//尾の前で「ダミー」ADUを挿入した場合。 //このADUはテールADUと同じ「ヘッダ」（したがって、//「mp3FrameSize」）を有することができるが、//はゼロの「aduDataSize」を有するべきです。これを行うための最も簡単な方法は、// //テールADUから「SIDEINFO」をコピーして、//「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":
「ADUフレーム」のシーケンスをインターリーブB.1：
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」：範囲内の整数【1256】 - 「interleaveCycle」：サイズのアレイ、「interleaveCycleSize」、「interleaveCycleSize」場合、例えば[0 .. interleaveCycleSize-1]セットから整数のいくつかの置換を含みます== 8、 "interleaveCycle" が含まれる場合があります：1,3,5,7,0,2,4,6を - "inverseInterleaveCycle"： "interleaveCycle" における置換の逆数を含む配列 - 即ち、その結果interleaveCycle [inverseInterleaveCycleを[I]] == I - "II"：現在のインターリーブインデックス（最初は0） - "ICC"：現在のインターリーブサイクル数（初期値は0） - "aduFrameBuffer"、 "interleaveCycleSize" サイズのアレイのADUパケットを待っているフレーム
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":
（インターリーブ）「ADUフレーム」のシーケンスをデインタリーブB.2：
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 32, 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」：（ポインタの大きさ32の配列、ただパケット解除されています）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 < 32; ++i) {
if (aduFrameBuffer[i] != NULL) {
release aduFrameBuffer[i];
aduFrameBuffer[i] = NULL;
}
}
}
iiLastSeen = ii;
iiLastSeen = II。
iccLastSeen = icc;
aduFrameBuffer[ii] = aduFrame;
}
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。