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
RTP Payload Format for
12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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).
この文書では、12ビットの非線形、20ビットリニア、リアルタイムトランスポートプロトコル（RTP）を使用して、24ビットリニアオーディオデータストリームをカプセル化するためのパケット化方式を指定します。この文書では、オーディオデータをサンプリングする前にプリエンファシスされたときに示すために、セッション記述プロトコル（SDP）パラメータの形式を指定します。パラメータは、L16（16ビットリニア）、特に、他のオーディオペイロードフォーマットと共に使用することができます。
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 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.
この文書では、12ビットの非線形、20ビットリニア、及び24ビットの線形符号化オーディオデータのサンプリングを記述し、リアルタイムトランスポートプロトコル（RTP）、バージョン2 [1にオーディオデータのカプセル化を指定します2]。 DAT（デジタルオーディオテープ）とDV（デジタルビデオ）装置[3,4]は、16ビットの線形符号化に加えて、これらのオーディオ符号化を使用します。 16ビットリニアオーディオパケット化スキーム（L16）が既に指定されている[2,5]。この文書では、L16のそれ以下の他のエンコーディングのためのパケット化スキームを指定します。 [2] RTPプロファイルで使用される場合、特に、これらのペイロードフォーマットはここで指定された[2]プラス拡張で指定されたインタリーブサンプル順序およびチャンネルのための符号化に依存しない規則に従います。この文書はまた、拡張チャンネルインタリービング規則およびアナログプリエンファシス技術は、オーディオデータに適用される使用のためのアウトオブバンドネゴシエーション方法を指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[6]。
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などの視覚システム、多くは、サンプルベースのオーディオ符号化方式を採用しています。さまざまなオーディオフォーマットは、様々な場面で使用されています。 RTPを使用してオーディオデータを転送するために、カプセル化は、各特定のフォーマットのために定義される必要があります。唯一の16ビットリニアオーディオカプセル化（L16）は、これまでに定義されています。他の符号化フォーマットは、すでにそのような12ビットの非線形、20ビットのリニア及びDATとDVビデオの世界で使用される24ビットの線形符号化として、登場しています。この仕様は、RTP環境で新しいエンコーディングを使用するために、RTPペイロードのカプセル化形式を定義します。
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.
IEC 61119 [3] LP（長時間再生）オーディオと呼ばれる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ビットリニアオーディオの場合と同じです。 12ビットの非線形オーディオの各サンプルは、非線形圧縮により16ビットリニアオーディオの単一のサンプルに由来します。表1は、16〜12ビットの変換の詳細を示しています。結果は-2048から2047までの範囲の12ビット符号付きの値であり、それは2の補数で表現されます。 12ビットのサンプルは、最上位ビットから始まるペイロードオクテットに連続してパックされます。ペイロードは、サンプルの奇数が含まれている場合、最後のオクテットの4つのLSBは未使用です。量子化、例えば、サンプリング周波数及びオーディオチャネル割当て以外のパラメータは、L16ペイロードフォーマットと同じです。具体的には、サンプルは、最も古いサンプルから始まる時系列でパケットにパックされています。
------------------------------------------------------------
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)
------------------------------------------------------------
Table 1. Conversion from 16-bit linear values (X) to 12-bit nonlinear values (Y) [3]
表1に変換16ビットリニア値（X）からの12ビットの非線形値（Y）[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
M =オーディオ49230 RTP / AVP 97 98 = rtpmap：97 DAT12 / 2分の32000 = rtpmap：98 L16 / 2分の48000
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ビットリニアオーディオエンコーディング[2]は単にL16リニアオーディオ符号化の拡張です。 20-または24ビット非圧縮の音声データサンプルが2の補数表現で符号付きの値として表されます。サンプルは、最上位ビットから始まるペイロードオクテットに連続してパックされます。ペイロードは、サンプルの奇数を含む場合、20ビットの符号化のために、最後のオクテットの4つのLSBは未使用です。サンプルは、最も古いサンプルから始まる時系列でパケットにパックされています。
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
M =オーディオ49230 RTP / AVP 99 100 = rtpmap：99 L20 / 48000/2 = rtpmap：100 L24 / 48000
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:
オーディオ信号の高周波数特性を改善するために、アナログプリエンファシスは、多くの場合、量子化前の信号に適用されます。アナログプリエンファシスが適用された場合、ペイロードデータがサンプリングされる前に、プリエンファシスの種類は、帯域外信号で搬送されるべきです。 「強調」パラメータは、この目的のために定義され、MIMEオプションのパラメータとして、以下のようSDPフォーマット固有の属性（=のfmtp線）を使用してのいずれかで運ばれてもよいです。
a=fmtp:<payload type> emphasis=<emphasis type>
=のfmtp：<ペイロードタイプ>強調= <重視タイプ>
Only one <emphasis type> value is defined for the parameter at this point:
一つだけ<重視タイプ>の値は、この時点でパラメータに定義されています。
50-15 <50/15 microsecond CD-type emphasis>
50-15 <50/15マイクロ秒のCD-型強調>
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:
プリエンファシスを示すサンプルSDPレコードは、ペイロードタイプ99にのみ適用される以下の通りであるかもしれません。
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 =オーディオ49230 RTP / AVP 99 100 = rtpmap：= 99のfmtp L20 / 48000 /図2a：99重点= 50-15 = rtpmap：100 L24 / 48000
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ビデオ規格IEC 61834から4 [4]は有効なオーディオサンプルが、そのサンプル期間のために利用可能でないことを示すオーディオエラーコードであると負のフルスケールオーディオサンプル値を定義します。磁気テープからオーディオデータを読み込み中にこのようなエラーが故障により発生する可能性があります。 DVオーディオエンコーディングの各オーディオエラーコード値が（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ビデオシステムからのオーディオサンプルを受け取り、これらのペイロード・フォーマットのいずれかに記載のそれらのサンプルをカプセル化する際に、RTP送信機は、単一のサンプルエラーまたは複数のサンプルのエラーが発生したかどうかに依存し得るいくつかの誤り隠蔽アルゴリズムを実行しなければなりません。エラー隠蔽アルゴリズムは、ここで指定されていないと実装に任されています。それは有効なオーディオサンプルであるかのように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 from a source other than a DV video system. The DV video specification [4] gives the following translations for the defined audio encodings:
逆に、これらのペイロード・フォーマットのいずれかで音声パケットを受け入れ、DVビデオシステムにオーディオサンプルを提供しRTP受信機は、次に小さい負オーディオ値にエラーコードとして解釈されるオーディオサンプルを変換すべきです。オーディオパケットがDVビデオシステム以外のソースから来ている可能性があるため、このようなオーディオサンプルが存在してもよいです。 DVビデオ仕様[4]定義されたオーディオ符号化のために、次の変換を与えます。
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ビットの線形符号化のために、複数のオーディオサンプル値は、最下位4ビットを無視することにより、20-ビットのオーディオデータを再生する16ビットシステムを可能にするために翻訳されることに注意してください。そのエンコーディングは、DVビデオ仕様に含まれていないので、何の変換は24ビットリニアオーディオ用に指定されていないことにも注意してください。
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ストリームに多重化される場合、各チャンネルからの音声サンプルを[2] L16ペイロードフォーマットと一致するように指定された規則に従ってインターリーブされます。つまり、同じサンプリング時点で取られた異なるチャネルからのサンプルは、連続したオクテットにパックされています。例えば、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ストリーム内の二つ以上のオーディオチャネルを送信する際に、既存の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- 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:
4チャンネル以上のDVオーディオストリームに対して、チャネル順序は、帯域外を指定しなければなりません。これは、この文書で定義されたペイロードフォーマット及びL16ペイロードフォーマットの両方に適用されます。 「チャネル - 順」パラメータは、この目的のためにここで定義され、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以外の規則が将来定義するためにこれが可能となります。この文書では、チャネル・オーダーパラメータで使用するための唯一の規則を定義しています。
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:
値は、<順番>の第二の成分は、ストリーム内のチャネルの構成を示しています。 DVビデオ仕様[4]は存在し、どのような順序であってもよく、オーディオチャンネルの種類を定義します。チャネルタイプを示すために使用される記号は、この文書の末尾の付録に再生されます。 DV大会のために、許可されたチャネルの順序で個々のチャネルシンボルの連結から形成された次の値は、<順序>コンポーネントに対して定義されています。
4 channels: LRLsRs, LRCS, LRCWo 5 channels: LRLsRsC 6 channels: LRLsRsCS, LmixRmixTWoQ1Q2 8 channels: LRCWoLsRsLmixRmix, LRCWoLs1Rs1Ls2Rs2, LRCWoLsRsLcRc
4つのチャネル：LRLsRs、のLRC、LRCWo 5つのチャネル：LRLsRsC 6つのチャネル：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ビデオシステムと連動するために、オーディオエンコードの一部のみが上記チャネルの組み合わせのサブセットのために定義されています。 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大会のために一つのチャンネルのみ注文が許可されていますが、一貫性を保つためのチャネル次のパラメータは、それにもかかわらず含まれている必要があります。
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
V = 0 O IP4 126.16.64.4のS =のPOI IN = ikob 2890844526 2890842807（音声のみ）私は、インターネット上でプレゼンテーションを行うセミナーを= U =のhttp：//www.koganei.wide.ad.jp/~ikob/POI /index.htmlがe=ikob@koganei.wide.ad.jp（勝志小林）C = IP4 224.2.17.12/127 IN T = 2873397496 2873404696メートル=オーディオ49170 RTP / AVP 112 113 = rtpmap：112 L16 / 48000 / 2 A = rtpmap：113 DAT12 / 4分の32000 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.
このセッション記述は、それぞれ、ペイロードタイプ番号112及び113を用いて、二つのフォーマット、L16及びDAT12に送信された音声メディアを示しています。 L16形式の場合、音声データは、第1の左チャネルと右チャネルの第二の暗黙的なデフォルト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チャネル順の代替を定義するための一般的なアウトオブバンドメカニズムを提供します。しかしながら、マルチチャネルオーディオデータは、送信側シャフリングデータのような単純な処理後AIFF-Cチャネル規則は、次の送信することができれば、別のチャンネル順序が定義されるべきではなく、代わりに、AIFF-Cの順序が使用されてください相互運用性を最大限に高めることができます。
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セッションで送ってください。これは、所望されるだけのチャンネルにチューニングする受信を可能にすることにより、帯域幅要件を低減します。
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.
DAT12、L20およびL24：この文書はまた、MIMEサブタイプとして登録されているいくつかの新しいRTPペイロード形式名を定義します。これらの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.
必要なパラメータ：速度：秒当たりのサンプル数 - 速度の推奨値は、毎秒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.
チャネル順序：マルチチャンネルオーディオストリームのサンプル・インターリーブ順序を（RFC 3190のセクション7を参照）を指定します。許容値はDV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LmixRmixTWoQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRcです。 DVビデオシステムとの相互運用のために、これらのチャネルの組み合わせのサブセットのみがDVビデオ仕様の12ビットの非線形符号化で使用するために指定されている[4]。そのサブセットはDV.LmixRmixTWoQ1Q2を除く上記のすべてです。 AIFF-Cチャンネルの順序規則が使用されている場合、このパラメータは省略されなければなりません。
Encoding considerations: DAT12 audio can be transmitted with RTP as specified in RFC 3190.
エンコードの考慮事項：RFC 3190で指定されたDAT12オーディオはRTPで送信することができます。
Security considerations: See Section 9.
セキュリティの考慮事項：第9節を参照してください。
Interoperability considerations: NONE
相互運用性に関する注意事項：NONE
Published specification: IEC 61119 Standard [4] and RFC 3190.
公開された仕様：IEC 61119規格[4]及びRFC 3190。
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）：なしファイルの拡張子（秒）：なしMacintoshのファイルタイプコード（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
意図している用法：COMMON
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
著者/変更コントローラ：克志小林メール：ikob@koganei.wide.ad.jp
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.
必要なパラメータ：速度：秒当たりのサンプル数 - 速度の推奨値は、毎秒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 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.
チャネル順序：マルチチャンネルオーディオストリームのサンプル・インターリーブ順序を（RFC 3190のセクション7を参照）を指定します。許容値はDV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LmixRmixTWoQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRcです。 DVビデオシステムとの相互運用のために、これらのチャネルの組み合わせのいずれもDVビデオ仕様の20ビットの線形符号化で使用するために指定されていない[4]。モノラルとステレオだけが許可されています。 AIFF-Cチャンネルの順序規則が使用されている場合、このパラメータは省略されなければなりません。
Encoding considerations: L20 audio can be transmitted with RTP as specified in RFC 3190.
エンコードの考慮事項：RFC 3190で指定されているようL20オーディオはRTPで送信することができます。
Security considerations: See Section 9.
セキュリティの考慮事項：第9節を参照してください。
Interoperability considerations: NONE
相互運用性に関する注意事項：NONE
Published specification: RFC 3190.
公開された仕様：RFC 3190。
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）：なしファイルの拡張子（秒）：なしMacintoshのファイルタイプコード（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
意図している用法：COMMON
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
著者/変更コントローラ：克志小林メール：ikob@koganei.wide.ad.jp
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.
必要なパラメータ：速度：秒当たりのサンプル数 - 速度の推奨値は、毎秒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ビットのサンプルとの間で行われます。
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.
エンコードの考慮事項：RFC 3190で指定されているようL24オーディオはRTPで送信することができます。
Security considerations: See Section 9.
セキュリティの考慮事項：第9節を参照してください。
Interoperability considerations: NONE
相互運用性に関する注意事項：NONE
Published specification: RFC 3190.
公開された仕様：RFC 3190。
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）：なしファイルの拡張子（秒）：なしMacintoshのファイルタイプコード（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
意図している用法：COMMON
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
著者/変更コントローラ：克志小林メール：ikob@koganei.wide.ad.jp
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]。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。このペイロード形式と一緒に使用されるデータ圧縮は、エンドツーエンドで適用されるので、二つの操作の間に競合がないので、暗号化は、圧縮後に行ってもよいです。
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.
潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を使用してデータ・エンコーディングのために存在します。攻撃者が復号及び受信機が過負荷にさせるのに複雑であるストリームに病理学的なデータグラムを注入することができます。しかし、このエンコーディングは、有意な不均一性を示しません。
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]とマルチキャストルーティングプロトコルにおける受信機は、それに到達するために許可されているソースを選択できるようにします。
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サブタイプのための登録を含んでいます。これらの登録は、各サブタイプに許可オプションのパラメータ値のサブセットを定義します。これらのオプションのパラメータのために定義する必要があります追加の値の数が少ないことが期待されています。そのため、新しい値を定義したい人は、通常のインターネット標準化プロセスを吟味するために、この文書の改訂を生成するために必要とされます。
[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. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル、" RFC 1889、1996年1月。
[2] H. Schulzrinne, "RTP profile for audio and video conferences with minimal control", RFC 1890, January 1996.
[2] H. Schulzrinneと、 "最小限の制御で、オーディオおよびビデオ会議用RTPプロファイル"、RFC 1890、1996年1月。
[3] IEC 61119, Digital audio tape cassette system (DAT), November 1992.
[3] IEC 61119、デジタルオーディオテープカセットシステム（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] IEC 61834、6,35ミリ民生（525から60まで、625から50まで、1125から1160および1250から1250システム）、1998年8月用の磁気テープを用いたヘリカルスキャンデジタルビデオカセット記録システム。
[5] Salsman, J., "The Audio/L16 MIME content type", RFC 2586, May 1999.
[5] Salsman、J.、 "オーディオ/ L16 MIMEコンテンツタイプ"、RFC 2586、1999月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、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のためのRTPペイロードフォーマット（IEC 61834）ビデオ"、RFC 3189、2002年1月。
[9] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[9]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
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オーディオチャネルシンボルは、これらのシンボルは、DVビデオ明細書で使用される表記法から取得され、表2に規定されているIEC 61834から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チャンネルオーディオの右センターチャンネル臥：ウーファーチャネル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]
DVビデオのオーディオチャンネル表2.チャネルシンボル[4]
Authors' Addresses
著者のアドレス
Katsushi Kobayashi Communication Research Laboratory 4-2-1 Nukii-kita machi, Koganei Tokyo 184-8795 JAPAN
かつし こばやし こっむにかちおん れせあｒｃｈ ぁぼらとｒｙ ４ー２ー１ ぬきいーきた まち、 こがねい ときょ １８４ー８７９５ じゃぱん
Phone: +81 42 327 6174 EMail: ikob@koganei.wide.ad.jp
電話：+81 42 327 6174 Eメール：ikob@koganei.wide.ad.jp
Akimichi Ogawa Keio University 5322 Endo, Fujisawa Kanagawa 252 JAPAN
あきみち おがわ けいお うにゔぇｒしｔｙ ５３２２ えんど、 ふじさわ かながわ ２５２ じゃぱん
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. Casnerパケットデザイン2465レーサムストリートマウンテンビュー、CA 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 POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org
電話：+49 421 218 7024ファックス：+49 421 218 7000 Eメール：cabo@tzi.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。