RFC5215 日本語訳
5215 RTP Payload Format for Vorbis Encoded Audio. L. Barbato. August 2008. (Format: TXT=54327 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Barbato Request for Comments: 5215 Xiph Category: Standards Track August 2008
Barbatoがコメントのために要求するワーキンググループL.をネットワークでつないでください: 5215年のXiphカテゴリ: 標準化過程2008年8月
RTP Payload Format for Vorbis Encoded Audio
Vorbisのための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 payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.
このドキュメントは、オーディオでコード化されたVorbisを輸送するためにRTPペイロード形式について説明します。 それは生のVorbisデータのためのRTPカプセル化メカニズムとデコーダ確率モデル(符号表と呼ばれる)のための排紙機構について詳述します、他のセットアップ情報と同様に。
Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP).
また、このメモの中に含まれているのは、Session記述プロトコル(SDP)とのVorbisの使用に必要なメディアタイプ登録証明書と詳細です。
Barbato Standards Track [Page 1] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conformance and Document Conventions . . . . . . . . . . . 3
2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8
3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10
3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12
3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12
3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14
5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19
7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20
7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20
7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 25
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 順応とドキュメントコンベンション. . . . . . . . . . . 3 2。 有効搭載量形式. . . . . . . . . . . . . . . . . . . . . . . . 3 2.1。 RTPヘッダー. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2。 有効搭載量ヘッダー. . . . . . . . . . . . . . . . . . . . . . 5 2.3。 有効搭載量データ. . . . . . . . . . . . . . . . . . . . . . . 6 2.4。 例のRTPパケット. . . . . . . . . . . . . . . . . . . . 8 3。 構成ヘッダー. . . . . . . . . . . . . . . . . . . . 8 3.1。 バンドにおけるヘッダートランスミッション. . . . . . . . . . . . . . . 9 3.1.1。 詰まっている構成. . . . . . . . . . . . . . . . . 10 3.2。 バンドトランスミッション. . . . . . . . . . . . . . . . . 12 3.2.1から。 詰まっているヘッダー. . . . . . . . . . . . . . . . . . . . 12 3.3。 構成ヘッダー. . . . . . . . . . . . . . 13 4の損失。 ヘッダー. . . . . . . . . . . . . . . . . . . . . . . 13 5について論評してください。 Packetization. . . . . . . . . . . . . . . . . . . . . 14 5.1を縁どってください。 例はVorbisパケット. . . . . . . . . . . . . 15 5.2を断片化しました。 パケット損失. . . . . . . . . . . . . . . . . . . . . . . 17 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 18 6.1。 .197にヘッダーIANA問題を梱包しました。 SDPは問題. . . . . . . . . . . . . . . . . . 20 7.1を関係づけました。 マッピングメディアはSDP. . . . . . . . . . 20 7.1.1にパラメタをタイプします。 SDPの例. . . . . . . . . . . . . . . . . . . . . 21 7.2。 SDP申し出/答えモデル. . . . . . . . . . 22 8がある用法。 輻輳制御. . . . . . . . . . . . . . . . . . . . . . 22 9。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1。 ラジオ. . . . . . . . . . . . . . . . . . . . . . . 22 10を流してください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 11。 状態. . . . . . . . . . . . . . . . . . . . . . 23 12をコピーします。 承認. . . . . . . . . . . . . . . . . . . . . . . 23 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 24 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 25
Barbato Standards Track [Page 2] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[2ページ]。
1. Introduction
1. 序論
Vorbis is a general purpose perceptual audio codec intended to allow maximum encoder flexibility, thus allowing it to scale competitively over an exceptionally wide range of bit rates. At the high quality/ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is in the same league as MPEG-4 AAC. Vorbis is also intended for lower and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
Vorbisは最大のエンコーダの自在性を許容することを意図する、汎用の知覚のオーディオコーデックです、その結果、それが例外的に広範囲のビット伝送速度にわたって競争的に比例するのを許容します。 スケール(16/24ビットCDかDATレートステレオの)の高い品質/bitrateエンドに、MPEG-4AACと同じリーグにはそれがあります。 また、Vorbisは低くて、より高い見本郵送料率(8kHzの電話から192kHzのデジタル・マスターまでの)とさまざまなチャンネル表現(モノラルの、そして、ポリフォニーの、そして、ステレオの、そして、4チャンネルの5.1、ambisonic、または最大255個の離散的なチャンネル)のために意図します。
Vorbis encoded audio is generally encapsulated within an Ogg format bitstream [RFC3533], which provides framing and synchronization. For the purposes of RTP transport, this layer is unnecessary, and so raw Vorbis packets are used in the payload.
一般に、オーディオでコード化されたVorbisはオッグ形式bitstream[RFC3533]の中で要約されます。bitstreamは縁どりと同期を提供します。 RTP輸送の目的のために、この層が不要であって、非常に生であるので、Vorbisパケットはペイロードで使用されます。
1.1. Conformance and Document Conventions
1.1. 順応とドキュメントコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119] and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが本書ではこと解釈されるのは中でBCP14について説明しました、[RFC2119]であり、対応する実現のために要件レベルを示すべきであるかをさせましょう。 別の方法で述べられない場合、要件はすべての実現に適用されます。
An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered individually for each type.
実現は本書では定義されたメディアタイプのひとりを支持するソフトウェア・モジュールです。 ソフトウェア・モジュールはマルチメディアタイプを支持するかもしれませんが、順応は各タイプのために個別に考えられます。
Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant".
1つ以上の“MUST"要件を満たさない実現は不従順であると考えられます。 すべての“MUST"要件を満たしますが、1つ以上の“SHOULD"要件は満たさない実現が「条件付きに言いなりになる」と言われています。 他のすべての実現が「無条件に言いなりになっています」。
2. Payload Format
2. 有効搭載量形式
For RTP-based transport of Vorbis-encoded audio, the standard RTP header is followed by a 4-octet payload header, and then the payload data. The payload headers are used to associate the Vorbis data with its associated decoding codebooks as well as indicate if the following packet contains fragmented Vorbis data and/or the number of whole Vorbis data frames. The payload data contains the raw Vorbis bitstream information. There are 3 types of Vorbis data; an RTP payload MUST contain just one of them at a time.
Vorbisによってコード化されたオーディオのRTPベースの輸送において、4八重奏のペイロードヘッダー、および次に、ペイロードデータは標準のRTPヘッダーを支えています。 ペイロードヘッダーは、関連解読符号表にVorbisデータを関連づけて、以下のパケットが全体のVorbisデータフレームの断片化しているVorbisデータ、そして/または、数を含むかどうかを示すのに使用されます。 ペイロードデータは生のVorbis bitstream情報を含んでいます。 3つのタイプに関するVorbisデータがあります。 RTPペイロードは一度に、ちょうどそれらの1つを含まなければなりません。
Barbato Standards Track [Page 3] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[3ページ]。
2.1. RTP Header
2.1. RTPヘッダー
The format of the RTP header is specified in [RFC3550] and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの書式は、[RFC3550]で指定されて、図1に示されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP Header
図1: RTPヘッダー
The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see [RFC3550] and [RFC3551] for details). For Vorbis RTP, the following values are used.
RTPヘッダーは分野(V、P、X、およびCC)の八重奏で専門化しているRTP用途を支持し始めます(詳細に関して[RFC3550]と[RFC3551]を見てください)。 Vorbis RTPに関しては、以下の値は使用されています。
Version (V): 2 bits
バージョン(V): 2ビット
This field identifies the version of RTP. The version used by this specification is two (2).
この分野はRTPのバージョンを特定します。 この仕様で使用されるバージョンは2(2)です。
Padding (P): 1 bit
詰め物(p): 1ビット
Padding MAY be used with this payload format according to Section 5.1 of [RFC3550].
[RFC3550]のセクション5.1によると、詰め物はこのペイロード形式と共に使用されるかもしれません。
Extension (X): 1 bit
拡大(X): 1ビット
The Extension bit is used in accordance with [RFC3550].
[RFC3550]に従って、Extensionビットは使用されます。
CSRC count (CC): 4 bits
CSRCは数えます(CCします): 4ビット
The CSRC count is used in accordance with [RFC3550].
[RFC3550]に従って、CSRCカウントは使用されます。
Marker (M): 1 bit
マーカー(M): 1ビット
Set to zero. Audio silence suppression is not used. This conforms to Section 4.1 of [VORBIS-SPEC-REF].
ゼロにセットしてください。 オーディオ沈黙抑圧は使用されていません。 これは[VORBIS-SPEC-REF]のセクション4.1に従います。
Barbato Standards Track [Page 4] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[4ページ]。
Payload Type (PT): 7 bits
有効搭載量タイプ(太平洋標準時の): 7ビット
An RTP profile for a class of applications is expected to assign a payload type for this format, or a dynamically allocated payload type SHOULD be chosen that designates the payload as Vorbis.
アプリケーションのクラスのためのRTPプロフィールがこの形式のためにペイロードタイプを選任すると予想されるか、またはダイナミックに割り当てられたペイロードはSHOULDをタイプします。選ばれて、それがVorbisとしてペイロードを指定するということになってください。
Sequence number: 16 bits
一連番号: 16ビット
The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore the packet sequence. This field is detailed further in [RFC3550].
それぞれのRTPデータ・パケットあたり1つによる一連番号増分は送られて、受信機によって使用されて、パケット損失を検出して、パケット系列を回復するかもしれません。 この分野はさらに[RFC3550]で詳細です。
Timestamp: 32 bits
タイムスタンプ: 32ビット
A timestamp representing the sampling time of the first sample of the first Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample rate of the encoded audio data and is conveyed out- of-band (e.g., as an SDP parameter).
RTPペイロードの最初のVorbisパケットの最初のサンプルの標本抽出時間を表すタイムスタンプ。 クロック周波数は、コード化されたオーディオデータの見本郵送料率に設定しなければならなくて、バンド(例えば、SDPパラメタとしての)の外に伝えられます。
SSRC/CSRC identifiers:
SSRC/CSRC識別子:
These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in [RFC3550].
これらの2つの分野(それぞれ1つのSSRC分野と最大16のCSRC分野がある32ビット)が[RFC3550]で定義されるようにあります。
2.2. Payload Header
2.2. 有効搭載量ヘッダー
The 4 octets following the RTP Header section are the Payload Header. This header is split into a number of bit fields detailing the format of the following payload data packets.
RTP Header部に続く4つの八重奏が有効搭載量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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | F |VDT|# pkts.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| F|VDT|# pkts| +++++++++++++++++++++++++++++++++
Figure 2: Payload Header
図2: 有効搭載量ヘッダー
Ident: 24 bits
Ident: 24ビット
This 24-bit field is used to associate the Vorbis data to a decoding Configuration. It is stored as a network byte order integer.
この24ビットの分野は、Vorbisデータを解読Configurationに関連づけるのに使用されます。 それはネットワークバイトオーダー整数として格納されます。
Fragment type (F): 2 bits
タイプ(F)を断片化してください: 2ビット
Barbato Standards Track [Page 5] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[5ページ]。
This field is set according to the following list:
以下のリストによると、この分野は設定されます:
0 = Not Fragmented
0 =は断片化しませんでした。
1 = Start Fragment
1個の=スタート断片
2 = Continuation Fragment
2=継続断片
3 = End Fragment
3=終わり断片
Vorbis Data Type (VDT): 2 bits
Vorbisデータ型(VDT): 2ビット
This field specifies the kind of Vorbis data stored in this RTP packet. There are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis packet (e.g., you must not aggregate configuration and comment packets in the same RTP payload).
この分野はこのRTPパケットに格納されたVorbisデータの種類を指定します。 現在、3つの異なったタイプのVorbisペイロードがあります。 各パケットは単独のタイプのVorbisパケットだけを含まなければなりません(例えば、あなたは同じRTPペイロードで構成とコメントパケットに集めてはいけません)。
0 = Raw Vorbis payload
=生のVorbis0ペイロード
1 = Vorbis Packed Configuration payload
1個の=Vorbis Packed Configurationペイロード
2 = Legacy Vorbis Comment payload
2=遺産Vorbis Commentペイロード
3 = Reserved
=が予約した3
The packets with a VDT of value 3 MUST be ignored.
価値3のVDTがあるパケットを無視しなければなりません。
The last 4 bits represent the number of complete packets in this payload. This provides for a maximum number of 15 Vorbis packets in the payload. If the payload contains fragmented data, the number of packets MUST be set to 0.
ベスト4ビットはこのペイロードの完全なパケットの数を表します。 これはペイロードの15のVorbisパケットの最大数に備えます。 ペイロードが断片化しているデータを含んでいるなら、パケットの数を0に設定しなければなりません。
2.3. Payload Data
2.3. 有効搭載量データ
Raw Vorbis packets are currently unbounded in length; application profiles will likely define a practical limit. Typical Vorbis packet sizes range from very small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation [LIBVORBIS] typically produces packets less than ~800 bytes, except for the setup header packets, which are ~4-12 kilobytes. Within an RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept sufficiently small so that after adding the RTP and payload headers, the complete RTP packet is smaller than the path MTU.
生のVorbisパケットは現在、長さで限りないです。 アプリケーションプロフィールはおそらく実用的な限界を定義するでしょう。 典型的なVorbisパケットサイズは非常に小さいこと(2-3バイト)からかなり大きくなる(8-12キロバイト)まで及びます。 通常、参照実現[LIBVORBIS]は~よりパケットを800バイト作り出しません、セットアップヘッダーパケットを除いて。(パケットは4-12キロバイト~です)。 断片化、Vorbisデータ・パケットサイズSHOULDを避けるために、RTP文脈の中では、十分小さく保たれてください。そうすれば、RTPとペイロードヘッダーを加えた後に、完全なRTPパケットは経路MTUより小さいです。
Barbato Standards Track [Page 6] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[6ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| vorbisパケットデータ。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Payload Data Header
図3: 有効搭載量データヘッダー
Each Vorbis payload packet starts with a two octet length header, which is used to represent the size in bytes of the following data payload, and is followed by the raw Vorbis data padded to the nearest byte boundary, as explained by the Vorbis I Specification [VORBIS-SPEC-REF]. The length value is stored as a network byte order integer.
それぞれのVorbisペイロードパケットは2八重奏長さのヘッダーから始めます、Vorbisで、I Specification[VORBIS-SPEC-REF]について説明するので。(ヘッダーを以下のデータペイロードのバイトで表現されるサイズを表すのに使用されて、最も近いバイト境界に水増しされた生のVorbisデータはあとに続きます)。 長さの値はネットワークバイトオーダー整数として格納されます。
For payloads that consist of multiple Vorbis packets, the payload data consists of the packet length followed by the packet data for each of the Vorbis packets in the payload.
複数のVorbisパケットから成るペイロードのために、ペイロードデータはペイロードのそれぞれのVorbisパケットのためのパケットデータがあとに続いたパケット長から成ります。
The Vorbis packet length header is the length of the Vorbis data block only and does not include the length field.
Vorbisパケット長ヘッダーは、Vorbisデータ・ブロックの長さ専用であり、長さの分野を入れません。
The payload packing of the Vorbis data packets MUST follow the guidelines set out in [RFC3551], where the oldest Vorbis packet occurs immediately after the RTP packet header. Subsequent Vorbis packets, if any, MUST follow in temporal order.
Vorbisデータ・パケットのペイロードパッキングは[RFC3551]に設定されるガイドラインに従わなければなりません。そこでは、最も古いVorbisパケットがRTPパケットのヘッダー直後起こります。 もしあればその後のVorbisパケットは時のオーダーで続かなければなりません。
Audio channel mapping is in accordance with the Vorbis I Specification [VORBIS-SPEC-REF].
Vorbis I Specification[VORBIS-SPEC-REF]によると、音声チャンネルマッピングがあります。
Barbato Standards Track [Page 7] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[7ページ]。
2.4. Example RTP Packet
2.4. 例のRTPパケット
Here is an example RTP payload containing two Vorbis packets.
ここに、2つのVorbisパケットを含んでいて、例のRTPペイロードがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0|0| 0 |0| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (in sample rate units) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | next vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 |0|0| 0 |0| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ(見本郵送料率単位の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 連動ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 0 | 0 | 2 pks| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| vorbisデータ。 +++++++++++++++++++++++++++++++++ vorbis、データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| 次のvorbisパケットデータ。 +++++++++++++++++++++++++++++++++ データをvorbisします。 +++++++++++++++++++++++++++++++++ vorbis、データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example Raw Vorbis Packet
図4: 例の生のVorbisパケット
The payload data section of the RTP packet begins with the 24-bit Ident field followed by the one octet bit field header, which has the number of Vorbis frames set to 2. Each of the Vorbis data frames is prefixed by the two octets length field. The Packet Type and Fragment Type are set to 0. The Configuration that will be used to decode the packets is the one indexed by the ident value.
RTPパケットのペイロード資料課は1個の八重奏の噛み付いている分野ヘッダーによって後をつけられた24ビットのIdent野原で始まります。ヘッダーはVorbisフレームの数を2に設定させます。 それぞれのVorbisデータフレームは2八重奏長さの分野によって前に置かれています。 Packet TypeとFragment Typeは0に用意ができています。 パケットを解読するのに使用されるConfigurationはident値によって索引をつけられたものです。
3. Configuration Headers
3. 構成ヘッダー
Unlike other mainstream audio codecs, Vorbis has no statically configured probability model. Instead, it packs all entropy decoding configuration, Vector Quantization and Huffman models into a data block that must be transmitted to the decoder with the compressed data. A decoder also requires information detailing the number of audio channels, bitrates, and similar information to configure itself for a particular compressed data stream. These two blocks of
他の主流のオーディオコーデックと異なって、Vorbisには、静的に構成された確率モデルが全くありません。 代わりに、それは圧縮されたデータでデコーダに伝えなければならないデータ・ブロックに構成、Vector Quantization、およびハフマンモデルを解読するすべてのエントロピーを梱包します。 また、デコーダは、特定の圧縮されたデータ・ストリームのためにそれ自体を構成するためにオーディオチャンネル(bitrates)の数を詳しく述べる情報と同様の情報を必要とします。 これらの2ブロック
Barbato Standards Track [Page 8] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[8ページ]。
information are often referred to collectively as the "codebooks" for a Vorbis stream, and are included as special "header" packets at the start of the compressed data. In addition, the Vorbis I specification [VORBIS-SPEC-REF] requires the presence of a comment header packet that gives simple metadata about the stream, but this information is not required for decoding the frame sequence.
情報は、しばしばVorbisの流れのための「符号表」とまとめて呼ばれて、圧縮されたデータの始めの特別な「ヘッダー」パケットとして含められています。 添加、I仕様が簡単なメタデータを与えるコメントヘッダーパケットの存在を必要とする[VORBIS-SPEC-REF]Vorbisでは、流れ、しかし、この情報は、フレーム系列を解読するのに必要ではありません。
Thus, these two codebook header packets must be received by the decoder before any audio data can be interpreted. These requirements pose problems in RTP, which is often used over unreliable transports.
したがって、どんなオーディオデータも解釈できる前にデコーダはこれらの2つの符号表ヘッダーパケットを受け取らなければなりません。 これらの要件はRTPの問題を引き起こします。(RTPは頼り無い輸送の上でしばしば使用されます)。
Since this information must be transmitted reliably and, as the RTP stream may change certain configuration data mid-session, there are different methods for delivering this configuration data to a client, both in-band and out-of-band, which are detailed below. In order to set up an initial state for the client application, the configuration MUST be conveyed via the signalling channel used to set up the session. One example of such signalling is SDP [RFC4566] with the Offer/Answer Model [RFC3264]. Changes to the configuration MAY be communicated via a re-invite, conveying a new SDP, or sent in-band in the RTP channel. Implementations MUST support an in-band delivery of updated codebooks, and SHOULD support out-of-band codebook update using a new SDP file. The changes may be due to different codebooks as well as different bitrates of the RTP stream.
この情報を確かに伝えなければならないので、RTPの流れが、あるコンフィギュレーション・データ中間のセッションを変えるとき、クライアントと、バンドと両方の、バンドの外にこのコンフィギュレーション・データを送るための異なった方法が以下にあります。(方法は詳細です)。 クライアントアプリケーションのために初期状態を設立するために、セッションをセットアップするのに使用される合図チャンネルで構成を伝えなければなりません。 そのような合図に関する1つの例がOffer/答えModel[RFC3264]とSDP[RFC4566]です。 構成への変化は再招待で伝えられるかもしれません、新しいSDP、または送られたRTPのバンドのチャンネルを伝えて。 実現はバンドにおける、アップデートされた符号表の配送を支持しなければなりません、そして、SHOULDはバンドの外で新しいSDPファイルを使用することで符号表最新版を支持します。 変化はRTPの流れの異なったbitratesと同様に異なった符号表のためであるかもしれません。
For non-chained streams, the recommended Configuration delivery method is inside the Packed Configuration (Section 3.1.1) in the SDP as explained the Mapping Media Type Parameters into SDP (Section 7.1).
非チェーニングされた流れのために、発送方法がSDPにPacked Configuration(セクション3.1.1)の中にあるお勧めのConfigurationはSDP(セクション7.1)にMappingメディアType Parametersについて説明しました。
The 24-bit Ident field is used to map which Configuration will be used to decode a packet. When the Ident field changes, it indicates that a change in the stream has taken place. The client application MUST have in advance the correct configuration. If the client detects a change in the Ident value and does not have this information, it MUST NOT decode the raw associated Vorbis data until it fetches the correct Configuration.
24ビットのIdent分野は使用されて、どのConfigurationを写像するかがパケットを解読するのに使用されるということです。 Ident分野が変化するとき、それは、流れにおける変化が起こったのを示します。 クライアントアプリケーションには、あらかじめ、正しい構成がなければなりません。 クライアントがIdent値における変化を検出して、この情報を持っていないなら、それは正しいConfigurationをとって来るまで生の関連Vorbisデータを解読してはいけません。
3.1. In-band Header Transmission
3.1. バンドにおけるヘッダートランスミッション
The Packed Configuration (Section 3.1.1) Payload is sent in-band with the packet type bits set to match the Vorbis Data Type. Clients MUST be capable of dealing with fragmentation and periodic re-transmission of [RFC4588] the configuration headers. The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies.
Packed Configuration(セクション3.1.1)有効搭載量をビットがVorbis Data Typeを合わせるように設定するパケットによるバンドのタイプに送ります。 クライアントは[RFC4588]構成ヘッダーの断片化と周期的な再トランスミッションに対処できなければなりません。 RTPタイムスタンプ価値はこの構成が適用される最初のデータ・パケットのトランスミッション時間を反映しなければなりません。
Barbato Standards Track [Page 9] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[9ページ]。
3.1.1. Packed Configuration
3.1.1. 詰まっている構成
A Vorbis Packed Configuration is indicated with the Vorbis Data Type field set to 1. Of the three headers defined in the Vorbis I specification [VORBIS-SPEC-REF], the Identification and the Setup MUST be packed as they are, while the Comment header MAY be replaced with a dummy one.
Vorbis Packed ConfigurationはVorbis Data Type分野セットで1まで示されます。 Vorbisで定義された3個のヘッダーでは、I仕様[VORBIS-SPEC-REF]、Identification、およびSetupは彼らのように詰まっているに違いありません、Commentヘッダーをダミーのものに取り替えるかもしれませんが。
The packed configuration stores Xiph codec configurations in a generic way: the first field stores the number of the following packets minus one (count field), the next ones represent the size of the headers (length fields), and the headers immediately follow the list of length fields. The size of the last header is implicit.
詰まっている構成は一般的な方法でXiphコーデック構成を格納します: 最初の分野は1を引いて以下のパケットの数を格納します、そして、(分野を数えてください)次の人はヘッダー(長さの分野)のサイズを表します、そして、ヘッダーはすぐに、長さの分野のリストに従います。 最後のヘッダーのサイズは暗黙です。
The count and the length fields are encoded using the following logic: the data is in network byte order; every byte has the most significant bit used as a flag, and the following 7 bits are used to store the value. The first 7 most significant bits are stored in the first byte. If there are remaining bits, the flag bit is set to 1 and the subsequent 7 bits are stored in the following byte. If there are remaining bits, set the flag to 1 and the same procedure is repeated. The ending byte has the flag bit set to 0. To decode, simply iterate over the bytes until the flag bit is set to 0. For every byte, the data is added to the accumulated value multiplied by 128.
カウントと長さの分野は以下の論理を使用することでコード化されます: ネットワークバイトオーダーにはデータがあります。 旗としてあらゆるバイトで最も重要なビットを使用します、そして、以下の7ビットは、値を格納するのに使用されます。 最初の7つの最上位ビットが最初のバイトで格納されます。 残っているビットがあれば、フラグビットは1に設定されます、そして、その後の7ビットは以下のバイトで格納されます。 設定されて、残っているビットがあれば、1と同じ手順への旗は繰り返されます。 終わりのバイトで、0にフラグビットを設定します。 解読するために、ビットをバイトの上単に旗まで繰り返してください。0に設定されます。 あらゆるバイトにおいて、データは128が掛けられた蓄積された値に加えられます。
The headers are packed in the same order as they are present in Ogg [VORBIS-SPEC-REF]: Identification, Comment, Setup.
彼らがオッグ[VORBIS-SPEC-REF]に存在しているので、ヘッダーは同次で梱包されます: 識別、コメントはセットアップされます。
The 2 byte length tag defines the length of the packed headers as the sum of the Configuration, Comment, and Setup lengths.
2バイトの長さのタグはConfiguration、Comment、およびSetupの長さの合計と詰まっているヘッダーの長さを定義します。
Barbato Standards Track [Page 10] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[10ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | n. of headers | length1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length2 | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment | Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| xxxx| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | xxxxx| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 0 | 1 | 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| n. ヘッダーについて| length1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length2| 識別。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. 識別。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. 識別。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. 識別。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. 識別| コメントしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメントしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメントしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメントしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメント| セットアップしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. セットアップしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. セットアップしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packed Configuration Figure
図5: 詰まっている構成図
The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 because the packet bears the full Packed configuration. The number of the packet is set to 1.
Ident分野はこのConfigurationを記述するのにRaw有効搭載量Packetsによって使用される値で設定されます。 パケットが完全なPacked構成に堪えるので、Fragmentタイプは0に用意ができています。 パケットの数は1に設定されます。
Barbato Standards Track [Page 11] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[11ページ]。
3.2. Out of Band Transmission
3.2. バンドトランスミッションから
The following packet definition MUST be used when Configuration is inside in the SDP.
ConfigurationがSDPに中にあるとき、以下のパケット定義を使用しなければなりません。
3.2.1. Packed Headers
3.2.1. 詰まっているヘッダー
As mentioned above, the RECOMMENDED delivery vector for Vorbis configuration data is via a retrieval method that can be performed using a reliable transport protocol. As the RTP headers are not required for this method of delivery, the structure of the configuration data is slightly different. The packed header starts with a 32-bit (network-byte ordered) count field, which details the number of packed headers that are contained in the bundle. The following shows the Packed header payload for each chained Vorbis stream.
以上のように、Vorbisコンフィギュレーション・データのためのRECOMMENDED配送ベクトルが信頼できるトランスポート・プロトコルを使用することで実行できる検索メソッドであります。 RTPヘッダーは配送のこのメソッドに必要でないように、コンフィギュレーション・データの構造がわずかに異なっています。 詰まっているヘッダーは(ネットワークバイトは注文されました)32ビットのカウント野原から始まります。(それは、バンドルに含まれている詰まっているヘッダーの数を詳しく述べます)。 以下はそれぞれのチェーニングされたVorbisストリームのためにPackedヘッダーペイロードを見せています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packed headers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 詰まっているヘッダーの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 詰まっているヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 詰まっているヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packed Headers Overview
図6: 詰まっているヘッダー概要
Barbato Standards Track [Page 12] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[12ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | length ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | n. of headers | length1 | length2 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | Comment Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 長さ。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. | n. ヘッダーについて| length1| length2。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. | 識別ヘッダー。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ................................................................. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. | ヘッダーについて論評してください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ................................................................. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメントヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダーをセットアップしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ................................................................. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. セットアップヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Packed Headers Detail
図7: 詰まっているヘッダーの詳細
The key difference between the in-band format and this one is that there is no need for the payload header octet. In this figure, the comment has a size bigger than 127 bytes.
バンドにおける形式とこれの主要な違いはペイロードヘッダー八重奏の必要は全くないということです。 この図では、コメントで、サイズは127バイトより大きくなります。
3.3. Loss of Configuration Headers
3.3. 構成ヘッダーの損失
Unlike the loss of raw Vorbis payload data, loss of a configuration header leads to a situation where it will not be possible to successfully decode the stream. Implementations MAY try to recover from an error by requesting again the missing Configuration or, if the delivery method is in-band, by buffering the payloads waiting for the Configuration needed to decode them. The baseline reaction SHOULD either be reset or end the RTP session.
生のVorbisペイロードデータの損失と異なって、構成ヘッダーの損失は首尾よくストリームを解読するのが可能でない状況に通じます。 実装が再びなくなったConfigurationを要求することによって、エラーから回復しようとするかもしれませんか、または発送方法がバンドであるなら、ペイロードをバッファリングすることによって、Configurationを待つのは、それらを解読する必要がありました。 基線反応SHOULDはリセットであるかRTPセッションを終わらせます。
4. Comment Headers
4. コメントヘッダー
Vorbis Data Type flag set to 2 indicates that the packet contains the comment metadata, such as artist name, track title, and so on. These metadata messages are not intended to be fully descriptive but rather to offer basic track/song information. Clients MAY ignore it completely. The details on the format of the comments can be found in the Vorbis I Specification [VORBIS-SPEC-REF].
2に設定されたVorbis Data Type旗は、パケットがコメントメタデータを含むのを示します、芸術家名、道のタイトルなどなどのように。 完全に描写的であることを意図するのではなく、これらのメタデータメッセージは、むしろ基本的な道/歌の情報を提供するために意図します。 クライアントはそれを完全に無視するかもしれません。 Vorbis I Specification[VORBIS-SPEC-REF]でコメントの形式に関する詳細を見つけることができます。
Barbato Standards Track [Page 13] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[13ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 2 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| xxxx| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | xxxxx| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 0 | 2 | 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| コメントしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメントしてください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. コメント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Comment Packet
エイト環: コメントパケット
The 2-byte length field is necessary since this packet could be fragmented.
2バイトの長さの分野が、このパケットを断片化できたので、必要です。
5. Frame Packetization
5. フレームPacketization
Each RTP payload contains either one Vorbis packet fragment or an integer number of complete Vorbis packets (up to a maximum of 15 packets, since the number of packets is defined by a 4-bit value).
それぞれのRTPペイロードは1個のVorbisパケット断片か整数のどちらかの完全なVorbisパケットを含んでいます(パケットの数が最大15のパケット4ビットの値によって定義されるので)。
Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP payload with as many Vorbis packets as will fit, up to a maximum of 15, except when such bundling would exceed an application's desired transmission latency. Path MTU is detailed in [RFC1191] and [RFC1981].
経路MTU SHOULD以下であるどんなVorbisデータ・パケットもRTPペイロードで最大15まで合うのと同じくらい多くのVorbisパケットで添付されて、そのようなバンドリングが超えているだろうというときに時を除いて、アプリケーションの必要なトランスミッション潜在を超えてください。 経路MTUは[RFC1191]と[RFC1981]で詳細です。
A fragmented packet has a zero in the last four bits of the payload header. The first fragment will set the Fragment type to 1. Each fragment after the first will set the Fragment type to 2 in the payload header. The consecutive fragments MUST be sent without any other payload being sent between the first and the last fragment. The RTP payload containing the last fragment of the Vorbis packet will have the Fragment type set to 3. To maintain the correct sequence for fragmented packet reception, the timestamp field of fragmented packets MUST be the same as the first packet sent, with
断片化しているパケットはペイロードヘッダーの最後の4ビットにゼロを持っています。 最初の断片はFragmentタイプを1に設定するでしょう。 1日後の各断片はペイロードヘッダーにFragmentタイプを2に設定するでしょう。 1番目と最後の断片の間に送られるペイロードなしでいかなる他のも連続した断片を送らなければなりません。 FragmentがVorbisパケットの最後の断片を含むのにタイプするRTPペイロードは3にセットしました。 断片化しているパケットレセプションのための正しい系列、最初のパケットと同じくらいが送られたなら断片化しているパケットの分野がそうしなければならないタイムスタンプを維持します。
Barbato Standards Track [Page 14] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[14ページ]。
the sequence number incremented as normal for the subsequent RTP payloads; this will affect the RTCP jitter measurement. The length field shows the fragment length.
その後のRTPペイロードのための標準として増加された一連番号。 これはRTCPジター測定に影響するでしょう。 長さの分野は断片の長さを示しています。
5.1. Example Fragmented Vorbis Packet
5.1. 例の断片化しているVorbisパケット
Here is an example of a fragmented Vorbis packet split over three RTP payloads. Each of them contains the standard RTP headers as well as the 4-octet Vorbis headers.
ここに、3個のRTPペイロードの上分けられた断片化しているVorbisパケットに関する例があります。 それぞれのそれらは4八重奏のVorbisヘッダーと同様に標準のRTPヘッダーを含んでいます。
Packet 1:
パケット1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 1 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| 1000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 1 | 0 | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| vorbisデータ。 +++++++++++++++++++++++++++++++++ vorbis、データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example Fragmented Packet (Packet 1)
図9: 例の断片化しているパケット(パケット1)
In this payload, the initial sequence number is 1000 and the timestamp is 12345. The Fragment type is set to 1, the number of packets field is set to 0, and as the payload is raw Vorbis data, the VDT field is set to 0.
このペイロードでは、初期シーケンス番号は1000です、そして、タイムスタンプは12345です。 Fragmentタイプは1に用意ができています、そして、パケット分野の数は0に設定されます、そして、ペイロードが生のVorbisデータであるので、VDT分野は0に設定されます。
Barbato Standards Track [Page 15] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[15ページ]。
Packet 2:
パケット2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 2 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| 1001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 2 | 0 | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| vorbisデータ。 +++++++++++++++++++++++++++++++++ vorbis、データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example Fragmented Packet (Packet 2)
図10: 例の断片化しているパケット(パケット2)
The Fragment type field is set to 2, and the number of packets field is set to 0. For large Vorbis fragments, there can be several of these types of payloads. The maximum packet size SHOULD be no greater than the path MTU, including all RTP and payload headers. The sequence number has been incremented by one, but the timestamp field remains the same as the initial payload.
Fragmentタイプ分野は2に設定されます、そして、パケット分野の数は0に設定されます。 大きいVorbis断片のために、これらのタイプのペイロードの数個があることができます。 最大のパケットサイズSHOULDは、よりそう以下です。すべてのRTPとペイロードヘッダーを含む経路MTU。 一連番号は1つ増加されましたが、タイムスタンプ分野は初期のペイロードと同じままで残っています。
Barbato Standards Track [Page 16] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[16ページ]。
Packet 3:
パケット3:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 3 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| 1002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ident| 3 | 0 | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| vorbisデータ。 +++++++++++++++++++++++++++++++++ vorbis、データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example Fragmented Packet (Packet 3)
図11: 例の断片化しているパケット(パケット3)
This is the last Vorbis fragment payload. The Fragment type is set to 3 and the packet count remains set to 0. As in the previous payloads, the timestamp remains set to the first payload timestamp in the sequence and the sequence number has been incremented.
これは最後のVorbis断片ペイロードです。 Fragmentタイプは3に用意ができています、そして、パケットカウントは0に設定されたままで残っています。 前のペイロードのように、残りが系列と一連番号における最初のペイロードタイムスタンプに設定するタイムスタンプは増加されました。
5.2. Packet Loss
5.2. パケット損失
As there is no error correction within the Vorbis stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Vorbis packets as the client will have to cope with the handling of the Fragment Type. In case of loss of fragments, the client MUST discard all the remaining Vorbis fragments and decode the incomplete packet. If we use the fragmented Vorbis packet example above and the first RTP payload is lost, the client MUST detect that the next RTP payload has the packet count field set to 0 and the Fragment type 2 and MUST drop it. The next RTP payload, which is the final fragmented packet, MUST be dropped in the same manner. If the missing RTP payload is the last, the two fragments received will be kept and the incomplete Vorbis packet decoded.
Vorbisストリームの中にエラー修正が全くないとき、パケット損失は信号の損失をもたらすでしょう。 クライアントがFragment Typeの取り扱いを切り抜けなければならないので、パケット損失は断片化しているVorbisパケットのための問題の以上です。 断片の損失の場合には、クライアントは、すべての残っているVorbis断片を捨てて、不完全なパケットを解読しなければなりません。 私たちが上記のパケットの例となくされた最初のRTPペイロード、クライアントが検出しなければならない断片化しているVorbisを使用するなら、次のRTPペイロードでパケットカウント分野を0とFragmentに設定するのは、2をタイプして、それを下げなければなりません。 同じ方法で次のRTPペイロード(最終的な断片化しているパケットである)を下げなければなりません。 なくなったRTPペイロードが最終、受け取られた2個の断片が保たれるということであるか、そして、不完全なVorbisパケットは解読しました。
Loss of any of the Configuration fragment will result in the loss of the full Configuration packet with the result detailed in the Loss of Configuration Headers (Section 3.3) section.
Configuration断片のどれかの損失はConfiguration Headers(セクション3.3)部のLossで詳細な結果で完全なConfigurationパケットの損失をもたらすでしょう。
Barbato Standards Track [Page 17] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[17ページ]。
6. IANA Considerations
6. IANA問題
Type name: audio
型名: オーディオ
Subtype name: vorbis
Subtypeは以下を命名します。 vorbis
Required parameters:
必要なパラメタ:
rate: indicates the RTP timestamp clock rate as described in RTP
Profile for Audio and Video Conferences with Minimal Control
[RFC3551].
以下を評価してください。 AudioとVideoコンファレンスのためにMinimal Control[RFC3551]と共にRTP Profileで説明されるようにRTPタイムスタンプクロックレートを示します。
channels: indicates the number of audio channels as described in
RTP Profile for Audio and Video Conferences with Minimal
Control [RFC3551].
チャンネル: AudioとVideoコンファレンスのためにMinimal Control[RFC3551]と共にRTP Profileで説明されるように音声チャンネルの数を示します。
configuration: the base64 [RFC4648] representation of the Packed
Headers (Section 3.2.1).
構成: Packed Headers(セクション3.2.1)のbase64[RFC4648]表現。
Encoding considerations:
問題をコード化します:
This media type is framed and contains binary data.
このメディアタイプは、縁どられて、バイナリ・データを含んでいます。
Security considerations:
セキュリティ問題:
See Section 10 of RFC 5215.
RFC5215のセクション10を見てください。
Interoperability considerations:
相互運用性問題:
None
なし
Published specification:
広められた仕様:
RFC 5215
RFC5215
Ogg Vorbis I specification: Codec setup and packet decode.
Available from the Xiph website, http://xiph.org/
オッグ・ボルビスI仕様: コーデックセットアップとパケットは解読します。 Xiphウェブサイト、 http://xiph.org/ から、利用可能です。
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
Audio streaming and conferencing tools
オーディオストリーミングと会議ツール
Additional information:
追加情報:
None
なし
Barbato Standards Track [Page 18] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[18ページ]。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Luca Barbato: <lu_zero@gentoo.org>
IETF Audio/Video Transport Working Group
ルカBarbato: <Lu_ゼロ@gentoo.org>IETFオーディオ/ビデオ輸送作業部会
Intended usage:
意図している用法:
COMMON
一般的
Restriction on usage:
用法における制限:
This media type depends on RTP framing, hence is only defined for
transfer via RTP [RFC3550].
このメディアタイプは、RTP縁どりによって、したがって、転送のためにRTP[RFC3550]を通して定義されるだけです。
Author:
以下を書いてください。
Luca Barbato
ルカBarbato
Change controller:
コントローラを変えてください:
IETF AVT Working Group delegated from the IESG
IESGから代表として派遣されたIETF AVT作業部会
6.1. Packed Headers IANA Considerations
6.1. 詰まっているヘッダーIANA問題
The following IANA considerations refers to the split configuration Packed Headers (Section 3.2.1) used within RFC 5215.
以下のIANA問題はRFC5215の中で使用された分裂構成Packed Headers(セクション3.2.1)について言及します。
Type name: audio
型名: オーディオ
Subtype name: vorbis-config
Subtypeは以下を命名します。 vorbis-コンフィグ
Required parameters:
必要なパラメタ:
None
なし
Optional parameters:
任意のパラメタ:
None
なし
Encoding considerations:
問題をコード化します:
This media type contains binary data.
このメディアタイプはバイナリ・データを含んでいます。
Security considerations:
セキュリティ問題:
See Section 10 of RFC 5215.
RFC5215のセクション10を見てください。
Barbato Standards Track [Page 19] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[19ページ]。
Interoperability considerations:
相互運用性問題:
None
なし
Published specification:
広められた仕様:
RFC 5215
RFC5215
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
Vorbis encoded audio, configuration data
Vorbisはオーディオ、コンフィギュレーション・データをコード化しました。
Additional information:
追加情報:
None
なし
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Luca Barbato: <lu_zero@gentoo.org>
IETF Audio/Video Transport Working Group
ルカBarbato: <Lu_ゼロ@gentoo.org>IETFオーディオ/ビデオ輸送作業部会
Intended usage: COMMON
意図している用法: 一般的
Restriction on usage:
用法における制限:
This media type doesn't depend on the transport.
このメディアタイプは輸送を当てにしません。
Author:
以下を書いてください。
Luca Barbato
ルカBarbato
Change controller:
コントローラを変えてください:
IETF AVT Working Group delegated from the IESG
IESGから代表として派遣されたIETF AVT作業部会
7. SDP Related Considerations
7. SDPは問題を関係づけました。
The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the Offer/Answer Model [RFC3264]. In order to be forward compatible, the implementation MUST ignore unknown parameters.
以下のパラグラフはIANA問題部で説明されたパラメタに関するマッピングとOffer/答えModel[RFC3264]のそれらの用法を定義します。 フォワード互換性があるように、実装は未知のパラメタを無視しなければなりません。
7.1. Mapping Media Type Parameters into SDP
7.1. メディア型引数をSDPに写像します。
The information carried in the Media Type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions, the mapping are as follows:
メディアType仕様で運ばれた情報はSession記述プロトコル(SDP)[RFC4566]の分野に特定のマッピングを持っています。(プロトコルは、RTPセッションについて説明するのに一般的に使用されます)。 SDPが指定するのに使用されるとき、セッション、マッピングは以下の通りです:
Barbato Standards Track [Page 20] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[20ページ]。
o The type name ("audio") goes in SDP "m=" as the media name.
o 型名(「オーディオ」)はメディア名としてSDP「m=」に行きます。
o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding
name.
o 「副-タイプ」名("vorbis")はコード化名としてSDP"a=rtpmap"に入ります。
o The parameter "rate" also goes in "a=rtpmap" as the clock rate.
o また、「レート」というパラメタはクロックレートとして"a=rtpmap"に入ります。
o The parameter "channels" also goes in "a=rtpmap" as the channel
count.
o また、「チャンネル」というパラメタはチャンネルカウントとして"a=rtpmap"に入ります。
o The mandated parameters "configuration" MUST be included in the
SDP "a=fmtp" attribute.
o SDP"a=fmtp"属性に「構成」という強制されたパラメタを含まなければなりません。
If the stream comprises chained Vorbis files and all of them are known in advance, the Configuration Packet for each file SHOULD be passed to the client using the configuration attribute.
ストリームがチェーニングされたVorbisを包括するなら、それらのファイルとすべてがあらかじめ知られています、それぞれのファイルSHOULDのためのConfiguration Packet。構成属性を使用することでクライアントに渡されます。
The port value is specified by the server application bound to the address specified in the c= line. The channel count value specified in the rtpmap attribute SHOULD match the current Vorbis stream or should be considered the maximum number of channels to be expected. The timestamp clock rate MUST be a multiple of the sample rate; a different payload number MUST be used if the clock rate changes. The Configuration payload delivers the exact information, thus the SDP information SHOULD be considered a hint. An example is found below.
ポート値はc=系列で指定されたアドレスに縛られたサーバ・アプリケーションで指定されます。 チャンネルカウント価値は、rtpmap属性SHOULDマッチで現在のVorbisストリームを指定するべきであるか、または予想されるためにチャンネルの最大数であると考えられるべきです。 タイムスタンプクロックレートは見本郵送料率の倍数であるに違いありません。 クロックレートが変化するなら、異なったペイロード番号を使用しなければなりません。 Configurationペイロードはその結果、正確な情報、SDP情報にSHOULDを提供します。ヒントであると考えられます。 例は以下で見つけられます。
7.1.1. SDP Example
7.1.1. SDPの例
The following example shows a basic SDP single stream. The first configuration packet is inside the SDP; other configurations could be fetched at any time from the URIs provided. The following base64 [RFC4648] configuration string is folded in this example due to RFC line length limitations.
以下の例は基本的なSDPただ一つのストリームを示しています。 SDPの中に最初の構成パケットがあります。 いつでも、提供されたURIから他の構成をとって来ることができました。 以下のbase64[RFC4648]構成ストリングはRFC行長制限のためこの例で折り重ねられます。
c=IN IP4 192.0.2.1
cがIP4 192.0.2において等しい、.1
m=audio RTP/AVP 98
mはオーディオのRTP/AVP98と等しいです。
a=rtpmap:98 vorbis/44100/2
a=rtpmap: 98vorbis/44100/2
a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;
a=fmtp: 98構成はAAAAAZ2f4g9NAh4aAXZvcmJpcwAと等しいです…;
Note that the payload format (encoding) names are commonly shown in uppercase. Media Type subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in Media Type types and in the default mapping to the SDP a=fmtp attribute. The a=fmtp line is
ペイロード形式(コード化する)名が大文字で一般的に示されることに注意してください。 メディアType血液型亜型では、一般的に小文字で目立ちます。 これらの名前は両方の場所で大文字と小文字を区別しないです。 同様に、パラメタ名はメディアTypeタイプとデフォルトマッピングでSDP a=fmtp属性に大文字と小文字を区別しないです。 a=fmtp系列はそうです。
Barbato Standards Track [Page 21] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[21ページ]。
a single line, even if it is shown as multiple lines in this document for clarity.
単線本書では明快のための同じくらい複数の系列がそれに示されても。
7.2. Usage with the SDP Offer/Answer Model
7.2. SDP申し出/答えモデルがある用法
There are no negotiable parameters. All of them are declarative.
どんな交渉可能なパラメタもありません。 それらは皆、宣言的です。
8. Congestion Control
8. 輻輳制御
The general congestion control considerations for transporting RTP data apply to Vorbis audio over RTP as well. See the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]). Audio data can be encoded using a range of different bit rates, so it is possible to adapt network bandwidth by adjusting the encoder bit rate in real time or by having multiple copies of content encoded at different bit rates.
RTPデータを輸送するための一般的な輻輳制御問題はまた、RTPの上のVorbisオーディオに適用されます。 RTP仕様[RFC3550]とあらゆる適切なRTPプロフィール(例えば、[RFC3551])を見てください。 さまざまな異なったビット伝送速度を使用することでオーディオデータをコード化できるので、リアルタイムで、エンコーダビット伝送速度を調整するか、または異なったビット伝送速度で複本の内容をコード化させることによってネットワーク回線容量を適合させるのは可能です。
9. Example
9. 例
The following example shows a common usage pattern that MAY be applied in such a situation. The main scope of this section is to explain better usage of the transmission vectors.
以下の例はそのような状況で適用されるかもしれない一般的な用法パターンを示しています。 このセクションのメイン範囲で、トランスミッションベクトルの、より良い用法がわかることになっています。
9.1. Stream Radio
9.1. ストリームラジオ
This is one of the most common situations: there is one single server streaming content in multicast, and the clients may start a session at a random time. The content itself could be a mix of a live stream (as the webjockey's voice) and stored streams (as the music she plays).
これは最も一般的な状況の1つです: マルチキャストには1つのただ一つのサーバストリーミングの内容があります、そして、クライアントはセッションの無作為の時に始めるかもしれません。 内容自体は、ライブストリーム(webjockeyの声としての)のミックスであるかもしれなく、ストリームを保存しました(音楽として、彼女はプレーします)。
In this situation, we don't know in advance how many codebooks we will use. The clients can join anytime and users expect to start listening to the content in a short time.
この状況で、私たちは、あらかじめ、いくつの符号表を使用するかを知りません。 クライアントはいつでも加わることができます、そして、ユーザはまもなく内容を聞くのを出発すると予想します。
Upon joining, the client will receive the current Configuration necessary to decode the current stream inside the SDP so that the decoding will start immediately after.
接合のときに、クライアントは直後の解読が始まるようにSDPの中で現在のストリームを解読するのに必要な現在のConfigurationを受け取るでしょう。
When the streamed content changes, the new Configuration is sent in- band before the actual stream, and the Configuration that has to be sent inside the SDP is updated. Since the in-band method is unreliable, an out-of-band fallback is provided.
流された内容が変化するとき、実際のストリームの前に新しいConfigurationをコネバンドに送ります、そして、SDPの中で送られなければならないConfigurationをアップデートします。 バンドにおけるメソッドが頼り無いので、バンドで出ている後退を提供します。
The client may choose to fetch the Configuration from the alternate source as soon as it discovers a Configuration packet got lost in- band, or use selective retransmission [RFC3611] if the server supports this feature.
サーバがこの特徴をサポートするなら、クライアントは、Configurationパケットが中でバンドを失せさせたと発見するとすぐに、代替のソースからConfigurationをとって来るのを選ぶか、または選択している「再-トランスミッション」[RFC3611]を使用するかもしれません。
Barbato Standards Track [Page 22] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[22ページ]。
A server-side optimization would be to keep a hash list of the Configurations per session, which avoids packing all of them and sending the same Configuration with different Ident tags.
サーバサイド最適化は1彼らを皆、梱包して、異なったIdentタグで同じConfigurationを送るのを避けるセッションあたりのConfigurationsのハッシュリストを保つだろうことです。
A client-side optimization would be to keep a tag list of the Configurations per session and not process configuration packets that are already known.
クライアントサイド最適化は既に知られているプロセス構成パケットではなく、1セッションあたりのConfigurationsのタグリストを保つだろうことです。
10. Security Considerations
10. セキュリティ問題
RTP packets using this payload format are subject to the security considerations discussed in the RTP specification [RFC3550], the base64 specification [RFC4648], and the URI Generic syntax specification [RFC3986]. Among other considerations, this implies that the confidentiality of the media stream is achieved by using encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data.
このペイロード形式を使用するRTPパケットはRTP仕様[RFC3550]、base64仕様[RFC4648]、およびURI Generic構文仕様[RFC3986]で議論したセキュリティ問題を受けることがあります。 他の問題の中では、これは、メディアストリームの秘密性が暗号化を使用することによって達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化は圧縮されたデータに実行されるかもしれません。
11. Copying Conditions
11. コピー状態
The authors agree to grant third parties the irrevocable right to copy, use, and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information.
作者は、仕事をコピーして、使用して、広げる呼び戻せない権利を第三者に与えるのに同意します、変更のあるなしにかかわらず、どんな媒体でも、ロイヤリティなしで、別々の許可が与えられない場合、再配付された変更された作品が紛らわしい作者、バージョン、仕事の名前、または裏書き情報を含んでいなければ。
12. Acknowledgments
12. 承認
This document is a continuation of the following documents:
このドキュメントは以下のドキュメントの継続です:
Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 2001.
モフィット、J.、「VorbisのためのRTP有効搭載量形式はオーディオをコード化した」2001年2月。
Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 2004.
カー、R.、「VorbisのためのRTP有効搭載量形式はオーディオをコード化した」2004年12月。
The Media Type declaration is a continuation of the following document:
メディアType宣言は以下のドキュメントの継続です:
Short, B., "The audio/rtp-vorbis MIME Type", January 2008.
急、と、B.、「オーディオ/rtp-vorbis MIMEの種類」2008年1月。
Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and
そしてAVT、スティーブCasner、アーロン・コルウェル、ロスフィンリースン、Fluendo、ラモン・ガルシア、パスカルエンヌカン、ラルフジャイルス、Tor-Einar Jarnbjo、コリンLaw、ジョンLazzaro、ジャック・モフィット、クリストファーモンゴメリ、コリン・パーキンス、バリーShort、マイク・スミス、フィル・カー、マイケル・スパークス、マグヌスWesterlund、デヴィッド・バーレット、シルビア・ファイファー、ステファン・エーマン、ジャンニCeccarelliを含むVorbis Communities / Xiph.Org財団をありがとうございます。
Barbato Standards Track [Page 23] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[23ページ]。
Alessandro Salvatori. Thanks to the LScube Group, in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, and Juan Carlos De Martin.
アレッサンドロ・サルヴァトーリ。 LScube Group、特にフェデリコ・リドルフォ、フランチェスコ・バラノ、Giampaoloマンシーニ、ダリウスGallucci、およびホアン・カルロス・Deマーチンをありがとうございます。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981,
August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for
Audio and Video Conferences with Minimal Control",
STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic
Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566,
July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64
Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and
packet decode. Available from the Xiph website,
http://xiph.org/vorbis/doc/Vorbis_I_spec.html".
[VORBIS-SPEC-REF]、「オッグ・ボルビスI仕様:」 コーデックセットアップとパケットは解読します。 「Xiphウェブサイト、 http://xiph.org/vorbis/doc/Vorbis_I_spec.html から、利用可能です」。
Barbato Standards Track [Page 24] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[24ページ]。
13.2. Informative References
13.2. 有益な参照
[LIBVORBIS] "libvorbis: Available from the dedicated website,
http://vorbis.com/".
[LIBVORBIS]は「以下をlibvorbisします」。 「ひたむきなウェブサイト、 http://vorbis.com/ から、利用可能です」。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format
Version 0", RFC 3533, May 2003.
[RFC3533] ファイファー、S.、「カプセル化がバージョン0インチフォーマットするオッグ、RFC3533、2003年5月。」
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP
Control Protocol Extended Reports (RTCP XR)",
RFC 3611, November 2003.
[RFC3611]フリードマン、T.、カセレス、R.、およびA.クラーク、「RTP制御プロトコルの拡張レポート(RTCP XR)」、RFC3611 2003年11月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format",
RFC 4588, July 2006.
[RFC4588] レイとJ.とレオンとD.と宮崎とA.とVarsa、V.とR.Hakenberg、「RTP Retransmission有効搭載量形式」、RFC4588、2006年7月。
Author's Address
作者のアドレス
Luca Barbato Xiph.Org Foundation
ルカBarbato Xiph.Org財団
EMail: lu_zero@gentoo.org URI: http://xiph.org/
メール: lu_zero@gentoo.org ユリ: http://xiph.org/
Barbato Standards Track [Page 25] RFC 5215 Vorbis RTP Payload Format August 2008
Barbato規格はVorbis RTP有効搭載量形式2008年8月にRFC5215を追跡します[25ページ]。
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に情報を記述してください。
Barbato Standards Track [Page 26]
Barbato標準化過程[26ページ]
一覧
スポンサーリンク
