RFC5219 日本語訳
5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R.Finlayson. February 2008. (Format: TXT=42830 bytes) (Obsoletes RFC3119) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Finlayson Request for Comments: 5219 Live Networks, Inc. Obsoletes: 3119 February 2008 Category: Standard Track
コメントを求めるワーキンググループR.フィンリースン要求をネットワークでつないでください: Inc.が時代遅れにする5219のライブネットワーク: 3119 2008年2月のカテゴリ: 標準の道
A More Loss-Tolerant RTP Payload Format for MP3 Audio
MP3オーディオのための、より損失許容性があるRTP有効搭載量形式
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices.
このドキュメントはMPEG(Picture Experts Groupを動かす)1か2を輸送するためにRTP(リアルタイムのプロトコル)ペイロード形式について説明します、層のIIIオーディオ、(一般的に知っている、「MP3")」 この形式は、RFC2250で説明されたそれへの代替手段であり、パケット損失があれば、よく振る舞います。 「SDP用法」セクションと中間コード付録における誤字を修正して、このドキュメントはRFC3119を時代遅れにします。
Finlayson Standards Track [Page 1] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The Structure of MP3 Frames .....................................3
4. A New Payload Format ............................................4
4.1. ADU Frames .................................................4
4.2. ADU Descriptors ............................................4
4.3. Packing Rules ..............................................5
4.4. RTP Header Fields ..........................................6
4.5. Handling Received Data .....................................6
5. Handling Multiple MPEG Audio Layers .............................6
6. Frame Packetizing and Depacketizing .............................7
7. ADU Frame Interleaving ..........................................8
8. IANA Considerations ............................................10
9. SDP Usage ......................................................11
10. Security Considerations .......................................11
11. Acknowledgements ..............................................11
12. Normative References ..........................................12
Appendix A. Translating between "MP3 Frames" and "ADU Frames" .....13
A.1. Converting a Sequence of "MP3 Frames"
to a Sequence of "ADU Frames" .............................14
A.2. Converting a Sequence of "ADU Frames"
to a Sequence of "MP3 Frames" .............................15
Appendix B. Interleaving and Deinterleaving .......................18
B.1. Interleaving a Sequence of "ADU Frames" ...................18
B.2. Deinterleaving a Sequence of (Interleaved) "ADU Frames" ...19
Appendix C. Changes from RFC 3119 .................................20
1. 序論…2 2. 用語…3 3. MP3フレームの構造…3 4. 新しい有効搭載量形式…4 4.1. ADUフレーム…4 4.2. ADU記述子…4 4.3. パッキングは統治されます…5 4.4. RTPヘッダーフィールド…6 4.5. 取り扱いはデータを受け取りました…6 5. 複数のMPEGオーディオを扱うのは層にされます…6 6. PacketizingとDepacketizingを縁どってください…7 7. ADUはインターリービングを縁どっています…8 8. IANA問題…10 9. SDP用法…11 10. セキュリティ問題…11 11. 承認…11 12. 標準の参照…12 「MP3フレーム」と「ADUフレーム」の間で翻訳される付録A.…13 A.1。 「MP3フレーム」の系列を「ADUフレーム」の系列に変換します…14 A.2。 「ADUフレーム」の系列を「MP3フレーム」の系列に変換します…15 付録B.のインターリービングとDeinterleaving…18 B.1。 「ADUフレーム」の系列をはさみ込みます…18 B.2。 (はさみ込まれます)「ADUフレーム」の系列をDeinterleavingします…19 付録C.はRFC3119から変化します…20
1. Introduction
1. 序論
While the RTP payload format defined in RFC 2250 [1] is generally applicable to all forms of MPEG audio or video, it is sub-optimal for MPEG-1 or 2, layer III audio (commonly known as "MP3"). The reason for this is that an MP3 frame is not a true "Application Data Unit" -- it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss.
RFC2250[1]で定義されたRTPペイロード書式は一般にすべての形式のMPEGオーディオかビデオに適切ですが、MPEG-1か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 2] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[2ページ]。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. The Structure of MP3 Frames
3. MP3フレームの構造
In this section we give a brief overview of the structure of an MP3 frame. (For a more detailed description, see the MPEG-1 audio [3] and MPEG-2 audio [4] specifications.)
このセクションでは、私たちはMP3フレームの構造の簡潔な概観を与えます。 (より詳細な記述に関して、MPEG-1オーディオ[3]とMPEG-2オーディオ[4]仕様を見てください。)
Each MPEG audio frame begins with a 4-byte header. Information defined by this header includes:
それぞれのMPEGオーディオフレームは4バイトのヘッダーと共に始まります。 このヘッダーによって定義された情報は:
- Whether the audio is MPEG-1 or MPEG-2.
- Whether the audio is layer I, II, or III. (The remainder of this
document assumes layer III, i.e., "MP3" frames.)
- Whether the audio is mono or stereo.
- Whether or not there is a 2-byte CRC field following the header.
- (indirectly) The size of the frame.
- オーディオは、MPEG-1かそれともMPEG-2ですか? - オーディオは、層I、II、またはIIIですか? (すなわち、このドキュメントの残りが層IIIを帯びる、「MP3"フレーム)。」 - オーディオは、モノタイプかそれともステレオですか? - ヘッダーに続く2バイトのCRC分野があるのであるかどうか - (間接的に) フレームのサイズ。
The following structures appear after the header:
以下の構造はヘッダーの後に現れます:
- (optionally) A 2-byte Cyclic Redundancy Check (CRC) field
- A "side info" structure. This has the following length:
- 32 bytes for MPEG-1 stereo
- 17 bytes for MPEG-1 mono, or for MPEG-2 stereo
- 9 bytes for MPEG-2 mono
- Encoded audio data, plus optional ancillary data (filling out the
rest of the frame)
- (任意に) 2バイトのCyclic Redundancy Check(CRC)分野--「サイドインフォメーション」構造。 これには、以下の長さがあります: - MPEG-1モノタイプ、またはMPEG-2ステレオのためのMPEG-1ステレオのための32バイトから17バイト(MPEG-2モノタイプのための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,
MP3デコーダは独自に各ADUを処理します。 ADUsが長さにおいて一般に異なりますが、彼らの平均した長さがそのように異なる、もちろん
Finlayson Standards Track [Page 3] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[3ページ]。
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フレーム(ヘッダーの長さを引いたCRC、および「サイドインフォメーション」分野)について。 (MPEG文学では、このADUは時々「噛み付いている貯水池」と呼ばれます。)
4. A New Payload Format
4. 新しい有効搭載量形式
As noted in [5], a payload format should be designed so that packet boundaries coincide with "codec frame boundaries" -- i.e., with ADUs. In the RFC 2250 payload format for MPEG audio [1], each RTP packet payload contains MP3 frames. In this new payload format for MP3 audio, however, each RTP packet payload contains "ADU frames", each preceded by an "ADU descriptor".
[5]に述べられるように、ペイロード形式はパケット境界がすなわち、ADUsと共に「コーデックフレーム境界」と一致するように、設計されるべきです。 MPEGオーディオ[1]のためのRFC2250ペイロード形式では、それぞれのRTPパケットペイロードはMP3フレームを含んでいます。 しかしながら、MP3オーディオのためのこの新しいペイロード形式では、それぞれのRTPパケットペイロードは「ADUフレーム」(「ADU記述子」が先行したそれぞれ)を含んでいます。
4.1. ADU Frames
4.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 7
below)
- The optional 2-byte CRC field (the same as the original MP3
frame)
- The "side info" structure (the same as the original MP3 frame)
- The complete sequence of encoded audio data (and any ancillary
data) for the ADU (i.e., running from the start of this MP3
frame's "main_data_begin" back-pointer, up to the start of the
next MP3 frame's back-pointer)
- 4バイトのMPEGヘッダー(以下のセクション7で説明されるように(任意に)最初の11ビットを「インターリービング一連番号」に取り替えるのを除いて、MP3が縁どるオリジナルと同じ)--任意の2バイトのCRC分野(オリジナルのMP3フレームと同じ)--「サイドインフォメーション」構造(オリジナルのMP3フレームと同じ)--ADUのためのコード化されたオーディオデータ(そして、どんな補助データも)の完全な配列(すなわち、このMP3フレームの逆ポインタの、そして、次のMP3の始まりに上がっている「主な_データ_は始まり」フレームのバック・ポインタの始まりから走ります)
Note that there is a one-to-one mapping between MP3 frames and ADU frames. Because MP3 frames are self-describing, with the bitrate (and sampling frequency) encoded within the 4-byte MPEG header, the same is true for ADU frames. Therefore, as with MP3 streams, the bitrate can change within a stream and may be used for congestion control.
MP3フレームとADUフレームの間には、1〜1つのマッピングがあることに注意してください。 bitrate(頻度を抽出して)が4バイトのMPEGヘッダーの中にコード化されている状態でMP3フレームが自己に説明しているので、ADUフレームに、同じくらいは本当です。 したがって、MP3の流れなら、bitrateは流れの中で変化できて、輻輳制御に使用されるかもしれません。
4.2. ADU Descriptors
4.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 an RTP packet.)
それぞれのRTPパケットペイロードの中では、1か2バイトの「ADU記述子」が各「ADUフレーム」に先行します(ADUのサイズを与えて、このパケットのデータが前のパケットのデータの継続であるかどうかを示します)。 (単一の「ADU記述子」+「ADUフレーム」がRTPパケットの中で合うことができないくらい大きいときにだけ、これは起こります。)
Finlayson Standards Track [Page 4] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[4ページ]。
An ADU descriptor consists of the following fields:
ADU記述子は以下の分野から成ります:
- "C": Continuation flag (1 bit): 1, if the data following the ADU
descriptor is a continuation of an ADU frame that was too
large to fit within a single RTP packet; 0 otherwise.
- 「C」: 継続旗(1ビット): 1 ADU記述子に従うデータがADUフレームの継続であるなら、それは単一のRTPパケットの中で合うことができないくらい大きかったです。 0 そうでなければ。
- "T": Descriptor Type flag (1 bit):
0 if this is a 1-byte ADU descriptor;
1 if this is a 2-byte ADU descriptor.
- 「T」: 記述子Typeは(1ビット)に旗を揚げさせます: 0 これが1バイトのADU記述子であるなら。 1 これが2バイトのADU記述子であるなら。
- "ADU size" (6 or 14 bits): The size (in bytes) of the ADU frame
that will follow this ADU descriptor (i.e., NOT including the
size of the descriptor itself). A 2-byte ADU descriptor
(with a 14-bit "ADU size" field) is used for ADU frame sizes
of 64 bytes or more. For smaller ADU frame sizes, senders
MAY alternatively use a 1-byte ADU descriptor (with a 6-bit
"ADU size" field). Receivers MUST be able to accept an ADU
descriptor of either size.
- 「ADUサイズ」(6ビットか14ビット): このADU記述子(すなわち、記述子自体のサイズを含んでいない)に従うADUフレームのサイズ(バイトによる)。 2バイトのADU記述子(14ビットの「ADUサイズ」分野がある)は64バイト以上のADUフレーム・サイズに使用されます。 よりわずかなADUフレーム・サイズのために、あるいはまた、送付者は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ビット)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. Packing Rules
4.3. 規則を梱包します。
Each RTP packet payload begins with an "ADU descriptor", followed by "ADU frame" data. Normally, this "ADU descriptor" + "ADU frame" will fit completely within the RTP packet. In this case, more than one successive "ADU descriptor" + "ADU frame" MAY be packed into a single RTP packet, provided that they all fit completely.
それぞれのRTPパケットペイロードは「ADUフレーム」データがあとに続いた「ADU記述子」で始まります。 通常、この「ADU記述子」+「ADUフレーム」はRTPパケットの完全中で合うでしょう。 この場合、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
しかしながら、単一の「ADU記述子」+「ADUフレーム」がRTPパケットの中で合うことができないくらい大きいなら、「ADUフレーム」は2つ以上の連続したRTPパケットの向こう側に分けられます。 そのような各パケットはADU記述子で始まります。 最初のパケットの記述子には、0の「C」(継続)旗があります。 以下のパケットの記述子には、それぞれ1の「C」旗があります。 各記述子には、この場合、同じ「ADUサイズ」値があります: the
Finlayson Standards Track [Page 5] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[5ページ]。
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フレーム」(単一のRTPパケットの中で合う部分であるだけではない)のサイズ。 そのような各パケット(最後のものさえ)は1「ADU記述子」だけ、を含んでいます。
4.4. RTP Header Fields
4.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 within 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ビットのタイムスタンプです。
4.5. Handling Received Data
4.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フレームの系列を変換することによって失われていないことに注意してください、以下のAppendix A.2で説明されるように。
5. Handling Multiple MPEG Audio Layers
5. 複数の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ペイロード形式がMPEG-1か2、層のIIIオーディオのためだけに意図する、(「MP3")」 対照的に、私と層IIが縁どる層はバック・ポインタなしで以前のフレームに自己充足的です。 しかしながら、オーディオフレームの系列が層のIIIフレーム、および私かIIが縁どる層の混合物から成るのは、可能です(珍しいのですが)。 そのような系列が伝えられるとき、層のIIIフレームだけがADUsに変換されます。 私かIIフレームが'そのままで'(「ADU記述子」のprependingを除いて)送られる層。 同様に、フレームの系列の受信機(このペイロード形式を使用する)は、私とIIフレームへ層を触れない状態で(prepended「ADU記述子」を取り除いた後の)おきますが、「ADUフレーム」から通常のMP3フレームまで層のIIIフレームを変換します。 (各フレームの層が4バイトのMPEGヘッダーから特定されたと思い出してください。)
If you are transmitting a stream consisting *only* of layer I or layer II frames (i.e., without any MP3 data), then there is no benefit to using this payload format, *unless* you are using the interleaving mechanism described in Section 7 below.
次に、このペイロード形式を使用することへの利益が全くありません、あなたであるなら、流れの成ることだけを伝えるのは、私か層IIが縁どる(すなわち、少しもMP3データなしで)層の*であり、**あなたが以下のセクション7で説明されたインターリービングメカニズムを使用していない場合。
Finlayson Standards Track [Page 6] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[6ページ]。
6. Frame Packetizing and Depacketizing
6. フレーム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 is the conversion of a sequence of MP3 frames to a corresponding sequence of ADU frames, and takes place as described in Sections 3 and 4.1 above. (Note also the pseudo-code in Appendix A.1.)
ステップ1は、ADUフレームの対応する系列へのMP3フレームの系列の変換であり、上のセクション3と4.1で説明されるように行われます。 (また、Appendix A.1の中間コードに注意してください。)
Step 2 is the reordering of the sequence of ADU frames in an (optional) interleaving pattern, prior to packetization, as described in section 7 below. (Note also the pseudo-code in Appendix B.1.) Interleaving helps reduce the effect of packet loss by distributing consecutive ADU frames over non-consecutive packets. (Note that because of the back-pointer in MP3 frames, interleaving can be applied -- in general -- only to ADU frames. Thus, interleaving was not possible for RFC 2250.)
ステップ2は(任意)のインターリービングパターンのADUフレームの系列に関する再命令です、packetizationの前で、下のセクション7で説明されるように。 (また、Appendix B.1の中間コードに注意してください。) インターリービングは、非連続したパケットの上に連続したADUフレームを分配することによってパケット損失の影響を減少させるのを助けます。 (MP3フレームのバック・ポインタのために、一般に、ADUフレームだけにインターリービングを適用できることに注意してください。 したがって、RFC2250には、インターリービングは可能ではありませんでした。)
Step 3 is the packetizing of a sequence of (interleaved) ADU frames into RTP packets -- as described in section 4.3 above. Each packet's RTP timestamp is the presentation time of the first ADU that is packed within it. Note that if interleaving was done in step 2, the RTP timestamps on outgoing packets will not necessarily be monotonically nondecreasing.
ステップ3は上のセクション4.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」(継続)旗を使用します。
Finlayson Standards Track [Page 7] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[7ページ]。
Step 6 is the rearranging of the sequence of ADU frames back to its original order (except for ADU frames missing due to packet loss), as described in Section 7 below. (Note also the pseudo-code in Appendix B.2.)
ステップ6は最初の注文(パケット損失のためになくなったADUフレームを除いた)へのADUフレームの系列の転位です、以下のセクション7で説明されるように。 (また、Appendix 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の逆。 (また、Appendix A.2の中間コードに注意してください。) 適切に変更されたMP3デコーダで、実現はこのステップを省略するかもしれません。 代わりに、それは直接(変更される)のMP3デコーダにADUフレームを提供するかもしれません。
7. ADU Frame Interleaving
7. 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オーディオフレーム、(MPEG-1か2;、すべての層)、いつも4バイトのMPEGヘッダー('syncword')の高位11ビットはオール1つ(すなわち、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
- =ビット0-7: 8ビットのInterleave Index(Cycleの中の)--b=ビット8-10: 3ビットのインタリーブサイクルカウント
That is, the 4-byte MPEG header is reused as follows:
すなわち、4バイトのMPEGヘッダーは以下の通り再利用されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Interleave Idx |CycCt| The rest of the original MPEG header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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):
例: 次のインタリーブサイクル(サイズ8の)に、考えてください:
1,3,5,7,0,2,4,6
1,3,5,7,0,2,4,6
(This particular pattern has the property that any loss of up to four consecutive ADUs in the interleaved stream will lead to a deinterleaved stream with no gaps greater than one.) This produces the following sequence of ISNs:
(この特定のパターンには、はさみ込まれた流れにおける、最大4連続したADUsのどんな損失もギャップ1以上なしで「反-はさみ込」まれた流れに導く特性があります。) これは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)など
Finlayson Standards Track [Page 8] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[8ページ]。
So, in this example, a sequence of ADU frames
この例、ADUフレームの系列のそう
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 (etc.)
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9(など)
would get reordered, in step 2, into:
ステップ2で以下に再命令させるでしょう。
(1,0)f1 (3,0)f3 (5,0)f5 (7,0)f7 (0,0)f0 (2,0)f2 (4,0)f4 (6,0)f6 (1,1)f9 (3,1)f11 (5,1)f13 (etc.)
(1、0)f1(3、0)f3(5、0)f5(7、0)f7(0、0)f0(2、0)f2(4、0)f4(6、0)f6(1、1)f9(3、1)f11(5、1)f13(など)
and the reverse reordering (along with replacement of the 0xFFE) would occur upon reception.
そして、逆の再命令(0xFFEの交換に伴う)はレセプションに起こるでしょう。
The reason for breaking the ISN into "Interleave Cycle Count" and "Interleave Index" (rather than just treating it as a single 11-bit counter) is to give receivers a way of knowing when an ADU frame should be 'released' to the ADU->MP3 conversion process (step 7 above), rather than waiting for more interleaved ADU frames to arrive. For instance, in the example above, when the receiver sees a frame with ISN (<something>,1), it knows that it can release all previously seen frames with ISN (<something>,0), even if some other (<something>,0) frames remain missing due to packet loss. An 8-bit Interleave Index allows interleave cycles of size up to 256.
ISNを「インタリーブサイクルカウント」と「インタリーブインデックス」(ただ単一の11ビットのカウンタとしてそれを扱うよりむしろ)に細かく分ける理由はADUフレームがいつ'リリースされるべきであるか'をさらにはさみ込まれたADUを待つよりむしろMP3変換の過程(上のステップ7)が到着するように縁どるADU->において知る方法を受信機に与えることです。 例えば、受信機がISNと共にフレームを見る上記の例、(<、>について何か、1)、ISNと共にすべての以前に見られたフレームはリリースできるのを知っている、(<、何か、>、0)、ある他の(<、>について何か、0個の)フレームがパケット損失のためになくなったままで残っています。 8ビットのInterleave Indexは最大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 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->に連続して、縁どる同じようにこれを扱うでしょう、再命令しないで。 (また、Appendix B.2の中間コードに注意してください。)
Finlayson Standards Track [Page 9] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[9ページ]。
8. IANA Considerations
8. IANA問題
Media type name: audio
メディア型名: オーディオ
Media subtype: mpa-robust
メディア「副-タイプ」: mpa強健です。
Required parameters: none
必要なパラメタ: なし
Optional parameters: none
任意のパラメタ: なし
Encoding considerations:
This type is defined only for transfer via RTP, as specified in
RFC 5219.
問題をコード化します: このタイプは転送のためだけにRFC5219で指定されるようにRTPを通して定義されます。
Security considerations:
See the "Security Considerations" section of RFC 5219.
セキュリティ問題: RFC5219の「セキュリティ問題」セクションを見てください。
Interoperability considerations:
This encoding is incompatible with both the "audio/mpa" and
"audio/mpeg" media types.
相互運用性問題: このコード化は両方の「オーディオ/mpa」と「オーディオ/mpeg」メディアタイプと非互換です。
Published specification:
The ISO/IEC MPEG-1 [3] and MPEG-2 [4] audio specifications, and
RFC 5219.
広められた仕様: ISO/IEC MPEG-1[3]、MPEG-2つの[4]オーディオ仕様、およびRFC5219。
Applications that use this media type:
Audio streaming tools (transmitting and receiving)
このメディアタイプを使用するアプリケーション: オーディオのストリーミングのツール(伝えるのと受信)
Additional information: none
追加情報: なし
Person & email address to contact for further information:
Ross Finlayson
finlayson@live555.com
詳細のために連絡する人とEメールアドレス: ロスフィンリースン finlayson@live555.com
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
Author: Ross Finlayson
Change controller: IETF AVT Working Group
コントローラを書くか、または変えてください: 以下を書いてください。 ロスフィンリースンChangeコントローラ: IETF AVT作業部会
Finlayson Standards Track [Page 10] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[10ページ]。
9. SDP Usage
9. SDP用法
When conveying information by SDP [7], the encoding name SHALL be "mpa-robust" (the same as the media subtype). An example of the media representation in SDP is:
SDP[7]、存在というコード化名のSHALLで「mpa強健な」状態で(メディア「副-タイプ」と同じ)情報を伝達するとき。 SDPのメディア表現に関する例は以下の通りです。
m=audio 49000 RTP/AVP 121
a=rtpmap:121 mpa-robust/90000
オーディオの49000RTP/AVP121m=a=rtpmap: 121 mpa強健な/90000
Note that the RTP timestamp frequency MUST be 90000.
RTPタイムスタンプ頻度が90000であるに違いないことに注意してください。
10. Security Considerations
10. セキュリティ問題
If a session using this payload format is being encrypted, and interleaving is being used, then the sender SHOULD ensure that any change of encryption key coincides with a start of a new interleave cycle. Apart from this, the security considerations for this payload format are identical to those noted for RFC 2250 [1].
このペイロード形式を使用するセッションがコード化されていて、インターリービングが使用されているなら、送付者SHOULDは、暗号化キーのどんな変化も新しいインタリーブサイクルをぎくっとして一致させるのを確実にします。 これは別として、このペイロード形式のためのセキュリティ問題はRFC2250[1]で有名であるものと同じです。
11. Acknowledgements
11. 承認
The suggestion of adding an interleaving option (using the first bits of the MPEG 'syncword' -- which would otherwise be all-ones -- as an interleaving index) is due to Dave Singer and Stefan Gewinner. In addition, Dave Singer provided valuable feedback that helped clarify
インターリービングオプション(インターリービングインデックスとしてそうでなければ、オールものであるだろうMPEG'syncword'の最初のビットを使用する)を加える提案はデーヴSingerとステファンGewinnerのためです。 さらに、デーヴSingerははっきりさせるのを助けた有益なフィードバックを提供しました。
and improve the description of this payload format. Feedback from Chris Sloan led to the addition of an "ADU descriptor" preceding each ADU frame in the RTP packet.
そして、このペイロード形式の記述を改良してください。 クリス・スローンからのフィードバックは、RTPパケットのそれぞれのADUフレームに先行しながら、「ADU記述子」の添加につながりました。
Finlayson Standards Track [Page 11] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[11ページ]。
12. Normative References
12. 引用規格
[1] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP
Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
1998年1月の[1] ホフマンとD.とフェルナンドとG.とGoyal、V.とM.Civanlar、「MPEG1/MPEG2ビデオのためのRTP有効搭載量形式」RFC2250。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[5] ハンドレー、M.とC.パーキンス、「RTP有効搭載量書式仕様の作家へのガイドライン」BCP36、1999年12月のRFC2736。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[7] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
Finlayson Standards Track [Page 12] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[12ページ]。
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 value (expressed in bytes) of the
backpointer for this frame
- "aduDataSize": the size (in bytes) of the ADU associated with
this frame. (If the frame is already an "ADU Frame", then
aduDataSize == frameDataSize)
- "mp3FrameSize": the total size (in bytes) that this frame would
have if it were a regular "MP3 Frame". (If it is already a
"MP3 Frame", then mp3FrameSize == headerSize + sideInfoSize +
frameDataSize) Note that this size can be derived completely
from "header".
- 「セグメント」: 「MP3フレーム」か「ADUフレーム」のどちらかを表す記録。 それは以下の分野から成ります: - 「ヘッダー」: 4バイトのMPEGヘッダー--"headerSize": (== 4)--一定の"sideInfo": 'サイドインフォメーション'構造、プレゼント--"sideInfoSize"であるなら任意の2バイトのCRCがさばく*を含む*: 構造--上の"frameData"のサイズ(バイトによる): このフレーム--"frameDataSize"の残っているデータ: データ--上の"backpointer"のサイズ(バイトによる): このフレーム--"aduDataSize"のためのbackpointerの値(バイトで、言い表されます): このフレームに関連しているADUのサイズ(バイトによる)。 (フレームが既に「ADUフレーム」、当時のaduDataSize=frameDataSizeであるなら) - "mp3FrameSize": このフレームにはそれが通常の「MP3フレーム」であるならある総サイズ(バイトによる)。 (それが既に「MP3フレーム」、当時のmp3FrameSize=headerSize+sideInfoSize+frameDataSizeであるなら) 「ヘッダー」からこのサイズを完全に得ることができることに注意してください。
- "SegmentQueue": A FIFO queue of "Segments", with operations
- void enqueue(Segment)
- Segment dequeue()
- Boolean isEmpty()
- Segment head()
- Segment tail()
- Segment previous(Segment): returns the segment prior to a
given one
- Segment next(Segment): returns the segment after a given one
- unsigned totalDataSize(): returns the sum of the
"frameDataSize" fields of each entry in the queue
- "SegmentQueue": 操作による「セグメント」の先入れ先出し待ち行列--空のエンキュー(セグメント)--セグメントは、()--ブールisEmpty()--セグメントヘッド()--セグメントテール()--セグメントが前の(セグメント)であるとデキューします: 1--次に(区分する)以下を区分するのを考えて、aの前にセグメントを返します。 リターン、与えられたものの後のセグメント--無記名のtotalDataSize(): 待ち行列における、それぞれのエントリーの"frameDataSize"分野の合計を返します。
Finlayson Standards Track [Page 13] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[13ページ]。
A.1. Converting a Sequence of "MP3 Frames" to a Sequence of
"ADU Frames"
A.1。 「MP3フレーム」の系列を「ADUフレーム」の系列に変換します。
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 Frames、私たちが堪能するまで、//へのデータはADUをフレームに発生させます: してください、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.head()!=curFrame)です。
Finlayson Standards Track [Page 14] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[14ページ]。
pendingMP3Frames.dequeue();
}
pendingMP3Frames.dequeue()。 }
// Output, from the remaining frames, the ADU data that
// we want:
int bytesToUse = tailFrame.aduDataSize;
while (bytesToUse > 0) {
int dataHere = curFrame.frameDataSize - offset;
int bytesUsedHere
= dataHere < bytesToUse ? dataHere :
bytesToUse;
残っているフレーム、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"
A.2。 「ADUフレーム」の系列を「MP3フレーム」の系列に変換します。
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を発生させることができるくらいのデータがある前に1新しいADUs//を待ち行列に入れる必要があるか否かに関係なく、//チェックは//ヘッドのために= 本当にADUブールneedToEnqueueを縁どっています。
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
Finlayson Standards Track [Page 15] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[15ページ]。
while (1) {
int endOfData = frameOffset
- curADU.backpointer +
curADU.aduDataSize;
if (endOfData >= endOfHeadFrame) {
// We have enough data to generate a
// frame.
needToEnqueue = False;
break;
}
(1)である、int endOfDataは(endOfData>=endOfHeadFrame)であるならframeOffset(curADU.backpointer+curADU.aduDataSize)と等しいです。等しい私たちが//フレーム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と等しいです。
Finlayson Standards Track [Page 16] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[16ページ]。
}
}
int fromOffset;
if (startOfData <= toOffset) {
fromOffset = toOffset - startOfData;
startOfData = toOffset;
if (endOfData < startOfData) {
endOfData = startOfData;
}
} else {
fromOffset = 0;
int fromOffset。 (startOfData<=toOffset)である、fromOffset=toOffset--startOfData; startOfDataが(endOfData<startOfData)であるならtoOffsetと等しい、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からのオフセット"toOffset"、"bytesUsedHere"バイト[fromOffset]で始まる、」、)、。 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)である間、それの前の1以上//を挿入するために、空になってください、'ダミーである'というADUsを区分しなければならない、(この状況//は例えば、パケット損失のために中間的ADUが取り逃がす//である場合にだけ起こるでしょうに。)テール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
(pendingADUFrames.head()!=tailADU)である、そこの//は前のADU Segment prevADU=pendingADUFrames.previous(tailADU)です; prevADUendはprevADU.mp3FrameSize+prevADU.backpointerと等しいです。
Finlayson Standards Track [Page 17] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[17ページ]。
- prevADU.headerSize
- prevADU.sideInfoSize;
if (prevADU.aduDataSize > prevADUend) {
// this shouldn't happen if the
// previous ADU was well-formed
prevADUend = 0;
} else {
prevADUend -= prevADU.aduDataSize;
}
} else {
prevADUend = 0;
}
- prevADU.headerSize(prevADU.sideInfoSize) (prevADU.aduDataSize>prevADUend)である、これがそうするべきでない//が//前のADUが0よく形成されたprevADUend=歳であったなら起こる、;、ほか、prevADUend -= prevADU.aduDataSize;、ほかprevADUend=0。 }
if (tailADU.backpointer > prevADUend) {
// Insert a 'dummy' ADU in front of the tail.
// This ADU can have the same "header" (and thus,
// "mp3FrameSize") as the tail ADU, but should
// have a "backpointer" of "prevADUend", and
// an "aduDataSize" of zero. The simplest
// way to do this is to copy the "sideInfo" from
// the tail ADU, replace the value of
// "main_data_begin" with "prevADUend", and set
// all of the "part2_3_length" fields to zero.
} else {
break; // no more dummy ADUs need to be
// inserted
}
}
}
(tailADU.backpointer>prevADUend)です。{ テールの//差し込み'ダミー'ADU。 //、//には、このADUはテールADUと同じ「ヘッダー」(そして、その結果、//"mp3FrameSize")を持つことができますが、//には、"prevADUend"のa"backpointer"があるべきであり、ゼロの"aduDataSize"があるべきです。 これをする最も簡単な//方法が//からの"sideInfo"テールADUをコピーすることであり、「主な_データ_を始まる」//の値を「part2_の3_長さ」のすべてがゼロとしてさばく"prevADUend"、およびセット//に取り替えてください。 } ほか、壊れてください; より//ダミーの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"
B.1。 「ADUフレーム」の系列をはさみ込みます。
We first define the following abstract data structures:
私たちは最初に、以下の抽象的なデータ構造を定義します:
- "interleaveCycleSize": an integer in the range [1..256] --
"interleaveCycle": an array, of size "interleaveCycleSize",
containing some permutation of the integers from the set [0 ..
interleaveCycleSize-1] e.g., if "interleaveCycleSize" == 8,
"interleaveCycle" might contain: 1,3,5,7,0,2,4,6
- "inverseInterleaveCycle": an array containing the inverse of the
permutation in "interleaveCycle" -- i.e., such that
- "interleaveCycleSize": 範囲[1 .256]の整数--、"interleaveCycle": アレイ、例えば、セット[0interleaveCycleSize-1]からの整数の何らかの順列を含んでいて、サイズ"interleaveCycleSize"に"interleaveCycle"は"interleaveCycleSize"=8であるなら、以下を含むかもしれません。 1 3 5 7 0 2 4 6--"inverseInterleaveCycle": すなわち、"interleaveCycle"の順列の逆を含むアレイ
Finlayson Standards Track [Page 18] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[18ページ]。
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
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
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)で(1) {というint positionOfNextFrameはinverseInterleaveCycle[ii]と等しいです; aduFrameBuffer[positionOfNextFrame]は隣のADUフレームと等しいです; 高位11ビットのフレームのこのものを取り替えてくださいMPEGヘッダーをゆったり過ごしてください; //注意: (+ + 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"
B.2。 (はさみ込まれます)「ADUフレーム」の系列をDeinterleavingします。
We first define the following abstract data structures:
私たちは最初に、以下の抽象的なデータ構造を定義します:
- "ii": the Interleave Index from the current incoming ADU frame
- "icc": the Interleave Cycle Count from the current incoming ADU
frame
- "iiLastSeen": the most recently seen Interleave Index (initially,
some integer *not* in the range [0..255])
- "iccLastSeen": the most recently seen Interleave Cycle Count
(initially, some integer *not* in the range [0..7])
- "aduFrameBuffer": an array, of size 256, of (pointers to) ADU
Frames that have just been depacketized (initially, all entries
are NULL)
- 「ii」: 現在の入って来るADUフレームからのInterleave Index--「icc」: 現在の入って来るADUからのInterleave Cycle Countフレーム--"iiLastSeen": 最も最近見られたInterleave Index(*ではなく、初めは、範囲[0 .255]の何らかの整数*)--、"iccLastSeen": 最も最近見られたInterleave Cycle Count(*ではなく、初めは、範囲[0 .7]の何らかの整数*)--、"aduFrameBuffer": サイズ256の勢ぞろい、(ポインタ、)、ちょうど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ビット//を必ず残してください。
Finlayson Standards Track [Page 19] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[19ページ]。
if (icc != iccLastSeen || ii == iiLastSeen) {
// We've started a new interleave cycle
// (or interleaving was not used). Release all
// pending ADU frames to the ADU->MP3 conversion
// step:
for (int i = 0; i < 256; ++i) {
if (aduFrameBuffer[i] != NULL) {
release aduFrameBuffer[i];
aduFrameBuffer[i] = NULL;
}
}
}
(icc!はiccLastSeenと等しいです| | ii=iiLastSeen)なら私たちが持っている//は新しいインタリーブサイクル//を始めました(インターリービングは使用されませんでした)。(aduFrameBuffer[i]!=NULL)がaduFrameBuffer[i]がNULLと等しいというaduFrameBuffer[i]をリリースするなら、MP3変換//が以下を踏むADU->(int i=0; i<256; + + i)にすべての//未定のADUフレームをリリースしてください。
iiLastSeen = ii;
iccLastSeen = icc;
aduFrameBuffer[ii] = aduFrame;
}
iiLastSeenはiiと等しいです。 iccLastSeenはiccと等しいです。 aduFrameBuffer[ii]はaduFrameと等しいです。 }
Appendix C. Changes from RFC 3119
RFC3119からの付録C.変化
The primary change from RFC 3119 is to correct the encoding name in the "SDP usage" section. The correct encoding name is "mpa-robust". Also, the term "media type" replaces "mime type". Finally, some minor bug fixes and clarifications were made to the (non-normative) pseudo code in Appendix A and Appendix B.
RFC3119からの第一の変化は「SDP用法」セクションのコード化名を修正することになっています。 正しいコード化名は「mpa強健です」。 「メディアはタイプすること」が「パントマイムタイプ」を取り替える用語も。 最終的に、いくつかのちょっとしたバグフィクスと明確化をAppendix AとAppendix Bの(非標準)の中間コードにしました。
Finlayson Standards Track [Page 20] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[20ページ]。
Author's Address
作者のアドレス
Ross Finlayson, Live Networks, Inc. 650 Castro St., suite 120-196 Mountain View, CA 94041 USA
ロスフィンリースン、Live Networks Inc.650カストロ通り、スイート120-196マウンテンビュー、カリフォルニア94041米国
EMail: finlayson@live555.com URI: http://www.live555.com/
メール: finlayson@live555.com ユリ: http://www.live555.com/
Finlayson Standards Track [Page 21] RFC 5219 February 2008
フィンリースン規格は2008年2月にRFC5219を追跡します[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Finlayson Standards Track [Page 22]
フィンリースン標準化過程[22ページ]
一覧
スポンサーリンク
