RFC3190 日本語訳
3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit LinearSampled Audio. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT=34977 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Kobayashi
Request for Comments: 3190 Communication Research Laboratory
Category: Standards Track A. Ogawa
Keio University
S. Casner
Packet Design
C. Bormann
Universitaet Bremen TZI
January 2002
コメントを求めるワーキンググループK.小林の要求をネットワークでつないでください: 3190年のコミュニケーション研究研究所カテゴリ: 標準化過程A.小河慶応義塾大学S.CasnerパケットデザインC.ボルマンUniversitaetブレーメンTZI2002年1月
RTP Payload Format for
12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
12ビットのDATオーディオ、20、および24ビットの直線的な抽出されたオーディオのためのRTP有効搭載量形式
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear).
このドキュメントはレアル-時間Transportプロトコル(RTP)を使用することで12ビットの非線形の、そして、20ビットの直線的で、24ビットの直線的なオーディオデータ・ストリームをカプセルに入れることのpacketization計画を指定します。 また、このドキュメントは、オーディオデータが標本抽出の前にいつ前強調されるかを示すためにSession記述プロトコル(SDP)パラメタの形式を指定します。 パラメタは特定のL16の他のオーディオペイロード形式(16ビット直線的な)と共に使用されるかもしれません。
1. Introduction
1. 序論
This document describes the sampling of audio data in 12-bit nonlinear, 20-bit linear, and 24-bit linear encodings, and specifies the encapsulation of the audio data into the Real-time Transport Protocol (RTP), version 2 [1,2]. DAT (digital audio tape) and DV (digital video) devices [3,4] use these audio encodings in addition to 16-bit linear encoding. The packetization scheme for 16-bit linear audio (L16) is already specified [2,5]. This document specifies the packetization scheme for the other encodings following that for L16; in particular, when used with the RTP profile [2], these payload formats follow the encoding-independent rules for
このドキュメントは、12ビットの非線形の、そして、20ビットの直線的で、24ビットの直線的なencodingsのオーディオデータの標本抽出を説明して、レアル-時間Transportプロトコル(RTP)にオーディオデータのカプセル化を指定します、バージョン2[1、2]。 DAT(デジタルオーディオテープ)とDV(デジタルビデオ)装置[3、4]は16ビットの直線的なコード化に加えてこれらのオーディオのencodingsを使用します。 16ビットの直線的なオーディオ(L16)のpacketization計画は既に指定されます[2、5]。 L16のためにそれに続いて、このドキュメントは他のencodingsのpacketization計画を指定します。 使用されているとき、特に、これらのペイロード形式は、RTPが[2]の輪郭を描くのにコード化して独立している規則に従います。
Kobayashi, et al. Standards Track [Page 1] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[1ページ]。
sample ordering and channel interleaving specified in [2] plus extensions specified here. This document also specifies out-of-band negotiation methods for the extended channel interleaving rules and for use when an analog preemphasis technique is applied to the audio data.
サンプル注文とチャンネルインターリービングは[2]で指定しました、そして、拡大はここで指定しました。 また、アナログのプリエンファシスのテクニックがオーディオデータに適用されるとき、このドキュメントはバンドの外で拡張チャンネルインターリービング規則と使用のための交渉方法を指定します。
1.1 Terminology
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 RFC 2119 [6]
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。[6]
2. The need for RTP encapsulation of 12-, 20- and 24-bit audio
2. 12、20、および24ビットのオーディオのRTPカプセル化の必要性
Many high-quality digital audio and visual systems, such as DAT and DV, adopt sample-based audio encodings. Different audio formats are used in various situations. To transport the audio data using RTP, an encapsulation needs to be defined for each specific format. Only 16-bit linear audio encapsulation (L16) has thus far been defined. Other encoding formats have already appeared, such as the 12-bit nonlinear, 20-bit linear and 24-bit linear encodings used in the DAT and DV video world. This specification defines the RTP payload encapsulation format in order to use the new encodings in the RTP environment.
DATやDVなどの多くの高品質なデジタル音響と映像システムがサンプルベースのオーディオencodingsを採用します。 異なったオーディオ形式は様々な状況において使用されます。 RTPを使用することでオーディオデータを輸送するために、カプセル化は、それぞれの特定の形式のために定義される必要があります。 16ビットの直線的なオーディオカプセル化(L16)だけがこれまでのところ、定義されました。 他のコード化形式は既に現れました、非線形の、そして、20ビットの直線的で24ビットの直線的なencodingsがDATとDVビデオ世界で使用した12ビットなどのように。 この仕様は、RTP環境で新しいencodingsを使用するためにRTPペイロードカプセル化書式を定義します。
3. 12-bit nonlinear audio encapsulation
3. 12ビットの非線形のオーディオカプセル化
IEC 61119 [3] specifies the 12-bit nonlinear audio format in DAT and DV, called LP (Long Play) audio. It would be easy to convert 12-bit nonlinear audio into 16-bit linear form at the RTP sender and transmit it using the L16 audio format already defined. However, this would consume 33% more network bandwidth than necessary. This payload format is specified as a more efficient alternative.
IEC61119[3]はLP(長いPlay)オーディオと呼ばれるDATとDVで12ビットの非線形のオーディオ形式を指定します。 RTP送付者における16ビットの線形形式に12ビットの非線形のオーディオを変換して、それを伝えるのは既に定義されたL16オーディオ形式を使用するのにおいて簡単でしょう。 しかしながら、これは必要とするより33%多くのネットワーク回線容量を消費するでしょう。 このペイロード形式は、より効率的な代替手段として指定されます。
The 12-bit nonlinear encoding is the same as for 16-bit linear audio except for the packing of each sampled data element. Each sample of 12-bit nonlinear audio is derived from a single sample of 16-bit linear audio by a nonlinear compression. Table 1 shows the details of the conversion from 16 to 12 bits. The result is a 12-bit signed value ranging from -2048 to 2047 and it is represented in two's complement notation. The 12-bit samples are packed contiguously into payload octets starting with the most significant bit. When the payload contains an odd number of samples, the four LSBs of the last octet are unused. Parameters other than quantization, e.g., sampling frequency and audio channel assignment, are the same as in the L16 payload format. In particular, samples are packed into the packet in time sequence beginning with the oldest sample.
12ビットの非線形のコード化はそれぞれの抽出されたデータ要素のパッキング以外の16ビットの直線的なオーディオのように同じです。 16ビットの直線的なオーディオのただ一つのサンプルから非線形の圧縮で12ビットの非線形のオーディオの各サンプルを得ます。 テーブル1は変換の詳細を16〜12ビット示しています。 結果は-2048〜2047年まで及ぶ12ビットのサインされた値です、そして、それは2の補数記法で表されます。 12ビットのサンプルは始まる中でビット最も重要であるペイロード八重奏に近接して詰め込みます。 ペイロードがサンプルの奇数を含むとき、最後の八重奏の4LSBsが未使用です。 量子化以外のパラメタ(例えば、サンプリング周波数とオーディオのチャネル割当)は、L16ペイロード形式と同じです。 特に、最も古いサンプルで始まる時間系列でサンプルにパケットに詰め込みます。
Kobayashi, et al. Standards Track [Page 2] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[2ページ]。
------------------------------------------------------------
32,767 (7FFFh) Y = INT(X/64) + (600h) 2,047 (7FFh)
16,384 (4000h) 1,792 (700h)
------------------------------------------------------------
16,383 (3FFFh) Y = INT(X/32) + (500h) 1,791 (6FFh)
8,192 (2000h) 1,536 (600h)
------------------------------------------------------------
8,191 (1FFFh) Y = INT(X/16) + (400h) 1,535 (5FFh)
4,096 (1000h) 1,280 (500h)
------------------------------------------------------------
4,095 (0FFFh) Y = INT(X/8) + (300h) 1,279 (4FFh)
2,048 (0800h) 1,024 (400h)
------------------------------------------------------------
2,047 (07FFh) Y = INT(X/4) + (200h) 1,023 (3FFh)
1,024 (0400h) 768 (300h)
------------------------------------------------------------
1,023 (03FFh) Y = INT(X/2) + (100h) 767 (2FFh)
512 (0200h) 512 (200h)
------------------------------------------------------------
511 (01FFh) Y = X 511 (1FFh)
0 (0000h) 0 (000h)
------------------------------------------------------------
-1 (FFFFh) Y = X -1 (FFFh)
-512 (FE00h) -512 (E00h)
------------------------------------------------------------
-513 (FFFFh) Y = INT((X + 1)/2) - (101h) -513 (DFFh)
-1,024 (FE00h) -768 (D00h)
------------------------------------------------------------
-1,025 (FBFFh) Y = INT((X + 1)/4) - (201h) -769 (CFFh)
-2,048 (F800h) -1,024 (C00h)
------------------------------------------------------------
-2,049 (F7FFh) Y = INT((X + 1)/8) - (301h) -1,025 (BFFh)
-4,096 (F000h) -1,280 (B00h)
------------------------------------------------------------
-4,097 (EFFFh) Y = INT((X + 1)/16) - (401h) -1,281 (AFFh)
-8,192 (E000h) -1,536 (A00h)
------------------------------------------------------------
-8,193 (DFFFh) Y = INT((X + 1)/32) - (501h) -1,537 (9FFh)
-16,384 (C000h) -1,792 (900h)
------------------------------------------------------------
-16,385 (BFFFh) Y = INT((X + 1)/64) - (601h) -1,793 (8FFh)
-32,768 (8000h) -2,048 (800h)
------------------------------------------------------------
------------------------------------------------------------ 3万2767 INT(X/64)+(600h)2,047(7FFh)16,384(4000h)(7FFFh)Y=1,792(700h)------------------------------------------------------------ 1万6383 INT(X/32)+(500h)1,791(6FFh)8,192(2000h)(3FFFh)Y=1,536(600h)------------------------------------------------------------ 8,191 INT(X/16)+(400h)1,535(5FFh)4,096(1000h)(1FFFh)Y=1,280(500h)------------------------------------------------------------ 4,095 INT(X/8)+(300h)1,279(4FFh)2,048(0800h)(0FFFh)Y=1,024(400h)------------------------------------------------------------ 2,047 INT(X/4)+(200h)1,023(3FFh)1,024(0400h)(07FFh)Y=768(300h)------------------------------------------------------------ 1,023 INT(X/2)+(100h)767(2FFh)512(0200h)(03FFh)Y=512(200h)------------------------------------------------------------ 511 X511(1FFh)0(0000h)(01FFh)Y=0(000h)------------------------------------------------------------ -1 (FFFFh)YはX-1(FFFh)-512(FE00h)-512(E00h)と等しいです。------------------------------------------------------------ -513(FFFFh)Y=INT((X+1)/2)--(101h)-513(DFFh)-1,024(FE00h)-768(D00h)------------------------------------------------------------ -1,025(FBFFh)Y=INT((X+1)/4)--(201h)-769(CFFh)-2,048(F800h)-1,024(C00h)------------------------------------------------------------ -2,049(F7FFh)Y=INT((X+1)/8)--(301h)-1,025(BFFh)-4,096(F000h)-1,280(B00h)------------------------------------------------------------ -4,097(EFFFh)Y=INT((X+1)/16)--(401h)-1,281(AFFh)-8,192(E000h)-1,536(A00h)------------------------------------------------------------ -8,193(DFFFh)Y=INT((X+1)/32)--(501h)-1,537(9FFh)-16,384(C000h)-1,792(900h)------------------------------------------------------------ -1万6385(BFFFh)Y=INT((X+1)/64)--(601h)-1,793(8FFh)-32,768(8000h)-2,048(800h)------------------------------------------------------------
Table 1. Conversion from 16-bit linear values (X) to 12-bit
nonlinear values (Y) [3]
1を見送ってください。 16ビットの直線的な値(X)から12ビットの非線形の値(Y)までの変換[3]
Kobayashi, et al. Standards Track [Page 3] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[3ページ]。
When conveying encoding information in an SDP [7] session description, the 12-bit nonlinear audio payload format specified here is given the encoding name "DAT12". Thus, the media format representation might be:
SDP[7]セッション記述でコード化情報を伝えるとき、ここで指定された12ビットの非線形のオーディオペイロード形式に"DAT12""というコード化名を与えます。 したがって、メディア形式表現は以下の通りです。
m=audio 49230 RTP/AVP 97 98
a=rtpmap:97 DAT12/32000/2
a=rtpmap:98 L16/48000/2
オーディオの49230RTP/AVP97 98m=a=rtpmap: 97DAT12/32000/2 a=rtpmap: 98L16/48000/2
4. 20- and 24-bit linear audio encapsulation
4. 20と24ビットの直線的なオーディオカプセル化
The 20- and 24-bit linear audio encodings are simply an extension of the L16 linear audio encoding [2]. The 20- or 24-bit uncompressed audio data samples are represented as signed values in two's complement notation. The samples are packed contiguously into payload octets starting with the most significant bit. For the 20-bit encoding, when the payload contains an odd number of samples, the four LSBs of the last octet are unused. Samples are packed into the packet in time sequence beginning with the oldest sample.
20と24ビットの直線的なオーディオencodingsは単に[2]をコード化するL16の直線的なオーディオの拡大です。 20か24ビットの解凍されたオーディオデータのサンプルがサインされた値として2の補数記法で表されます。 サンプルは始まる中でビット最も重要であるペイロード八重奏に近接して詰め込みます。 20ビットのコード化において、ペイロードがサンプルの奇数を含んでいると最後の八重奏の4LSBsが未使用です。 最も古いサンプルで始まる時間系列でサンプルにパケットに詰め込みます。
When conveying encoding information in an SDP session description, the 20- and 24-bit linear audio payload formats specified here are given the encoding names "L20" and "L24", respectively. An example SDP audio media description would be:
そして、SDPセッション記述におけるコード化情報を伝えるとき、ここで指定された20と24ビットの直線的なオーディオペイロード形式にコード化名を与える、「L20"、「それぞれL24"、」 例のSDPオーディオメディア記述は以下の通りでしょう。
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=rtpmap:100 L24/48000
オーディオの49230RTP/AVP99 100m=a=rtpmap: 99L20/48000/2 a=rtpmap: 100L24/48000
5. Preemphasized audio data
5. オーディオデータをPreemphasizedしました。
In order to improve the higher frequency characteristics of audio signals, analog preemphasis is often applied to the signal before quantization. If analog preemphasis was applied before the payload data was sampled, the type of the preemphasis SHOULD be conveyed with out-of-band signaling. An "emphasis" parameter is defined for this purpose and may be conveyed either as a MIME optional parameter or using the SDP format-specific attribute (a=fmtp line) as below:
音声信号の高周波化の特性を改良するために、アナログのプリエンファシスは量子化の前にしばしば信号に適用されます。 ペイロードデータはアナログのプリエンファシスのときに適用される前なら抽出されました、タイプ。プリエンファシスSHOULDでは、バンドの外がある運ばれたシグナリングになってください。 「強調」パラメタはこのために定義されて、MIMEの任意のパラメタとして運ばれるか、またはSDPを使用するのが、以下の形式特有の同じくらい属性であったかもしれない(a=fmtp線)なら以下の通りです。
a=fmtp:<payload type> emphasis=<emphasis type>
a=fmtp: <ペイロードタイプ>強調は<強調タイプ>と等しいです。
Only one <emphasis type> value is defined for the parameter at this point:
1つの<強調タイプ>価値だけがここにパラメタのために定義されます:
50-15 <50/15 microsecond CD-type emphasis>
50-15 50/15マイクロセカンドの間の<CDタイプ強調>。
Kobayashi, et al. Standards Track [Page 4] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[4ページ]。
The emphasis attribute MUST NOT be included in the SDP record if preemphasis was not applied. This rule allows the emphasis attribute to be used with other audio formats, in particular L16 [2], while retaining backward compatibility with existing implementations so long as preemphasis is not applied. If an existing application that does not implement preemphasis accepts a session description with an emphasis attribute but ignores that attribute, the only penalty is that the sound will be too "bright" when receiving or "dull" when sending.
プリエンファシスが適用されなかったなら、SDP記録に強調属性を含んではいけません。 この規則は、強調属性が他のオーディオ形式と共に使用されるのを許容します、プリエンファシスが適用されていない限り、既存の実現との後方の互換性を保有していて特定のL16[2]で。 プリエンファシスを実行しない既存のアプリケーションが強調属性でセッション記述を受け入れますが、その属性を無視するなら、唯一の刑罰は発信するとき、音が受信するとき、「明る過ぎる」か、または「鈍くなる」ということです。
A sample SDP record showing preemphasis applied only to payload type 99 might be as follows:
プリエンファシスがペイロードタイプ99だけに適用されたのを示すサンプルSDP記録は以下の通りであるかもしれません:
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=fmtp:99 emphasis=50-15
a=rtpmap:100 L24/48000
mはオーディオの49230RTP/AVP99 100a=rtpmapと等しいです: 99L20/48000/2 a=fmtp: 99強調は50-15 a=rtpmap: 100L24/48000と等しいです。
6. Translation of DV audio error code
6. DVオーディオエラーコードに関する翻訳
The DV video specification IEC 61834-4 [4] defines the negative full- scale audio sample value to be an audio error code indicating that no valid audio sample is available for that sample period. Such an error might occur due to a failure while reading audio data from magnetic tape. The audio error code values for each of the DV audio encodings are (in hexadecimal):
DVビデオ仕様IEC61834-4[4]は、どんな有効なオーディオのサンプルもそのサンプルの期間に利用可能でないことを示すオーディオエラーコードになるように否定的完全なスケールオーディオ標本値を定義します。 そのような誤りは失敗のため磁気テープからオーディオデータを読んでいる間、発生するかもしれません。 それぞれのDVのオーディオのencodingsのためのオーディオ誤りコード値はこと(16進で)です:
12-bit nonlinear: 800h
16-bit linear: 8000h
20-bit linear: 80000h
12ビット非線形: 800h、16ビット直線的: 8000h、20ビット直線的: 80000h
For the payload formats defined in this document, as well as for the L16 payload format defined in [2], no such error code is defined. That is, all possible sample values are valid. When an RTP sender accepts audio samples from a DV video system and encapsulates those samples according to one of these payload formats, the RTP sender SHOULD perform some error concealment algorithm which may depend upon whether a single sample error or multiple sample errors have occurred. The error concealment algorithm is not specified here and is left to the implementation. The RTP sender MAY treat the error code as if it were a valid audio sample, but this is likely to cause undesirable audio output.
本書では定義されたペイロード書式、および[2]で定義されたL16ペイロード書式において、どんなそのようなエラーコードも定義されません。 すなわちすべての可能な標本値が有効です。 RTP送付者がDVビデオシステムからオーディオのサンプルを受け入れて、これらのペイロード形式の1つに応じてそれらのサンプルをカプセルに入れるとき、RTP送付者SHOULDはただ一つのサンプル誤りか複数のサンプル誤りが発生したかどうかによるかもしれない何らかの誤り補正アルゴリズムを実行します。 誤り補正アルゴリズムは、ここで指定されないで、実現に残されます。 RTP送付者はまるでそれが有効なオーディオのサンプルであるかのようにエラーコードを扱うかもしれませんが、これは望ましくないオーディオ出力を引き起こしそうです。
Conversely, an RTP receiver that accepts audio packets in one of these payload formats and delivers the audio samples to a DV video system SHOULD translate the audio samples that would be interpreted as error codes into the next smaller negative audio value. Such audio samples may be present because the audio packets may have come
逆に、これらのペイロード形式の1つでオーディオパケットを受け入れて、DVビデオシステムSHOULDにオーディオのサンプルを渡すRTP受信機は次の、より小さい否定的オーディオへのエラーコードが評価するように解釈されるオーディオのサンプルを翻訳します。 オーディオパケットが来たかもしれないので、そのようなオーディオのサンプルは存在しているかもしれません。
Kobayashi, et al. Standards Track [Page 5] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[5ページ]。
from a source other than a DV video system. The DV video specification [4] gives the following translations for the defined audio encodings:
DVビデオシステム以外のソースから。 DVビデオ仕様[4]は定義されたオーディオのencodingsのための以下の翻訳を与えます:
12-bit nonlinear: 800h -> 801h
16-bit linear: 8000h -> 8001h
20-bit linear: 80000h - 8000Fh -> 80010h
12ビット非線形: 800h->801h、16ビット直線的: 8000h->8001h、20ビット直線的: 80000h--8000Fh->80010h
For the 20-bit linear encoding, note that multiple audio sample values are translated in order to allow a 16-bit system to play 20- bit audio data by ignoring the least significant four bits. Note also that no translation is specified for 24-bit linear audio because that encoding is not included in the DV video specification.
20ビットの直線的なコード化によって、複数のオーディオ標本値が16ビットのシステムが最も重要でない4ビットを無視することによって20の噛み付いているオーディオデータをプレーするのを許容するために翻訳されることに注意してください。 また、そのコード化がDVビデオ仕様に含まれていないので翻訳が全く24ビットの直線的なオーディオに指定されないことに注意してください。
7. Channel interleaving and non-AIFF-C audio channel convention
7. チャンネルインターリービングと非AIFFのC音声チャンネルコンベンション
When multiple channels of audio, such as in a stereo program, are multiplexed into a single RTP stream, the audio samples from each channel are interleaved according to the rules specified in [2] to be consistent with the L16 payload format. That is, samples from different channels taken at the same sampling instant are packed into consecutive octets. For example, for a two-channel encoding, the sample sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample). Samples for all channels belonging to a single sampling instant MUST be contained in the same packet.
ステレオプログラムなどのオーディオの複数のチャンネルをただ一つのRTPの流れの中に多重送信するとき、L16ペイロード形式と一致しているように[2]で指定された規則に従って、各チャンネルからのオーディオのサンプルをはさみ込みます。 瞬間を抽出する同じくらいで取られた異なったチャンネルからのすなわち、サンプルは連続した八重奏に詰め込まれます。 例えば、サンプル系列が2チャンネルのコード化のための、(左のチャンネル、最初のサンプル)である、(正しいチャンネル、最初のサンプル)、(左のチャンネル、2番目のサンプル)、(正しいチャンネル、2番目のサンプル。) 同じパケットに瞬間を抽出するシングルに属すオール・チャンネルへのサンプルを含まなければなりません。
This sample order differs from the packing of samples into blocks in a native DV audio stream. Therefore, applications transmitting DV audio using the payload formats defined in this document MUST reshuffle the samples into the order specified here. This requirement is intended to enable interworking between DV systems and other digital audio systems. Applications choosing to send bundled DV audio/video streams using the native DV block structure may use the payload format defined in [8] instead.
この見本注文は自然なDVオーディオストリームにおいてブロックへのサンプルのパッキングと異なっています。 したがって、本書では定義されたペイロード書式を使用することでDVオーディオを送るアプリケーションはここで指定されたオーダーにサンプルを改造しなければなりません。 この要件はDVシステムと他のデジタルオーディオ装置の間の織り込むことを可能にするつもりです。固有のDVブロック構造を使用することで束ねられたDVオーディオ/ビデオストリームを送るのを選ぶアプリケーションは代わりに[8]で定義されたペイロード書式を使用するかもしれません。
Most of the existing RTP audio payload formats follow the AIFF-C convention for channel ordering as specified in [2] when sending more than two audio channels within a single RTP stream. However, this convention does not cover some applications. For example, some DV audio formats define a "woofer" channel, but AIFF-C does not include this frequency-dependent channel. Thus, it is necessary to specify the audio channel allocation information explicitly when the contents of the audio stream are beyond the scope of AIFF-C.
ただ一つのRTPの流れの中で2つ以上の音声チャンネルを送るとき、既存のRTPオーディオペイロード形式の大部分はチャンネル注文のための[2]の指定されるとしてのAIFF-Cコンベンションに続きます。 しかしながら、このコンベンションはいくつかのアプリケーションをカバーしません。 例えば、いくつかのDVオーディオ形式が「低音用スピーカー」チャンネルを定義しますが、AIFF-Cはこの頻度依存チャンネルを含んでいません。 オーディオストリームの内容がAIFF-Cの範囲を超えているとき、したがって、明らかに音声チャンネル配分情報を指定するのが必要です。
For DV audio streams of 4 or more channels, the channel order MUST be specified out-of-band. This applies both to the payload formats defined in this document and to the L16 payload format. A "channel-
4個以上のチャンネルのDVオーディオストリームとして、バンドの外でチャンネル注文を指定しなければなりません。 これは本書では定義されたペイロード書式と、そして、L16ペイロード書式に適用されます。 「チャンネル」
Kobayashi, et al. Standards Track [Page 6] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[6ページ]。
order" parameter is defined here for this purpose and may be conveyed either as a MIME optional parameter or with the SDP a=fmtp attribute using the following syntax:
「オーダー」パラメタは、ここでこのために定義されて、MIMEの任意のパラメタかSDP a=fmtp属性で以下の構文を使用することで伝えられるかもしれません:
a=fmtp:<payload type> channel-order=<convention>.<order>
a=fmtp: <ペイロードタイプ>チャンネル注文は><コンベンション<オーダー>と等しいです。
The first component of the value, <convention>, specifies the type of channel assignment convention used. This allows for conventions other than AIFF-C and DV to be defined in the future. This document defines only one convention for use in the channel-order parameter:
価値の最初のコンポーネント(<コンベンション>)はコンベンションが使用したチャネル割当のタイプを指定します。 これは、AIFF-Cを除いたコンベンションとDVが将来定義されるのを許容します。 このドキュメントはチャンネルオーダパラメータにおける使用のために1つのコンベンションだけを定義します:
DV
DV
The second component of the value, <order>, indicates the arrangement of channels within the stream. The DV video specification [4] defines the types of audio channels that may be present and in what order. The symbols used to denote the channel types are reproduced in the Appendix at the end of this document. For the DV convention, the following values, which were formed from the concatenation of the individual channel symbols in the allowed channel orders, are defined for the <order> component:
価値の2番目のコンポーネント(<オーダー>)は流れの中にチャンネルのアレンジメントを示します。 DVビデオ仕様[4]は存在していて、ことで注文されるかもしれない音声チャンネルのタイプを定義します。 チャンネル種別を指示するのに使用されるシンボルはこのドキュメントの端でAppendixで再生します。 DVコンベンションに関しては、以下の値(許容チャンネル注文における、個々のチャンネルシンボルの連結から形成された)は<オーダー>の部品のために定義されます:
4 channels: LRLsRs, LRCS, LRCWo
5 channels: LRLsRsC
6 channels: LRLsRsCS, LmixRmixTWoQ1Q2
8 channels: LRCWoLsRsLmixRmix, LRCWoLs1Rs1Ls2Rs2, LRCWoLsRsLcRc
4個のチャンネル: LRLsRs、LRCWo5がチャネルを開設するLRCS: LRLsRsC6は精神を集中します: LRLsRsCS、LmixRmixTWoQ1Q2 8チャンネル: LRCWoLsRsLmixRmix、LRCWoLs1Rs1Ls2Rs2、LRCWoLsRsLcRc
The <convention> and <order> symbols are case-insensitive, but are shown here in mixed case to make the individual channel symbols more apparent. These concatenated symbols were deliberately constructed without separators to make clear the fact that the channels MUST NOT be assembled in other, arbitrary orders.
<コンベンション>と<オーダー>シンボルは、大文字と小文字を区別しないのですが、個々のチャンネルシンボルをより明らかにするようにここ、複雑な場合で見せられます。 これらの連結されたシンボルは、他の、そして、任意の命令でチャンネルを集まらせてはいけないという事実を明らかにするために故意に分離符なしで構成されました。
For interworking with DV video systems, some of the audio encodings are defined only for a subset of the channel combinations listed above. The DV video specification lists the channel combinations that are allowed for each encoding.
DVと共にビデオがシステムであると織り込むのにおいて、いくらかのオーディオのencodingsが上に記載されたチャンネル組み合わせの部分集合のためだけに定義されます。 DVビデオ仕様は各コード化のために許されているチャンネル組み合わせを記載します。
The channel-order parameter MUST be consistent with the number of channels specified in the MIME optional parameter "channels" or in the a=rtpmap attribute of SDP. For RTP audio streams of 1, 2 or 3 channels, the AIFF-C channel order is used and is implicit in the number of audio channels specified. To allow backward compatibility, the channel-order parameter MUST NOT be included in this case.
チャンネルオーダパラメータは「チャンネル」というMIMEの任意のパラメタかSDPのa=rtpmap属性で指定されるチャンネルの数と一致しているに違いありません。 1、2または3個のチャンネルのRTPオーディオストリームにおいて、AIFF-Cチャンネル注文は、使用されていて、指定された音声チャンネルの数で暗黙です。 後方の互換性を許容するために、この場合チャンネルオーダパラメータを含んではいけません。
Note that for the DV convention with 5 channels only one channel order is allowed, but for consistency the channel-order parameter MUST be included nonetheless.
5個のチャンネルだけとのDVコンベンションに関して、1つのチャンネル注文を許しますが、一貫性において、チャンネルオーダパラメータをそれにもかかわらず、含まなければならないことに注意してください。
Kobayashi, et al. Standards Track [Page 7] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[7ページ]。
An example of an SDP session description using the channel-order parameter is:
チャンネルオーダパラメータを使用するSDPセッション記述に関する例は以下の通りです。
v=0
o=ikob 2890844526 2890842807 IN IP4 126.16.64.4
s=POI (Audio only)
i=A Seminar on making Presentations on the Internet
u=http://www.koganei.wide.ad.jp/~ikob/POI/index.html
e=ikob@koganei.wide.ad.jp (Katsushi Kobayashi)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 112 113
a=rtpmap:112 L16/48000/2
a=rtpmap:113 DAT12/32000/4
a=fmtp:113 emphasis=50-15; channel-order=DV.LRCWO
インターネットu= http://www.koganei.wide.ad.jp/~ikob/POI/index.html e= ikob@koganei.wide.ad.jp の上のPresentations(小林勝志)を2873397496 2873404696c=IN IP4 224.2.17.12/127t=m=オーディオの49170RTP/AVP112 113a=rtpmapにするときのv=0 o=ikob2890844526 2890842807IN IP4 126.16.64.4 s=POI(オーディオ専用)i=A Seminar: 112 L16/48000/2 a=rtpmap: 113 DAT12/32000/4 a=fmtp: 113 強調は50-15と等しいです。 チャンネル注文はDV.LRCWOと等しいです。
This session description shows the audio medium being transmitted in two formats, L16 and DAT12, using payload type numbers 112 and 113, respectively. For the L16 format, the audio data contains 2-channel stereo following the implicit, default AIFF-C convention for left channel first and right channel second. For the DAT12 format, the audio data contains 4 channels following the DV audio convention for the channels left, right, center, and woofer.
このセッション記述は、オーディオ媒体が2つの形式、L16、およびDAT12で伝えられるのを示します、それぞれペイロード形式数112と113を使用して。 L16形式のために、オーディオデータは2番目に、最初に左のチャンネルにおいて、内在しているデフォルトAIFF-Cコンベンションに続く2チャンネルのステレオと正しいチャンネルを含んでいます。 DAT12形式のために、オーディオデータはセンターであることで真直に残っているチャンネルのためのDVオーディオコンベンションに続く4個のチャンネル、および低音用スピーカーを含んでいます。
This example also shows how multiple MIME optional parameters
("emphasis" and "channel-order") for these payload formats are mapped
to a single a=fmtp attribute as a semicolon separated list of
parameter=value pairs.
また、この例はパラメタ=価値のセミコロンの切り離されたリストに対にされるときこれらのペイロード形式のための複数のMIMEの任意のパラメタ(「強調」と「チャンネル注文」)がどうただ一つのa=fmtp属性に写像されるかを示しています。
The channel-order parameter described here provides a generic out-of- band mechanism to define alternatives to the AIFF-C channel order. However, if multi-channel audio data could be sent following the AIFF-C channel convention after simple processing, such as a data shuffling on the sender side, the alternative channel order SHOULD NOT be defined and instead the AIFF-C order SHOULD be employed to maximize interoperability.
ここで説明されたチャンネルオーダパラメータがジェネリックを外に提供する、-、-メカニズムを括って、AIFF-Cチャンネル注文への代替手段を定義してください。 しかしながら、オーディオデータを送ることができた送付者側、代替のチャンネルオーダーSHOULD NOTにおけるデータシャッフルなどの簡単な処理の後にAIFF-Cチャンネルコンベンションに続くマルチチャンネルが定義されていて代わりにAIFF-CオーダーSHOULDであるなら使われて、相互運用性を最大にしてください。
Moreover, multiple channels of audio data should only be multiplexed within a single RTP stream when all of the audio channels are intended to be reproduced together, such as the left and right channels in a stereo program. Independent audio channels, such as multiple language translations, SHOULD be sent in separate RTP sessions. This reduces bandwidth requirements by allowing receivers to tune in to only those channels which are desired.
音声チャンネルのすべてを一緒に再生させるつもりであるときだけ、そのうえ、ただ一つのRTPの流れの中でオーディオデータの複数のチャンネルを多重送信するべきです、ステレオプログラムにおける左右のチャンネルなどのように。 独立しているオーディオは送られた別々のRTPがセッションであったなら複数の言語翻訳などのようにSHOULDにチャネルを開設します。 受信機が望まれているそれらのチャンネルだけに波長を合わせるのを許容することによって、これは帯域幅要件を減らします。
Kobayashi, et al. Standards Track [Page 8] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[8ページ]。
8. MIME registration
8. MIME登録
This document defines some new RTP payload format names which are also registered as MIME subtypes: DAT12, L20 and L24. The registration forms for these MIME subtypes are provided in the next sections.
このドキュメントはまた、MIME血液型亜型として登録されるいくつかの新しいRTPペイロード形式名を定義します: DAT12、L20、およびL24。 これらのMIME血液型亜型のための登録用紙を次のセクションに提供します。
8.1 MIME registration form for audio/DAT12
8.1 オーディオ/DAT12のためのMIME登録用紙
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME subtype name: DAT12
MIME「副-タイプ」は以下を命名します。 DAT12
Required parameters:
rate: number of samples per second -- RECOMMENDED values for rate
are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000
samples per second. Other values are permissible.
必要なパラメタ: 以下を評価してください。 1秒あたりのサンプルの数--レートのためのRECOMMENDED値は、1秒あたりのサンプルに8000と、11025と、16000と、22050と、24000と、32000と、44100と48000です。 他の値は許されています。
Optional parameters:
channels: how many audio streams are interleaved -- defaults to 1;
stereo would be 2, etc. Interleaving takes place between
individual 12-bit samples.
任意のパラメタ: チャンネル: いくつのオーディオストリームがはさみ込まれるか--1へのデフォルト;。 ステレオは2でしょうなど。 インターリービングは個々の12ビットのサンプルの間の場所を取ります。
emphasis: analog preemphasis applied to the data before
quantization. The only emphasis value defined here is
emphasis=50-15 to indicate 50/15 microsecond preemphasis. This
parameter MUST be omitted if no analog preemphasis was applied.
強調: アナログのプリエンファシスは量子化の前にデータに適用されました。 ここで定義された唯一の強調値が50/15マイクロセカンドのプリエンファシスを示す強調=50-15です。 どんなアナログのプリエンファシスも適用されなかったなら、このパラメタを省略しなければなりません。
channel-order: specifies the sample interleaving order for
multiple-channel audio streams (see RFC 3190 Section 7).
Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo,
DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2,
DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.
For interoperation with DV video systems, only a subset of
these channel combinations is specified for use with 12-bit
nonlinear encoding in the DV video specification [4]; that
subset is all of the above except DV.LmixRmixTWoQ1Q2. This
parameter MUST be omitted when the AIFF-C channel order
convention is in use.
チャンネル注文: 複数のチャンネルオーディオストリーム(RFC3190セクション7を見る)のサンプルインターリービング命令を指定します。 許容値はDV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LmixRmixTWoQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRcです。 DVビデオシステムがあるinteroperationとして、これらのチャンネル組み合わせの部分集合だけがDVビデオ仕様[4]に基づく12ビットの非線形のコード化で使用に指定されます。 上記でその部分集合はDV.LmixRmixTWoQ1Q2以外のすべてです。 AIFF-Cチャンネルオーダーコンベンションが使用中であるときに、このパラメタを省略しなければなりません。
Encoding considerations:
DAT12 audio can be transmitted with RTP as specified in RFC 3190.
問題をコード化します: RFC3190の指定されるとしてのRTPと共にDAT12オーディオを送ることができます。
Security considerations: See Section 9.
セキュリティ問題: セクション9を見てください。
Interoperability considerations: NONE
相互運用性問題: なし
Kobayashi, et al. Standards Track [Page 9] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[9ページ]。
Published specification:
IEC 61119 Standard [4] and RFC 3190.
広められた仕様: IEC61119規格[4]とRFC3190。
Applications which use this media type:
Audio communication.
このメディアタイプを使用するアプリケーション: オーディオコミュニケーション。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
追加情報: マジックナンバー(s): なにも、File拡張子: マッキントッシュファイルがタイプしないなにも(s)をコード化します: なし
Person & email address to contact for further information:
Katsushi Kobayashi
e-mail: ikob@koganei.wide.ad.jp
詳細のために連絡する人とEメールアドレス: 勝志小林メール: ikob@koganei.wide.ad.jp
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
Katsushi Kobayashi
e-mail: ikob@koganei.wide.ad.jp
コントローラを書くか、または変えてください: 勝志小林メール: ikob@koganei.wide.ad.jp
8.2 MIME registration form for audio/L20
8.2 オーディオ/L20のためのMIME登録用紙
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME subtype name: L20
MIME「副-タイプ」は以下を命名します。 L20
Required parameters:
rate: number of samples per second -- RECOMMENDED values for rate
are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000
samples per second. Other values are permissible.
必要なパラメタ: 以下を評価してください。 1秒あたりのサンプルの数--レートのためのRECOMMENDED値は、1秒あたりのサンプルに8000と、11025と、16000と、22050と、24000と、32000と、44100と48000です。 他の値は許されています。
Optional parameters:
channels: how many audio streams are interleaved -- defaults to 1;
stereo would be 2, etc. Interleaving takes place between
individual 20-bit samples.
任意のパラメタ: チャンネル: いくつのオーディオストリームがはさみ込まれるか--1へのデフォルト;。 ステレオは2でしょうなど。 インターリービングは個々の20ビットのサンプルの間の場所を取ります。
emphasis: analog preemphasis applied to the data before
quantization. The only emphasis value defined here is
emphasis=50-15 to indicate 50/15 microsecond preemphasis. This
parameter MUST be omitted if no analog preemphasis was applied.
強調: アナログのプリエンファシスは量子化の前にデータに適用されました。 ここで定義された唯一の強調値が50/15マイクロセカンドのプリエンファシスを示す強調=50-15です。 どんなアナログのプリエンファシスも適用されなかったなら、このパラメタを省略しなければなりません。
channel-order: specifies the sample interleaving order for
multiple-channel audio streams (see RFC 3190 Section 7).
Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo,
DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2,
DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.
For interoperation with DV video systems, none of these channel
チャンネル注文: 複数のチャンネルオーディオストリーム(RFC3190セクション7を見る)のサンプルインターリービング命令を指定します。 許容値はDV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LmixRmixTWoQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRcです。 DVビデオシステムがあるinteroperationに関しては、これらのいずれも精神を集中しません。
Kobayashi, et al. Standards Track [Page 10] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[10ページ]。
combinations is specified for use with 20-bit linear encoding
in the DV video specification [4]; only mono and stereo are
allowed. This parameter MUST be omitted when the AIFF-C
channel order convention is in use.
組み合わせはDVビデオ仕様[4]に基づく20ビットの直線的なコード化で使用に指定されます。 モノタイプとステレオだけが許容されています。 AIFF-Cチャンネルオーダーコンベンションが使用中であるときに、このパラメタを省略しなければなりません。
Encoding considerations:
L20 audio can be transmitted with RTP as specified in RFC 3190.
問題をコード化します: RFC3190の指定されるとしてのRTPと共にL20オーディオを送ることができます。
Security considerations: See Section 9.
セキュリティ問題: セクション9を見てください。
Interoperability considerations: NONE
相互運用性問題: なし
Published specification:
RFC 3190.
広められた仕様: RFC3190。
Applications which use this media type:
Audio communication.
このメディアタイプを使用するアプリケーション: オーディオコミュニケーション。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
追加情報: マジックナンバー(s): なにも、File拡張子: マッキントッシュファイルがタイプしないなにも(s)をコード化します: なし
Person & email address to contact for further information:
Katsushi Kobayashi
e-mail: ikob@koganei.wide.ad.jp
詳細のために連絡する人とEメールアドレス: 勝志小林メール: ikob@koganei.wide.ad.jp
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
Katsushi Kobayashi
e-mail: ikob@koganei.wide.ad.jp
コントローラを書くか、または変えてください: 勝志小林メール: ikob@koganei.wide.ad.jp
8.3 MIME registration form for audio/L24
8.3 オーディオ/L24のためのMIME登録用紙
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME subtype name: L24
MIME「副-タイプ」は以下を命名します。 L24
Required parameters:
rate: number of samples per second -- RECOMMENDED values for rate
are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000
samples per second. Other values are permissible.
必要なパラメタ: 以下を評価してください。 1秒あたりのサンプルの数--レートのためのRECOMMENDED値は、1秒あたりのサンプルに8000と、11025と、16000と、22050と、24000と、32000と、44100と48000です。 他の値は許されています。
Optional parameters:
channels: how many audio streams are interleaved -- defaults to 1;
stereo would be 2, etc. Interleaving takes place between
individual 24-bit samples.
任意のパラメタ: チャンネル: いくつのオーディオストリームがはさみ込まれるか--1へのデフォルト;。 ステレオは2でしょうなど。 インターリービングは個々の24ビットのサンプルの間の場所を取ります。
Kobayashi, et al. Standards Track [Page 11] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[11ページ]。
emphasis: analog preemphasis applied to the data before
quantization. The only emphasis value defined here is
emphasis=50-15 to indicate 50/15 microsecond preemphasis. This
parameter MUST be omitted if no analog preemphasis was applied.
強調: アナログのプリエンファシスは量子化の前にデータに適用されました。 ここで定義された唯一の強調値が50/15マイクロセカンドのプリエンファシスを示す強調=50-15です。 どんなアナログのプリエンファシスも適用されなかったなら、このパラメタを省略しなければなりません。
channel-order: specifies the sample interleaving order for
multiple-channel audio streams (see Section 7). Permissible
values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC,
DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix,
DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. This parameter MUST be
omitted when the AIFF-C channel order convention is in use.
チャンネル注文: 複数のチャンネルオーディオストリーム(セクション7を見る)のサンプルインターリービング命令を指定します。 許容値はDV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LmixRmixTWoQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRcです。 AIFF-Cチャンネルオーダーコンベンションが使用中であるときに、このパラメタを省略しなければなりません。
Encoding considerations:
L24 audio can be transmitted with RTP as specified in RFC 3190.
問題をコード化します: RFC3190の指定されるとしてのRTPと共にL24オーディオを送ることができます。
Security considerations: See Section 9.
セキュリティ問題: セクション9を見てください。
Interoperability considerations: NONE
相互運用性問題: なし
Published specification:
RFC 3190.
広められた仕様: RFC3190。
Applications which use this media type:
Audio communication.
このメディアタイプを使用するアプリケーション: オーディオコミュニケーション。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
追加情報: マジックナンバー(s): なにも、File拡張子: マッキントッシュファイルがタイプしないなにも(s)をコード化します: なし
Person & email address to contact for further information:
Katsushi Kobayashi
e-mail: ikob@koganei.wide.ad.jp
詳細のために連絡する人とEメールアドレス: 勝志小林メール: ikob@koganei.wide.ad.jp
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
Katsushi Kobayashi
e-mail: ikob@koganei.wide.ad.jp
コントローラを書くか、または変えてください: 勝志小林メール: ikob@koganei.wide.ad.jp
Kobayashi, et al. Standards Track [Page 12] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[12ページ]。
9. Security Considerations
9. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1], and any appropriate RTP profile [2]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used along with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様[1]、およびどんな適切なRTPプロフィール[2]でも議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
潜在的サービスの否定の脅威は、データencodingsのために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機を積みすぎさせることができます。 しかしながら、このコード化は少しの重要な非の一様性も示しません。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [9] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
どんなIPベースのプロトコル、いくつかの事情ではも、受信機は単に必要であるか望まれないあまりに多くのパケットの領収書で積みすぎられるかもしれません。 ネットワーク層認証は望まれないソースからパケットを捨てるのに使用されるかもしれませんが、認証自体の加工費は高過ぎるかもしれません。 マルチキャスト環境で、特定のソースを取り除くのは、受信機が、どのソースがそれに達することができるかを選択するのを許容するためにIGMP[9]の将来のバージョンとマルチキャストルーティング・プロトコルで実行されるかもしれません。
10. IANA Considerations
10. IANA問題
This document defines two new MIME subtype-specific optional parameters "emphasis" and "channel-order", which are specified with the sets of permissible values for those parameters in Sections 5 and 7, respectively. Section 8 includes registrations for three new MIME subtypes that use those optional parameters. These registrations define the subset of the optional parameter values allowed for each subtype. It is expected that the number of additional values that will need to be defined for these optional parameters is small. Therefore, anyone wishing to define new values is required to produce a revision of this document to be vetted through the normal Internet Standards process.
このドキュメントはそれぞれ許容値のセットでセクション5と7のそれらのパラメタに指定される「強調」と「チャンネル注文」という2つの新しいMIME「副-タイプ」特有の任意のパラメタを定義します。 セクション8は3の新しいMIME血液型亜型のためのそれらの任意のパラメタを使用する登録証明書を含めます。 これらの登録証明書は各「副-タイプ」のために許容された任意のパラメタ値の部分集合を定義します。 これらの任意のパラメタのために定義される必要がある加算値の数が少ないと予想されます。 したがって、新しい値を定義したがっているだれでも、正常なインターネットStandardsの過程で診察されるためにこのドキュメントの改正を起こさなければなりません。
Kobayashi, et al. Standards Track [Page 13] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[13ページ]。
11. References
11. 参照
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for real-time applications," RFC 1889,
January 1996.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのTransportプロトコル」、RFC1889、1996年1月。
[2] H. Schulzrinne, "RTP profile for audio and video conferences with
minimal control", RFC 1890, January 1996.
[2] H.Schulzrinne、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
[3] IEC 61119, Digital audio tape cassette system (DAT), November
1992.
[3] IEC61119、Digitalオーディオ・テープカセット方式(DAT)、1992年11月。
[4] IEC 61834, Helical-scan digital video cassette recording system
using 6,35 mm magnetic tape for consumer use (525-60, 625-50,
1125-60 and 1250-50 systems), August 1998.
[4] IEC61834(1998年8月に消費者使用(525-60、625-50、1125-60、および1250-50台のシステム)に6、35mmの磁気テープを使用することでシステムを記録するHelical-スキャンのデジタルビデオ・カセット)。
[5] Salsman, J., "The Audio/L16 MIME content type", RFC 2586, May
1999.
[5]Salsman、J.、「Audio/L16MIME内容タイプ」、RFC2586、1999年5月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[7] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[8] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload
Format for DV (IEC 61834) Video", RFC 3189, January 2002.
[8] 小林とK.と小河とA.、CasnerとS.とC.ボルマン、「DV(IEC61834)ビデオのためのRTP有効搭載量形式」RFC3189(2002年1月)。
[9] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[9] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
Kobayashi, et al. Standards Track [Page 14] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[14ページ]。
Appendix
付録
The DV audio channel symbols are specified in Table 2. These symbols are taken from the notation used in the DV video specification IEC 61834-4 [4], chapter 8.1. For the exact meaning of each symbol, the original DV video specification should be consulted.
DV音声チャンネルシンボルはTable2で指定されます。 DVビデオ仕様IEC61834-4[4]、第8.1章で使用される記法からこれらのシンボルを取ります。 それぞれのシンボルの正確な意味において、当初のDVビデオ仕様は相談されるべきです。
L: Left channel of stereo
R: Right channel of stereo
M: Monaural signal
C: Center channel of 3,4,6 or 8 channel audio
S: Surround channel of 4 channel audio
Ls, Ls1, Ls2: Left surround channel
Rs, Rs1, Rs2: Right surround channel
Lc: Left center channel of 8 channel audio
Rc: Right center channel of 8 channel audio
Wo: Woofer channel
Lmix: L + 0.7071C + 0.7071LS
Rmix: R + 0.7071C + 0.7071RS
T: 0.7071C
Q1: 0.7071LS + 0.7071RS
Q2: 0.7071LS - 0.7071RS
L: ステレオRの左のチャンネル: ステレオMの正しいチャンネル: モノラルの信号C: 3、4、6または8チャンネルオーディオSのチャンネルを中心に置いてください: 4チャンネルのオーディオのLs、Ls1、Ls2のチャンネルを囲んでください: 左の取り囲むものチャンネルRs、Rs1、Rs2: 右の取り囲むものチャンネルLc: 8のチャンネルのオーディオのRcの左のセンターチャンネル: 8のチャンネルのオーディオのWoの正しいセンターチャンネル: 低音用スピーカーチャンネルLmix: L+0.7071C+0.7071LS Rmix: R+0.7071C+0.7071RS T: 0.7071C Q1: 0.7071LS+0.7071RS Q2: 0.7071LS--0.7071RS
Table 2. Channel symbols for audio channels in DV video [4]
2を見送ってください。 DVビデオの音声チャンネルのチャンネルシンボル[4]
Kobayashi, et al. Standards Track [Page 15] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[15ページ]。
Authors' Addresses
作者のアドレス
Katsushi Kobayashi Communication Research Laboratory 4-2-1 Nukii-kita machi, Koganei Tokyo 184-8795 JAPAN
Communication研究所4-2-1Nukii-kita machi、勝志小金井東京日本の小林184-8795
Phone: +81 42 327 6174 EMail: ikob@koganei.wide.ad.jp
以下に電話をしてください。 +81 42 327 6174はメールされます: ikob@koganei.wide.ad.jp
Akimichi Ogawa Keio University 5322 Endo, Fujisawa Kanagawa 252 JAPAN
Akimichi小河慶応義塾大学5322の遠藤、神奈川日本藤沢252
EMail: akimichi@sfc.wide.ad.jp
メール: akimichi@sfc.wide.ad.jp
Stephen L. Casner Packet Design 2465 Latham Street Mountain View, CA 94040 United States
スティーブンL.Casner2465レイサム通りマウンテンビュー、パケットデザインカリフォルニア94040合衆国
Phone: +1 650-943-1843 EMail: casner@acm.org
以下に電話をしてください。 +1 650-943-1843 メールしてください: casner@acm.org
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI Postfach330440D-28334ブレーメン(ドイツ)
Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org
以下に電話をしてください。 +49 421 218、7024Fax: +49 7000年の421 218メール: cabo@tzi.org
Kobayashi, et al. Standards Track [Page 16] RFC 3190 RTP Payload Format January 2002
小林、他 規格はRTP有効搭載量形式2002年1月にRFC3190を追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kobayashi, et al. Standards Track [Page 17]
小林、他 標準化過程[17ページ]
一覧
スポンサーリンク
