RFC3119 日本語訳
3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R.Finlayson. June 2001. (Format: TXT=37796 bytes) (Obsoleted by RFC5219) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Finlayson Request for Comments: 3119 LIVE.COM Category: Standards Track June 2001
コメントを求めるワーキンググループR.フィンリースン要求をネットワークでつないでください: 3119年のLIVE.COMカテゴリ: 標準化過程2001年6月
A More Loss-Tolerant RTP Payload Format for MP3 Audio
MP3オーディオのための、より損失許容性がある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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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(Picture Experts Groupを動かす)1か2を輸送するためにRTP(リアルタイムのプロトコル)ペイロード形式について説明します、層のIIIオーディオ、(一般的に知っている、「MP3")」 この形式は、RFC2250で説明されたそれへの代替手段であり、パケット損失があれば、よく振る舞います。
1. Introduction
1. 序論
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.
RFC2250[2]で定義されたRTPペイロード書式は一般にすべての形式のMPEGオーディオかビデオに適切ですが、MPEG1か2に、それはサブ最適です、層のIIIオーディオ、(一般的に知っている、「MP3")」 この理由はMP3フレームが本当の「アプリケーションデータユニット」でないということです--以前のフレームにデータにバック・ポインタを含んでいるので、これらの以前のフレームの如何にかかわらずそれを解読できません。 RFC2250がそれを定義するので、パケット境界はフレーム境界と一致して、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ペイロード書式を定義します。 この形式はオリジナルのMPEGフレームのデータを保存する配列換えを使用します、パケット境界が現在本当のMP3「アプリケーションデータユニット」(また、(任意に、)インターリービングパターンで再配列できる)と一致するように。 したがって、この新しい形式はパケット損失に直面してRFC2250よりデータ効率的です。
Finlayson Standards Track [Page 1] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[1ページ]。
2. The Structure of MP3 Frames
2. MP3フレームの構造
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フレームの構造の簡潔な概観を与えます。 (より詳細な記述に関して、MPEG1オーディオ[3]とMPEG2オーディオ[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.
- オーディオは、MPEG1かそれともMPEG2ですか? - オーディオは、層I、II、またはIIIですか? (すなわち、このドキュメントの残りが層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)
- (任意に) 2バイトのCRC分野--「サイドインフォメーション」構造。 これには、以下の長さがあります: - MPEGのために、32バイト、1台のステレオ(MPEG2モノタイプのためのMPEG1モノタイプ、またはMPEG2ステレオのための17バイトから9バイト)がオーディオのデータ、および任意の補助データをコード化しました。(フレームの残りに書き込みます)
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).
- 「主な_データ_は始まります」: これは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を処理します。 一般に、ADUsがしかし、長さ、長さがもちろんそれであるために望んでいる彼らの平均において異なる、MP3フレーム(ヘッダーの長さを引いたCRC、および「サイドインフォメーション」分野)について。 (MPEG文学では、このADUは時々「噛み付いている貯水池」と呼ばれます。)
Finlayson Standards Track [Page 2] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[2ページ]。
3. A New Payload Format
3. 新しい有効搭載量形式
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".
[5]に述べられるように、ペイロード形式はパケット境界がすなわち、ADUsと共に「コーデックフレーム境界」と一致するように、設計されるべきです。 MPEGオーディオ[2]のためのRFC2250ペイロード形式では、それぞれのRTPパケットペイロードはMP3フレームを含んでいます。 しかしながら、MP3オーディオのためのこの新しいペイロード形式では、それぞれのRTPパケットペイロードは「ADUフレーム」(「ADU記述子」が先行したそれぞれ)を含んでいます。
3.1 ADU frames
3.1 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フレームの逆ポインタの、そして、次のMP3の始まりに上がっている「主な_データ_は始まり」フレームのバック・ポインタの始まりから走ります)
3.2 ADU descriptors
3.2 ADU記述子
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パケットペイロードの中では、1か2バイトの「ADU記述子」が各「ADUフレーム」に先行します(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
- 「C」: 継続旗(1ビット): 1 ADU記述子に従うデータがADUフレームの継続であるなら、それは単一のRTPパケットの中で合うことができないくらい大きかったです。 0 そうでなければ。 - 「T」: 記述子Typeは(1ビット)に旗を揚げさせます: 0 これが1バイトのADU記述子であるなら。 1 これが2バイトのADU記述子であるなら。 - 「ADUサイズ」(6ビットか14ビット): このADU記述子(すなわち、記述子自体のサイズを含んでいない)に従うADUフレームのサイズ(バイトによる)。 2バイトのADU記述子(14ビットの「ADUサイズ」分野がある)は64バイト以上のADUフレームサイズに使用されます。 よりわずかなADUフレーム・サイズのために、あるいはまた、送付者はそうするかもしれません。
Finlayson Standards Track [Page 3] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[3ページ]。
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.
1バイトのADU記述子(6ビットの「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 |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |C|0| ADUサイズ| +-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|1| ADUサイズ(14ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3 Packing rules
3.3 規則を梱包すること。
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パケットの完全中で合うでしょう。 この場合、1連続した「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」(継続)旗があります。 以下のパケットの記述子には、それぞれ1の「C」旗があります。 各記述子には、この場合、同じ「ADUサイズ」値があります: 全体の「ADUフレーム」(単一のRTPパケットの中で合う部分であるだけではない)のサイズ。 そのような各パケット(最後のものさえ)は1「ADU記述子」だけ、を含んでいます。
3.4 RTP header fields
3.4 RTPヘッダーフィールド
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].
有効搭載量タイプ: MPEGオーディオ[6]のために定義された(静的)のペイロードタイプ14を使用してはいけません。 代わりに、異なって、ダイナミックなペイロードタイプを使用しなければなりません--すなわち、範囲[96,127]の1。
M bit: This payload format defines no use for this bit. Senders
SHOULD set this bit to zero in each outgoing packet.
Mは噛み付きました: このペイロード形式はこのビットのための無駄を定義します。 送付者SHOULDはそれぞれの出発しているパケットのゼロにこのビットを設定します。
Timestamp: This is a 32-bit 90 kHz timestamp, representing the
presentation time of the first ADU packed within the packet.
タイムスタンプ: パケットの中で梱包された最初のADUのプレゼンテーション時間を表して、これは90kHzの32ビットのタイムスタンプです。
Finlayson Standards Track [Page 4] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[4ページ]。
3.5 Handling received data
3.5 取り扱いはデータを受け取りました。
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実現が直接適切に変更されたMP3デコーダにADUフレームを提供するか、またはMP3フレームの系列にそれらを変換し返すことができるように、情報が全く「ADUフレーム」の対応する系列にMP3フレームの系列を変換することによって失われていないことに注意してください、以下の付録A.2で説明されるように。
4. Handling Multiple MPEG Audio Layers
4. 複数のMPEGオーディオ層を扱います。
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ペイロード形式がMPEG1か2、層のIIIオーディオのためだけに意図する、(「MP3")」 対照的に、私と層IIが縁どる層はバック・ポインタなしで以前のフレームに自己充足的です。 しかしながら、オーディオフレームの系列が層のIIIフレームと私かIIが縁どる層の混合物から成るのは、可能です(珍しいのですが)。 そのような系列が伝えられるとき、層のIIIフレームだけがADUsに変換されます。 私かIIフレームが'そのままで'(「ADU記述子」のprependingを除いて)送られる層。 同様に、フレームの系列の受信機(このペイロード形式を使用する)が触れない状態で層IとIIフレームを出る、(prependedを取り除いた後、「ADU記述子)、転向者が「ADUフレーム」から通常のMP3フレームまでIIIフレームを層にする、」 (各フレームの層が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.
あなたが伝わっているなら、流れは成ります。**私か層IIが縁どる(すなわち、少しもMP3データなしで)層には、**あなたがインターリービングメカニズムを使用していなくて、このペイロード形式を使用することへの利益が全くあるだけではありません。
5. Frame Packetizing and Depacketizing
5. フレームPacketizingとDepacketizing
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
ADUフレーム-2MP3フレーム-1>の>がADUフレーム-3>のRTPパケットをはさみ込みました。
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.)
ステップ1(ADUフレームの対応する系列へのMP3フレームの系列の変換)は上のセクション2と3.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 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
ステップ2は(任意)のインターリービングパターンのADUフレームの系列に関する再命令です、packetizationの前で、下のセクション6で説明されるように。 (また、付録B.1の中間コードに注意してください。) インターリービングは、非連続したパケットの上に連続したADUフレームを分配することによってパケット損失の影響を減少させるのを助けます。 (それに注意してください。
Finlayson Standards Track [Page 5] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[5ページ]。
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.)
MP3フレームのバック・ポインタのために、一般に、ADUフレームだけにインターリービングを適用できます。 その結果、RFC2250には、インターリービングは可能ではありませんでした。)
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で説明されるようにRTPパケットへの(はさみ込まれます)ADUフレームの系列のpacketizingです。 各パケットの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
RTP一連番号-5>によって注文されたRTPパケット-4>のRTPパケットはADUフレーム-7ADUフレーム-6>の>のMP3フレームをはさみ込みました。
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はRTPパケットからのADUフレームのdepacketizingです--すなわち、ステップ3の逆。 この過程の一部として、受信機は、ADUフレームがいつ1つ以上のパケット(そしてこれらのパケットの1つが完全に無くなるならADUが縁どる破棄に)の上で分けられるかに気付くのにADU記述子で「C」(継続)旗を使用します。
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は最初の注文(パケット損失のためになくなったADUフレームを除いた)へのADUフレームの系列の転位です、下のセクション6で説明されるように。 (また、付録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はMP3フレームの対応する系列へのADUフレームの系列の変換です--すなわち、ステップ1の逆。 (また、付録A.2の中間コードに注意してください。) 適切に変更されたMP3デコーダで、実現はこのステップを省略するかもしれません。 代わりに、それは直接(変更される)のMP3デコーダにADUフレームを提供するかもしれません。
6. ADU Frame Interleaving
6. ADUフレームインターリービング
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オーディオフレーム(MPEG1か2; すべての層)では、いつも4バイトのMPEGヘッダー('syncword')の高位11ビットはオール1つ(すなわち、0xFFE)です。 トランスミッションのためにADUフレームの系列を再命令するとき、私たちは「インターリービング一連番号」(ISN)としてこれらの11ビットを再利用します。 (レセプションでは、もう一度それらを0xFFEに取り替えます。)
Finlayson Standards Track [Page 6] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[6ページ]。
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
- =ビット0-7: 8ビットのInterleave Index(Cycleの中の)--b=ビット8-10: 3ビットのインタリーブサイクルカウント
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |インタリーブIdx|CycCt| オリジナルのMPEGヘッダーの残り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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連続したADUsのどんな損失も1つ[7]より大きいギャップなしで「反-はさみ込」まれた流れに導く特性があります。) これはISNsの以下の系列を作成します:
(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ビットのInterleave Indexは最大256のサイズのインタリーブサイクルを許容します。
Finlayson Standards Track [Page 7] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[7ページ]。
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 packetizationの如何にかかわらずインターリービング命令の選択をすることができます。 したがって、簡単な実現は、最初に、ADUがそれに従って、縁どる追加注文(ステップ2)をインターリービング命令に選んで、次に、単にRTPパケット(ステップ3)にそれらに連続して詰め込むかもしれません。 しかしながら、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.)
このペイロード形式のそれぞれの受信実現は、入って来るADUフレーム(ステップ6)を「反-はさみ込」むのにおいてISNを認識して、働くことができなければなりません。 しかしながら、このペイロード形式の送付実現は、すなわち、ステップ2を省略することによってインターリービングを実行しないのを選ぶかもしれません。 この場合、それぞれの4バイトのMPEGヘッダーの高位11ビットは0xFFEに残るでしょう。 実現を受けると、その結果、同じISNs(すべての0xFFE)の系列は見られるでしょう。 彼らはまるでInterleave Cycle CountがそれぞれのADUフレームを交換するかのように単に入来の系列をリリースすることによって、ADUがMP3変換の過程(ステップ7)をADU->に連続して、縁どる同じようにこれを扱うでしょう、再命令しないで。 (また、付録B.2の中間コードに注意してください。)
7. MIME registration
7. MIME登録
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".
問題をコード化します: このタイプは転送のためだけに「RFC3119」の指定されるとしてのRTPを通して定義されます。
Security considerations:
See the "Security Considerations" section of
"RFC 3119".
セキュリティ問題: 「RFC3119」の「セキュリティ問題」セクションを見てください。
Interoperability considerations:
This encoding is incompatible with both the "audio/mpa"
and "audio/mpeg" mime types.
相互運用性問題: このコード化は両方の「オーディオ/mpa」と「オーディオ/mpeg」パントマイムタイプと非互換です。
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]オーディオ仕様、および「RFC3119。」
Finlayson Standards Track [Page 8] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[8ページ]。
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
意図している用法: 一般的
Author/Change controller:
Author: Ross Finlayson
Change controller: IETF AVT Working Group
コントローラを書くか、または変えてください: 以下を書いてください。 ロスフィンリースンChangeコントローラ: IETF AVT作業部会
8. SDP usage
8. SDP用法
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]、存在というコード化名のSHALLによる「mp3"(MIME「副-タイプ」と同じ)」という情報を伝えるとき。 SDPのメディア表現に関する例は以下の通りです。
m=audio 49000 RTP/AVP 121
a=rtpmap:121 mpa-robust/90000
オーディオの49000RTP/AVP121m=a=rtpmap: 121 mpa強健な/90000
9. Security Considerations
9. セキュリティ問題
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].
このペイロード形式を使用するセッションがコード化されていて、インターリービングが使用されているなら、送付者SHOULDは、暗号化キーのどんな変化も新しいインタリーブサイクルをぎくっとして一致させるのを確実にします。 これは別として、このペイロード形式のためのセキュリティ問題はRFC2250[2]で有名であるものと同じです。
10. Acknowledgements
10. 承認
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'syncword'の最初のビットを使用する)を加える提案はデーヴSingerとステファンGewinnerのためです。 さらに、デーヴSingerはこのペイロード形式の記述をはっきりさせて、改良するのを助けた有益なフィードバックを、提供しました。 クリス・スローンからのフィードバックは、RTPパケットのそれぞれのADUフレームに先行しながら、「ADU記述子」の添加につながりました。
Finlayson Standards Track [Page 9] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[9ページ]。
11. References
11. 参照
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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有効搭載量形式」、RFC2250、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メガビット/sのための関連オーディオ--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有効搭載量書式仕様の作家へのガイドライン」、BCP36、RFC2736、1999年12月。
[6] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[6]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、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.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
11. Author's Address
11. 作者のアドレス
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
ロスフィンリースン、ライブネットワークInc.(LIVE.COM)
EMail: finlayson@live.com WWW: http://www.live.com/
メール: finlayson@live.com WWW: http://www.live.com/
Finlayson Standards Track [Page 10] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[10ページ]。
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".
以下の'中間コード'は、このペイロード形式を使用している送付者がどうしたら通常の「MP3フレーム」の系列を「ADUフレーム」に翻訳できるか、そして、受信機がどのように逆の翻訳を実行できるかを説明します: 「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": 'サイドインフォメーション'構造、プレゼント--"sideInfoSize"であるなら任意の2バイトのCRCがさばく*を含む*: 構造--上の"frameData"のサイズ(バイトによる): このフレーム--"frameDataSize"の残っているデータ: データ--上の"backpointer"のサイズ(バイトによる): このフレーム--"aduDataSize"のためのbackpointerのサイズ(バイトによる): このフレームに関連している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の先入れ先出し待ち行列--空のエンキュー(セグメント)--セグメントは、()--ブールisEmpty()--セグメントヘッド()--セグメントテール()--セグメントが前の(セグメント)であるとデキューします: 1--次に(区分する)以下を区分するのを考えて、aの前にセグメントを返します。 リターン、与えられたものの後のセグメント--無記名のtotalDataSize(): 待ち行列における、それぞれのエントリーの"frameDataSize"分野の合計を返します。
Finlayson Standards Track [Page 11] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[11ページ]。
A.1 Converting a sequence of "MP3 Frames" to a sequence of "ADU Frames":
「MP3フレーム」の系列を「ADUフレーム」の系列に変換する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)である間、空になる、aのためのADUが縁どる//: //エンキューの新しいMP3 Frames、私たちには発生できるくらいのデータがあるまでしてください、int totalDataSizeBeforeはpendingMP3Frames.totalDataSize()と等しいです。
Segment newFrame = 'the next MP3 Frame';
pendingMP3Frames.enqueue(newFrame);
セグメントnewFrameは'次のMP3 Frame'と等しいです。 pendingMP3Frames.enqueue(newFrame)。
int totalDataSizeAfter
= pendingMP3Frames.totalDataSize();
} while (totalDataSizeBefore < newFrame.backpointer ||
totalDataSizeAfter < newFrame.aduDataSize);
int totalDataSizeAfterはpendingMP3Frames.totalDataSize()と等しいです。 (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を発生させることができるくらいのデータに現在縁どらせる//(すなわち、待ち行列のテール)。 待ち行列におけるもしあれば以前のフレームは//捨てなければなりません、私たちに//を発生させることができるくらいのデータがないとき。//、(それらのADUs、) セグメントtailFrameはpendingMP3Frames.tail()と等しいです。
// Output the header and side info:
output(tailFrame.header);
output(tailFrame.sideInfo);
//はヘッダーとサイドインフォメーションを出力しました: 出力(tailFrame.header)。 出力(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;
}
}
//は私たちのADUデータの始まりを含むフレームに戻ります: intは=0を相殺しました。 セグメントcurFrameはtailFrameと等しいです。 int prevBytesはtailFrame.backpointerと等しいです。 (prevBytes>0)をゆったり過ごしてください。curFrameはpendingMP3Frames.previous(curFrame)と等しいです; int dataHereが(dataHere<prevBytes)であるならcurFrame.frameDataSizeと等しい、prevBytes -= dataHere;、ほかのオフセット=dataHere--prevBytes; 壊れます。
// Dequeue any frames that we no longer need:
while (pendingMP3Frames.head() != curFrame) {
pendingMP3Frames.dequeue();
}
//は私たちがもう必要としないどんなフレームもデキューします: (pendingMP3Frames.head()!=curFrame)をゆったり過ごしてください。pendingMP3Frames.dequeue()。
Finlayson Standards Track [Page 12] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[12ページ]。
// 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;
残っているフレーム、私たちが欲しいADUデータからの//出力: int bytesToUseはtailFrame.aduDataSizeと等しいです。 (bytesToUse>0)である、int dataHereはcurFrame.frameDataSizeと等しいです--相殺してください; int bytesUsedHereはdataHere<bytesToUse?dataHereと等しいです: bytesToUse
output("bytesUsedHere" bytes from curFrame.frameData,
starting from "offset");
(「オフセット」から始めるcurFrame.frameDataからの"bytesUsedHere"バイト)を出力してください。
bytesToUse -= bytesUsedHere;
offset = 0;
curFrame = pendingMP3Frames.next(curFrame);
}
}
bytesToUse -= bytesUsedHere。 =0を相殺してください。 curFrameはpendingMP3Frames.next(curFrame)と等しいです。 } }
A.2 Converting a sequence of "ADU Frames" to a sequence of "MP3 Frames":
「ADUフレーム」の系列を「MP3フレーム」の系列に変換するA.2:
SegmentQueue pendingADUFrames; // initially empty
while (1) {
while (needToGetAnADU()) {
Segment newADU = 'the next ADU Frame';
pendingADUFrames.enqueue(newADU);
SegmentQueue pendingADUFrames。 //が初めは(1)である間、空になる、(needToGetAnADU())、セグメントnewADUは'次のADU Frame'と等しいです; pendingADUFrames.enqueue(newADU)
insertDummyADUsIfNecessary();
}
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()、私たちがaを発生させることができるくらいのデータにADUヘッドのブールneedToEnqueueのために= 本当に縁どらせる//の前の//チェックの私たちは、1つを待ち行列に入れる必要があるか、そして、より新しいADUs。
if (!pendingADUFrames.isEmpty()) {
Segment curADU = pendingADUFrames.head();
int endOfHeadFrame = curADU.mp3FrameSize
- curADU.headerSize - curADU.sideInfoSize;
int frameOffset = 0;
(pendingADUFrames.isEmpty())、セグメント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.
(1)である、int endOfDataが(endOfData>=endOfHeadFrame)であるならframeOffset(curADU.backpointer+curADU.aduDataSize)と等しい、私たちがa//を発生させることができるくらいのデータに縁どらせる//。
Finlayson Standards Track [Page 13] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[13ページ]。
needToEnqueue = False;
break;
}
needToEnqueueは偽と等しいです。 壊れてください。 }
frameOffset += curADU.mp3FrameSize
- curADU.headerSize
- curADU.sideInfoSize;
if (curADU == pendingADUFrames.tail()) break;
curADU = pendingADUFrames.next(curADU);
}
}
curADU.mp3FrameSize--curADU.headerSize--frameOffset+=curADU.sideInfoSize。 (curADU=pendingADUFrames.tail())は壊れます。 curADUはpendingADUFrames.next(curADU)と等しいです。 } }
return needToEnqueue;
}
needToEnqueueを返してください。 }
void generateFrameFromHeadADU() {
Segment curADU = pendingADUFrames.head();
generateFrameFromHeadADU()を欠如させてください、セグメントcurADUはpendingADUFrames.head()と等しいです。
// Output the header and side info:
output(curADU.header);
output(curADU.sideInfo);
//はヘッダーとサイドインフォメーションを出力しました: 出力(curADU.header)。 出力(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);
//は外でフレームの残りのゼロを合わせることによって、始まります、ADU//データが中に完全にそれをいっぱいにするといけないというわけではないので: int endOfHeadFrameはcurADU.mp3FrameSize--curADU.headerSize--curADU.sideInfoSizeと等しいです。 ("endOfHeadFrame"ゼロバイト)を出力してください。
// Fill in the frame with appropriate ADU data from this and
// subsequent ADUs:
int frameOffset = 0;
int toOffset = 0;
これからの適切なADUデータと//その後の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;
}
壊れてください; より多くの//いいえ、ADUsが必要です。(toOffset<endOfHeadFrame)である、int startOfDataが(startOfData>endOfHeadFrame)であるならframeOffset(curADU.backpointer)と等しい、int endOfDataはstartOfData+curADU.aduDataSizeと等しいです;、(endOfData>endOfHeadFrame)です。endOfData=endOfHeadFrame。
int fromOffset;
if (startOfData <= toOffset) {
fromOffset = toOffset - startOfData;
startOfData = toOffset;
if (endOfData < startOfData) {
int fromOffset。 (startOfData<=toOffset)である、fromOffset=toOffset--startOfData; startOfDataは(endOfData<startOfData)であるならtoOffsetと等しいです。
Finlayson Standards Track [Page 14] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[14ページ]。
endOfData = startOfData;
}
} else {
fromOffset = 0;
endOfDataはstartOfDataと等しいです。 } ほか、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;
int bytesUsedHereはendOfDataと等しいです--startOfData 「出力(オフセットでは、「」 curADU.frameData[fromOffset]からのtoOffset、"bytesUsedHere"バイト」を始めます)。 toOffset+=bytesUsedHere。
frameOffset += curADU.mp3FrameSize
- curADU.headerSize - curADU.sideInfoSize;
curADU = pendingADUFrames.next(curADU);
}
curADU.mp3FrameSize--curADU.headerSize--frameOffset+=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
この状況はそうするべきです。テールセグメント(ADU)は最近、//待ち行列に入れられると思われます。insertDummyADUsIfNecessary()を欠如させてください、それの前のbackpointerが前のADUのデータ//を重ね合わせるなら、私たちは、空の状態で1以上//を挿入する必要があります、'ダミーである'という//ADUs、(//が中間的ADUはなくなっていました--例えば、パケット損失への支払われるべきもの//場合にだけ起こる、)、(1)である、テールADUの始まりに比例してtailADU=pendingADUFrames.tail(); int prevADUend; //を区分してください。
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;
(pendingADUFrames.head()!=tailADU)である、そこの//は前のADU Segment prevADU=pendingADUFrames.previous(tailADU)です; prevADUendが(prevADU.aduDataSize>prevADUend)であるならprevADU.mp3FrameSize+prevADU.backpointer--prevADU.headerSize--curADU.sideInfoSizeと等しい、これがそうするべきでない//が前の//ADUが0よく形成されたprevADUend=歳であったなら起こる、;、ほか、prevADUend -= prevADU.aduDataSize。
Finlayson Standards Track [Page 15] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[15ページ]。
}
} 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"があるべきですか? これをする最も簡単な//方法は、//からの"sideInfo"テールADUをコピーして、//から//「part2_3_の長さ」分野の「主な_データ_は始まっ」てすべてのゼロを合わせることです。 } ほか、壊れてください; より//ダミーのADUsは、挿入される必要があります。 }
Appendix B: Interleaving and Deinterleaving
付録B: インターリービングとDeinterleaving
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).
以下の'中間コード'は、インターリービングに従った「ADUフレーム」の送付者缶の追加注文a系列がどのように(ステップ2)を型に基づいて作るか、そして、受信機がどのように(ステップ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": 範囲[1,256]--"interleaveCycle"の整数: アレイ、例えば、セット[0interleaveCycleSize-1]からの整数の何らかの順列を含んでいて、サイズ"interleaveCycleSize"に"interleaveCycle"は"interleaveCycleSize"=8であるなら、以下を含むかもしれません。 1 3 5 7 0 2 4 6--"inverseInterleaveCycle": すなわち、"interleaveCycle"の順列の逆を含むアレイ、そのようなもの、そのinterleaveCycle、[inverseInterleaveCycle[i]]=i--「ii」: 現在のInterleave Index、(初めは、0)--"icc": 現在のInterleave Cycle Count、(初めは、0)--"aduFrameBuffer": サイズ"interleaveCycleSize"、packetizationを待っているADU Framesのアレイ
while (1) {
int positionOfNextFrame = inverseInterleaveCycle[ii];
aduFrameBuffer[positionOfNextFrame] = the next ADU frame;
replace the high-order 11 bits of this frame's MPEG header
(1) {というint positionOfNextFrameはinverseInterleaveCycle[ii]と等しいです; aduFrameBuffer[positionOfNextFrame]は隣のADUフレームと等しいです; 高位11ビットのフレームのこのものを取り替えてくださいMPEGヘッダーをゆったり過ごしてください。
Finlayson Standards Track [Page 16] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[16ページ]。
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、icc)で。 //注意: (+ + ii=interleaveCycleSize)であるならそのままで残っている21ビットを必ず残してください、私たちがこのサイクルに終わるのですべて//未定の状態で通らせる//が(int i=0; i<interleaveCycleSize; + + i)のためのpacketizingステップに縁どられます。packetizingステップへのパスaduFrameBuffer[i]。
ii = 0;
icc = (icc+1)%8;
}
}
ii=0。 icc=(icc+1)%8。 } }
B.2 Deinterleaving a sequence of (interleaved) "ADU Frames":
(はさみ込まれます)「ADUフレーム」のB.2 Deinterleaving a系列:
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フレームからのInterleave Index--「icc」: 現在の入って来るADUからのInterleave Cycle Countフレーム--"iiLastSeen": 最も最近見られたInterleave Index、(*ではなく、初めは、範囲[0,255])--"iccLastSeen"の何らかの整数*: 最も最近見られたInterleave Cycle Count(*ではなく、初めは、範囲[0、7]の何らかの整数*)--、"aduFrameBuffer": サイズ32の勢ぞろい、(ポインタ、)、ちょうどdepacketizedされたADU Frames(初めは、すべてのエントリーが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
(1)である間の{aduFrameはdepacketizingステップから隣のADUフレームと等しいです; 「高位11ビットのaduFrame MPEG(ii、icc)=ヘッダー」; 「aduFrameのMPEGヘッダーの高位11ビット」は0xFFEと等しいです; //注意: そのままで残っている21ビットを必ず残してください。
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;
}
}
}
(icc!はiccLastSeenと等しいです| | ii=iiLastSeen)なら私たちが持っている//は新しいインタリーブサイクル//を始めました(インターリービングは使用されませんでした)。>MP3変換ステップをADUに縁どってすべての//未定のADUをリリースしてください: aduFrameBuffer[i]をリリースしてください; (int i=0; i<32; + + i)に関するaduFrameBuffer[i]=NULL(aduFrameBuffer[i]!=NULL)であるなら
iiLastSeen = ii;
iiLastSeenはiiと等しいです。
Finlayson Standards Track [Page 17] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[17ページ]。
iccLastSeen = icc;
aduFrameBuffer[ii] = aduFrame;
}
iccLastSeenはiccと等しいです。 aduFrameBuffer[ii]はaduFrameと等しいです。 }
Finlayson Standards Track [Page 18] RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
フィンリースン規格は2001年6月にMP3オーディオのためのRFC3119の損失許容性があるRTP有効搭載量形式を追跡します[18ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Finlayson Standards Track [Page 19]
フィンリースン標準化過程[19ページ]
一覧
スポンサーリンク
