Network Working Group B. Link
Request for Comments: 4184 T. Hager
Category: Standards Track Dolby Laboratories
J. Flaks
Microsoft Corporation
October 2005
RTP Payload Format for AC-3 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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation.
この文書では、AC-3オーディオ圧縮規格を使用してオーディオデータを搬送するためのRTPペイロードフォーマットを記述する。 AC-3は、米国のHDTV、DVD、ケーブルテレビ、衛星テレビや他のメディアに使用される高品質、マルチチャンネルオーディオコーディングシステムです。この文書のRTPペイロードフォーマットは、データの断片化のためのサポートを含みます。
AC-3 [ATSC] is a high-quality audio codec (audio coding format) designed to encode multiple channels of audio into a low bit-rate format. AC-3 achieves its large compression ratios via encoding a multiplicity of channels as a single entity. Dolby Digital, which is a branded version of AC-3, encodes up to 5.1 channels of audio.
AC-3 [ATSC]は、低ビットレートフォーマットにオーディオの複数のチャネルを符号化するために設計された高品質のオーディオコーデック（オーディオコーディングフォーマット）です。 AC-3は、単一のエンティティとして多数のチャネルをコードを介して、その大きな圧縮比を達成します。 AC-3のブランドのバージョンであるドルビーデジタルは、オーディオの5.1チャンネルを符号化します。
AC-3 has been adopted as an audio compression scheme for many consumer and professional applications. It is a mandatory audio codec for DVD-video, Advanced Television Standards Committee (ATSC) digital terrestrial television and Digital Living Network Alliance (DLNA) home networking, as well as an optional multichannel audio format for DVD-audio.
AC-3は、多くの消費者および専門家の双方のアプリケーションのためのオーディオ圧縮方式として採用されています。これは、DVDビデオのための必須オーディオコーデック、高度テレビジョン方式委員会（ATSC）地上デジタルテレビやデジタルリビングネットワークアライアンス（DLNA）ホームネットワーキングのほか、DVDオーディオのためのオプションのマルチチャンネルオーディオフォーマットです。
There is a need to stream AC-3 data over IP networks. The Internet Real Time Protocol (RTP) provides a mechanism for stream synchronization and hence serves as the best transport solution for AC-3, which is primarily used in audio-for-video applications. Applications for streaming AC-3 include streaming movies from a home media server to a display, video on demand, and multichannel Internet radio.
IPネットワーク上でAC-3データをストリームする必要があります。インターネットリアルタイムプロトコル（RTP）は、ストリームの同期のためのメカニズムを提供し、従って、AC-3、主にオーディオ用のビデオアプリケーションで使用されるための最良の輸送溶液として働きます。 AC-3をストリーミングするためのアプリケーションは、ストリーミング表示にホームメディアサーバから映画、ビデオオンデマンド、およびマルチチャンネルのインターネットラジオが含まれています。
Section 2 gives a brief overview of the AC-3 algorithm. Section 3 specifies values for fields in the RTP header, while Section 4 specifies the AC-3 payload format. Section 5 discusses media types and SDP usage. Security considerations are covered in Section 6, congestion control in Section 7, and IANA considerations in Section 8. References are given in Sections 9 and 10.
第2節では、AC-3アルゴリズムの概要を示します。セクション4は、AC-3ペイロード形式を指定しながら、第3節では、RTPヘッダ内のフィールドの値を指定します。第5節では、メディアタイプとSDP使用方法について説明します。セキュリティの考慮事項は、セクション7でセクション6、輻輳制御で覆われており、第8の参考文献にIANA問題はセクション9及び10に示されています。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
AC-3 can deliver up to 5.1 channels of audio at data rates approximately equal to half of one PCM channel [ATSC], [1994AC3], [1996AC3]. The ".1" refers to a band-limited, optional, low-frequency effects (LFE) channel. AC-3 was designed for signals sampled at rates of 32, 44.1, or 48 kHz. Data rates can vary between 32 kbps and 640 kbps, depending on the number of channels and the desired quality.
AC-3 [1996AC3]、[1994AC3]一つのPCMチャネル[ATSC]の半分にほぼ等しいデータレートでオーディオの5.1チャンネルまで送達することができます。 」.1" は帯域制限され、任意に、低周波数効果（LFE）チャネルを指します。 AC-3は、32、44.1、または48キロヘルツのレートでサンプリングされた信号のために設計されました。データレートがチャネルの数と所望の品質に依存して、32 kbpsの640 kbpsの間で変化させることができます。
AC-3 exploits psycho-acoustic phenomena that cause a significant fraction of the information contained in a typical audio signal to be inaudible. Substantial data reduction occurs via the removal of inaudible information contained in an audio stream. Source coding techniques are further used to reduce the data rate.
AC-3は、典型的な音声信号に含まれる情報のかなりの割合が聞こえないことが原因と心理音響現象を利用します。かなりのデータ削減は、オーディオストリームに含まれて聞こえない情報の除去を介して起こります。ソース符号化技術は、データ・レートを低下させるために使用されています。
Like most perceptual coders, AC-3 operates in the frequency domain. A 512-point TDAC transform is taken with 50% overlap, providing 256 new frequency samples. Frequency samples are then converted to exponents and mantissas. Exponents are differentially encoded. Mantissas are allocated a varying number of bits depending on the audibility of the associated spectral components. Audibility is determined via a masking curve. Bits for mantissas are allocated from a global bit pool.
最も知覚的コーダーのように、AC-3は、周波数領域で動作します。 512点TDAC変換256新たな周波数サンプルを提供し、50％のオーバーラップで撮影されています。周波数サンプルは、その後、指数と仮数に変換されます。指数は、差動符号化されています。仮数は、関連するスペクトル成分の可聴性に応じてビットの変化数を割り当てられます。聴感マスキングカーブを経て決定されます。仮数のためのビットは、グローバルビットプールから割り振られます。
AC-3 bit streams are organized into synchronization frames. Each AC-3 frame contains a Synchronization Information (SI) field, a Bit Stream Information (BSI) field, and 6 audio blocks (ABs) that each represent 256 PCM samples for all channels. The frame ends with an optional auxiliary data field (AUX) and an error correction field (CRC). The entire frame represents the time duration of 1536 PCM samples across all coded channels [ATSC]. AC-3 encodes audio sampled at 32 kHz, 44.1 kHz, and 48 kHz. From Annex A, Part 2, of [ATSC], the time duration of an AC-3 frame varies with the sampling rate as follows:
AC-3ビットストリームは、同期フレームに編成されます。各AC-3フレームは、各々が全てのチャンネル256個のPCMサンプルを表すこと同期情報（SI）フィールド、ビットストリーム情報（BSI）フィールドを含み、6つのオーディオブロック（ABS）。フレームは、オプションの補助データフィールド（AUX）と誤り訂正フィールド（CRC）で終わります。フレーム全体は、すべての符号化されたチャネル[ATSC]横切る1536個のPCMサンプルの持続時間を表します。 AC-3は、32 kHzの、44.1kHzで、及び48kHzでサンプリングされた音声を符号化します。以下の通りの附属書A、パート2、[ATSC]から、AC-3フレームの持続時間は、サンプリングレートに応じて変化します。
Sampling rate Frame duration
_____________________________________
48 kHz 32 ms
44.1 kHz approx. 34.83 ms
32 kHz 48 ms
Figure 1 shows the AC-3 frame format.
図1は、AC-3フレームフォーマットを示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SI |BSI| AB0 | AB1 | AB2 | AB3 | AB4 | AB5 |AUX|CRC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AC-3 Frame Format
図1. AC-3フレームフォーマット
The Synchronization Information field contains information needed to acquire and maintain codec synchronization. The Bit Stream Information field contains parameters that describe the coded audio service [ATSC]. Each audio block contains fields that indicate the use of various coding tools: block switching, dither, coupling, and exponent strategy. They also contain metadata, optionally used to enhance the playback, such as dynamic range control. Finally, the exponents and bit allocation data needed to decode the mantissas into audio data, and the mantissas themselves, are included. The placement of these fields in an AC-3 audio block is shown in Figure 2. The fields shown in this figure are described in detail in [ATSC]. Note that field sizes vary depending on the coded data.
同期情報フィールドは、コーデックの同期を獲得し、維持するために必要な情報が含まれています。ビットストリーム情報フィールドは、符号化されたオーディオサービス[ATSC]を記述するパラメータが含まれています。ブロックスイッチング、ディザ、結合、および指数戦略：各オーディオブロックは、様々な符号化ツールの使用を示すフィールドが含まれています。彼らはまた、必要に応じて、ダイナミックレンジ制御として再生を増強するために使用される、メタデータを含みます。最後に、指数及び音声データに仮数をデコードするために必要なビット割り当てデータ、および仮数自体が、含まれています。 AC-3音声ブロックにおけるこれらのフィールドの配置は、この図に示されるフィールドは、[ATSC]に詳細に記載されている図2に示されています。フィールドサイズは、符号化されたデータに依存して変化することに注意してください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block |Dither |Dynamic |Coupling |Coupling |Exponent |
| Switch |Flags |Range Ctrl |Strategy |Coordinates |Strategy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponents | Bit Allocation | Mantissas |
| | Parameters | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. AC-3 Audio Block Format
図2. AC-3オーディオブロックフォーマット
o Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document. It is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using SDP).
Oペイロードタイプ（PT）：このパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。なお、このペイロードフォーマットが使用される、またはアウトオブバンド（例えば、SDPを使用して）動的に通知され、その下RTPプロファイルで指定されています。
o Marker (M) bit: The M bit is set to one to indicate that the RTP packet payload contains at least one complete AC-3 frame or contains the final fragment of an AC-3 frame.
Oマーカ（M）ビット：Mビットは、RTPパケットのペイロードは、少なくとも1つの完全なAC-3フレームを含むか、AC-3フレームの最後の断片を含むことを示すために1に設定されています。
o Extension (X) bit: Defined by the RTP profile used.
O拡張（X）ビット：使用RTPプロファイルによって定義されています。
o Timestamp: A 32-bit word that corresponds to the sampling instant for the first AC-3 frame in the RTP packet. Packets containing fragments of the same frame MUST have the same time stamp. The timestamp of the first RTP packet sent SHOULD be selected at random. Thereafter, the timestamp increases linearly with the number of samples included in each frame (i.e., by 1536 for each frame).
Oタイムスタンプ：RTPパケット内の最初のAC-3フレームのサンプリング瞬間に対応する32ビット・ワード。同じフレームの断片を含むパケットは、同じタイムスタンプを持たなければなりません。送信された最初のRTPパケットのタイムスタンプは、ランダムに選択されるべきである（SHOULD）。その後、直線的サンプルの数とタイムスタンプが増加する（即ち、フレーム毎に1536によって）各フレームに含まれます。
This payload format is defined for AC-3, as defined in the main part and Annex D of [ATSC]. It is not defined for E-AC-3, as defined in Annex E of [ATSC], and it MUST NOT be used to carry E-AC-3.
[ATSC]の主要部分と付属書Dで定義されるように、このペイロードフォーマットは、AC-3のために定義されています。 [ATSC]の付録Eで定義されるように、それは、E-AC-3に定義されていない、E-AC-3を搬送するために使用してはいけません。
According to [RFC2736], RTP payload formats should contain an integral number of application data units (ADUs). The AC-3 frame corresponds to an ADU, in the context of this payload format. Each RTP payload MUST start with the two-byte payload header followed by an integral number of complete AC-3 frames or by a single fragment of an AC-3 frame.
[RFC2736]によれば、RTPペイロードフォーマットは、アプリケーション・データ・ユニット（のADU）の整数を含むべきです。 AC-3フレームは、このペイロードフォーマットの文脈において、ADUに対応します。各RTPペイロードは、完全なAC-3フレームの整数によって、またはAC-3フレームの単一のフラグメントに続く2バイトのペイロードヘッダで始まる必要があります。
If an AC-3 frame exceeds the MTU for a network, it SHOULD be fragmented for transmission within an RTP packet. Section 4.2 provides guidelines for creating frame fragments.
AC-3フレームはネットワークのMTUを超えた場合、それは、RTPパケット内の送信のために断片化されるべきです。 4.2節では、フレームの断片を作成するためのガイドラインを提供します。
There is a two-octet Payload Header at the beginning of each payload.
各ペイロードの先頭に2オクテットのペイロードヘッダがあります。
Each AC-3 RTP payload MUST begin with the payload header shown in Figure 3.
各AC-3 RTPペイロードは、図3に示したペイロードヘッダで始まる必要があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | FT| NF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AC-3 RTP Payload Header
図3 AC-3 RTPペイロードヘッダ
o MBZ (Must Be Zero): Bits marked MBZ SHALL be set to the value zero and SHALL be ignored by receivers. The bits are reserved for future extensions.
O MBZは（ゼロでなければならない）：ビットは、MBZが値ゼロに設定されるものとし、受信機によって無視されるマーク。ビットは、将来の拡張のために予約されています。
o FT (Frame Type): This two-bit field indicates the type of frame(s) present in the payload. It takes the following values:
O FT（フレーム・タイプ）：この2ビットフィールドは、ペイロード内に存在するフレーム（複数可）のタイプを示します。それは次の値をとります。
0 - One or more complete frames. 1 - Initial fragment of frame which includes the first 5/8ths of the frame. (See Section 4.2.) 2 - Initial fragment of frame, which does not include the first 5/8ths of the frame. 3 - Fragment of frame other than initial fragment. (Note that M bit in RTP header is set for final fragment).
0 - 1つ以上の完全なフレーム。 1 - フレームの最初の5 / 8thsを含むフレームの最初の断片。 （セクション4.2を参照。）2 - フレームの最初の断片、フレームの最初の5 / 8thsを含みません。 3 - 最初のフラグメント以外のフレームのフラグメント。 （RTPヘッダ内のMビットは、最終的な断片のために設定されることに注意してください）。
o NF (Number of frames/fragments): An 8-bit field whose meaning depends on the Frame Type (FT) in this payload. For complete frames (FT of 0), it is used to indicate the number of AC-3 frames in the RTP payload. For frame fragments (FT of 1, 2, or 3), it is used to indicate the number fragments (and therefore packets) that make up the current frame. NF MUST be identical for packets containing fragments of the same frame.
O NF（フレーム/フラグメントの数）：意味このペイロードにフレームタイプ（FT）に依存して8ビットのフィールド。完全なフレーム（0のFT）のためには、RTPペイロード内のAC-3フレームの数を示すために使用されます。フレームフラグメント（1のFT、2、または3）のために、現在のフレームを構成する多数の断片（したがって、パケット）を示すために使用されます。 NFは、同じフレームのフラグメントを含むパケットに対して同一でなければなりません。
Figure 4 shows the full AC-3 RTP payload format.
図4は、完全なAC-3 RTPペイロードフォーマットを示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| Payload | Frame | Frame | | Frame |
| Header | (1) | (2) | | (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 4. Full AC-3 RTP payload
図4.フルAC-3 RTPペイロード
When receiving AC-3 payloads with FT = 0 and more than a single frame (NF > 1), a receiver needs to use the "frmsizecod" field in the Synchronization Information (syncinfo) block in each AC-3 frame to determine the frame's length. That way a receiver can determine the boundary of the next frame. Note that the frame length may vary from frame to frame.
FT = 0と単一フレーム（NF> 1）、受信機が決定するために、各AC-3フレームに同期情報（syncinfo）ブロックに「frmsizecod」フィールドを使用する必要がある以上でAC-3ペイロードを受信した場合、フレームの長さ。その方法は、受信機は、次のフレームの境界を決定することができます。フレーム長がフレームからフレームに変化し得ることに留意されたいです。
The size of an AC-3 frame depends on the sample rate of the audio and the data rate used by the encoder (which are indicated in the "Synchronization Information" header in the AC-3 frame). The size of a frame, for a given sample rate and data rate, is specified in Table 5.18 ("Frame Size Code Table") of [ATSC]. This table shows that AC-3 frames range in size from a minimum of 128 bytes to a maximum of 3840 bytes. If the size of an AC-3 frame exceeds the MTU size, the frame SHOULD be fragmented at the RTP level. The fragmentation MAY be performed at any byte boundary in the frame. RTP packets containing fragments of the same AC-3 frame SHALL be sent in consecutive order, from first to last fragment. This enables a receiver to assemble the fragments in correct order.
AC-3フレームのサイズは、オーディオのサンプルレートと（AC-3フレームに「同期情報」ヘッダに示されている）エンコーダによって使用されるデータレートに依存します。フレームの大きさは、所与のサンプル・レート及びデータレートのために、[ATSC]の表5.18（「フレームサイズのコード表」）で指定されています。このテーブルは、AC-3フレームは、3840バイトの最大128バイトの最小の大きさの範囲であることを示しています。 AC-3フレームのサイズがMTUサイズを超える場合、フレームは、RTPレベルで断片化されるべきです。断片化は、フレーム内の任意のバイト境界で行うことができます。同じAC-3フレームの断片を含むRTPパケットは、最初から最後のフラグメントに、連続した順序で送付しなければなりません。これは、正しい順序で断片を組み立てるために受信機を可能にします。
When an AC-3 frame is fragmented, it MAY be fragmented such that at least the first 5/8ths of the frame data is in the first fragment. This provides greater resilience to packet loss. This initial portion of any frame is guaranteed to contain the data necessary to decode the first two blocks of the frame. Any frame fragments other than those containing the first 5/8ths of frame data are only decodable once the complete frame is received. The 5/8ths point of the frame is defined in Table 7.34 ("5/8_frame Size Table") of [ATSC].
AC-3フレームが断片化されている場合、そのようなデータは、最初のフラグメントであるフレームの少なくとも最初の5 / 8thsことが断片化されてもよいです。これは、パケット損失に大きな回復力を提供します。任意のフレームのこの最初の部分は、フレームの最初の二つのブロックを復号するために必要なデータを含むことが保証されます。フレームデータの最初の5 / 8thsを含有するもの以外の任意のフレームの断片は、完全なフレームが受信された後にのみ復号可能です。フレームの5 / 8ths点は[ATSC]の表7.34（ "5 / 8_frameサイズ表"）に定義されています。
This registration uses the template defined in [DRAFT-FREED] and follows RFC 3555 [RFC3555].
この登録は、[DRAFT-フリード]で定義されたテンプレートを使用して、RFC 3555 [RFC3555]を以下。
o Type name: audio
O型名：オーディオ
o Subtype name: ac3
Oサブタイプ名：AC3
o Required parameters:
必須パラメータO：
rate: The RTP timestamp clock rate that is equal to the audio sampling rate. Permitted rates are 32000, 44100, and 48000.
レート：オーディオサンプリングレートに等しいRTPタイムスタンプのクロックレート。許容レートは32000、44100、および48000です。
o Optional parameters:
オプションのパラメータO：
channels: From a sender, the maximum number of channels present in the AC3 stream. From a receiver, the maximum number of output channels the receiver will deliver. This MUST be a number between 1 and 6. The LFE (".1") channel MUST be counted as one channel. Note that the channel order used in AC-3 differs from the channel order scheme in [RFC3551]. The AC-3 channel order scheme can be found in Table 5.8 of [ATSC].
チャネル：送信者から、AC3ストリーム中に存在するチャネルの最大数。受信機から、出力チャネルの最大数は、受信機が提供されます。これは、LFE（」0.1" ）チャンネルが一つのチャンネルとしてカウントされなければならない1と6の間の数でなければなりません。 AC-3で使用されるチャネルの順序は[RFC3551]のチャネル順序方式とは異なることに留意されたいです。 AC-3チャンネルの順序スキームが[ATSC]の表5.8に見出すことができます。
ptime: See RFC 2327 [RFC2327].
PTIME：RFC 2327 [RFC2327]を参照してください。
maxptime: See RFC 3267 [RFC3267].
maxptime：RFC 3267 [RFC3267]を参照してください。
o Encoding considerations:
Oエンコーディングの考慮事項：
This media type is framed (see section 4.8 in [DRAFT-FREED])
and contains binary data.
o Security considerations:
Oセキュリティに関する注意事項：
See Section 6 of this document.
このドキュメントのセクション6を参照してください。
o Interoperability considerations:
Oの相互運用性の考慮事項：
None
無し
o Published specification:
O発行仕様：
This payload format specification and see [ATSC].
このペイロードフォーマット仕様および[ATSC]参照。
o Applications that use this media type:
このメディアタイプを使用するOアプリケーション：
Multichannel audio compression of audio and audio for video.
ビデオ用のオーディオやオーディオのマルチチャンネルオーディオ圧縮。
o Additional Information:
O追加情報：
Magic number(s):
The first two octets of an AC-3 frame are always the
synchronization word, which has the hex value 0x0B77.
o Person & email address to contact for further information:
詳細のために連絡するO人とEメールアドレス：
Brian Link <bdl@dolby.com>
IETF AVT working group.
o Intended Usage:
O使用目的：
COMMON
一般
o Restrictions on usage:
使用法のO制限：
This media type depends on RTP framing, and hence is only
defined for transfer via RTP [RFC3550]. Transport within other
framing protocols is not defined at this time.
Author/Change controller:
著者/変更コントローラ：
IETF Audio/Video Transport Working Group delegated from the
IESG.
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC2327], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing AC-3, the mapping is as follows:
MIMEメディアタイプの仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC2327]のフィールドに特定のマッピングを有します。 SDPは、AC-3を用いたセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The Media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The Media subtype ("ac3") goes in SDP "a=rtpmap" as the encoding name.
メディアサブタイプ（「AC3」）O SDPでエンコーディング名として「= rtpmap」になります。
o The required parameter "rate" also goes in "a=rtpmap" as the clock rate, optionally followed by the parameter "channel".
O必要なパラメータ「速度」はまた、必要に応じて、パラメータ「チャネル」に続くクロックレートとして「A = rtpmap」に進みます。
o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oオプションのパラメータ "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
An example of the SDP data for AC-3:
AC-3のSDPデータの例：
m=audio 49111 RTP/AVP 100
a=rtpmap:100 ac3/48000/6
Certain considerations are needed when SDP is used to perform offer/answer exchanges [RFC3264].
SDPは、オファー/アンサー交換[RFC3264]を実行するために使用されている場合、特定の考慮が必要とされています。
o The "rate" is a symmetric parameter, and the answer MUST use the same value or remove the payload type.
「レート」は対称パラメータであり、答えは同じ値を使用するか、ペイロードタイプを削除する必要があり、O。
o The "channels" parameter is declarative and indicates, for recvonly or sendrecv, the desired channel configuration to receive, and for sendonly, the intended channel configuration to transmit. All receivers are capable of receiving any of the defined channel configurations, and the parameter exchange might be used to help optimize the transmission to the number of channels the receiver requests. If the "channels" parameter is omitted, a default maximum value of 6 is implied.
「チャネル」パラメータoを宣言し、示し、recvonlyで又はSENDRECVため、受信したいチャンネルの構成、及びsendonlyのために、意図されたチャネル構成を送信します。すべての受信機は、定義されたチャネル構成のいずれかを受信することが可能であり、パラメータ交換チャネル受信要求の数への送信を最適化するために使用されるかもしれません。 「チャンネル」パラメータが省略されている場合は、6のデフォルトの最大値が暗示されます。
o The "ptime" and "maxptime" parameters are negotiated as defined for "ptime" in RFC 3264 [RFC3264].
RFC 3264 [RFC3264]に "PTIME" について定義した通りO "PTIME" および "maxptime" パラメータがネゴシエートされています。
The payload format described in this document is subject to the security considerations defined in the RTP specification [RFC3550] and in any applicable RTP profile (e.g., [RFC3551]). To protect the user's privacy and any copyrighted material, confidentiality protection would have to be applied. To also protect against modification by intermediate entities and ensure the authenticity of the stream, integrity protection and authentication would be required. Confidentiality, integrity protection, and authentication have to be provided by a mechanism external to this payload format, e.g., SRTP [RFC3711].
この文書に記載されたペイロードフォーマットは、RTP仕様[RFC3550]及び該当RTPプロファイル（例えば、[RFC3551]）で定義されたセキュリティ問題を受けます。ユーザーのプライバシーとあらゆる著作物を保護するために、機密保護が適用されなければなりません。また、中間エンティティによって変更から保護し、ストリームの信頼性を確保するために、完全性保護と認証が必要とされるであろう。機密性、完全性保護、および認証は、このペイロード形式、例えば、SRTP [RFC3711]に外部機構によって提供されなければなりません。
The AC-3 format is designed so that the validity of data frames can determined by decoders. A decoder that encounters a malformed frame discards the malformed data and conceals the errors in the audio output until a valid frame is detected and decoded. This is expected to prevent crashes and other abnormal decoder behavior in response to errors or attacks.
データフレームの有効性は、デコーダによって決定できるように、AC-3フォーマットが設計されています。不正な形式のフレームに遭遇したデコーダは、不正な形式のデータを廃棄し、有効なフレームが検出され、デコードされるまで、オーディオ出力のエラーを隠蔽します。これは、エラーや攻撃に応答して、クラッシュやその他の異常なデコーダの動作を防止することが期待されます。
The general congestion control considerations for transporting RTP data apply to AC-3 audio over RTP as well. See the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]).
RTPデータを転送するための一般的な輻輳制御の検討事項は、同様にRTPオーバーAC-3オーディオに適用されます。 RTP仕様[RFC3550]と該当RTPプロファイルを参照して（例えば、[RFC3551]）。
AC-3 encoders may use a range of bit rates to encode audio data, 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. Additionally, packing more frames in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced robustness against packet losses.
AC-3符号器は、オーディオデータを符号化するためにビットレートの範囲を使用することができるので、リアルタイムで符号化ビットレートを調整することによって、または異なるビットレートでエンコードされたコンテンツの複数のコピーを有することによって、ネットワーク帯域幅を適応させることが可能です。また、各RTPペイロードに複数のフレームをパッキング増加遅延を犠牲にして、IP / UDP / RTPヘッダから従ってオーバーヘッドを送信したパケットの数を削減し、パケット損失に対するロバスト性を低減することができます。
A new media subtype has been assigned for AC-3; see Section 5.1.
新しいメディアサブタイプは、AC-3用に割り当てられています。セクション5.1を参照してください。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月。
[ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC Standard: Digital Audio Compression (AC-3), Revision B," Doc A/52B, June 2005.
[ATSC]米国高度テレビジョンシステム委員会（ATSC）、 "ATSC規格：デジタルオーディオ圧縮（AC-3）、リビジョンB、" ドクA / 52B、2005年6月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[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：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[RFC3267] Sjoberg、J.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「リアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットと適応マルチレート（AMR）と適応マルチ用ストレージファイル形式-rate広帯域（AMR-WB）オーディオコーデック」、RFC 3267、2002年6月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555] Casner、S.とP. Hoschka、 "RTPペイロード形式のMIMEタイプ登録"、RFC 3555、2003年7月。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[RFC2736]ハンドリー、M.とC.パーキンス、 "RTPペイロードフォーマット仕様の作家のためのガイドライン"、BCP 36、RFC 2736、1999年12月。
[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プロフィール"、STD 65、RFC 3551、2003年7月。
[1994AC3] Todd, C., et al., "AC-3: Flexible Perceptual Coding for Audio Transmission and Storage," Preprint 3796, Presented at the 96th Convention of the Audio Engineering Society, May 1994.
[1994AC3]トッド、C.ら、「AC-3：オーディオ伝送およびストレージのための柔軟な知覚符号化、」オーディオ技術協会、1994年5月の第96回大会で発表予稿集3796、。
[1996AC3] Fielder, L., et al., "AC-2 and AC-3: Low-Complexity Transform-Based Audio Coding," Collected Papers on Digital Audio Bit-Rate Reduction, pp. 54-72, Audio Engineering Society, September 1996.
【1996AC3]フィールダー、L.ら、「AC-2、AC-3：低複雑変換ベースのオーディオ符号化、」デジタルオーディオビットレートの削減に関する論文集、54から72頁、オーディオエンジニアリングソサイエティ1996年9月。
[RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.ら、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004月。
[DRAFT-FREED] Freed, N. and Klensin, J., "Media Type Specifications and Registration Procedures", Work in Progress, April 2005.
[DRAFT-フリード]フリード、N.とKlensin、J.、 "メディアタイプの仕様と登録手順"、進歩、2005年4月の作業。
Authors' Addresses
著者のアドレス
Brian Link Dolby Laboratories 100 Potrero Ave San Francisco, CA 94103
ブライアン・リンクドルビーラボラトリーズ100ポトレロアベニューサンフランシスコ、CA 94103
Phone: +1 415 558 0200 EMail: bdl@dolby.com
電話：+1 415 558 0200 Eメール：bdl@dolby.com
Todd Hager Dolby Laboratories 100 Potrero Ave San Francisco, CA 94103
トッド・ヘイガードルビーラボラトリーズ100ポトレロアベニューサンフランシスコ、CA 94103
Phone: +1 415 558 0136 EMail: thh@dolby.com
電話：+1 415 558 0136 Eメール：thh@dolby.com
Jason Flaks Microsoft Corporation 1 Microsoft Way Redmond, WA 98052
ジェイソンは98052 OFマイクロソフト社1マイクロソフト道レドモンドを、Flaks
Phone: +1 425 722 2543 EMail: jasonfl@microsoft.com
電話：+1 425 722 2543 Eメール：jasonfl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。