Network Working Group B. Link
Request for Comments: 4598 Dolby Laboratories
Category: Standards Track July 2006
Real-time Transport Protocol (RTP)
Payload Format for Enhanced AC-3 (E-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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation.
この文書では、強化されたAC-3（E-AC-3）符号化された音声データを転送するためのリアルタイム転送プロトコル（RTP）ペイロード形式について説明します。 E-AC-3は、高品質、マルチチャンネルオーディオコーディングフォーマットであり、米国の高精細テレビ（HDTV）、DVD、ケーブルおよび衛星テレビジョンで使用されているAC-3オーディオコーディングフォーマットの拡張であり、他のメディア。 E-AC-3は、米国および世界的なデジタルテレビや高精細DVDフォーマットのオプションのオーディオフォーマットです。この文書で提示されるRTPペイロードフォーマットは、データの断片化のためのサポートを含みます。
Table of Contents
目次
1. Introduction ....................................................2
2. Overview of Enhanced-AC-3 .......................................3
2.1. E-AC-3 Bit Stream ..........................................5
2.1.1. Sync Frames and Audio Blocks ........................5
2.1.2. Programs and Substreams .............................6
2.1.3. Frame Sets ..........................................7
3. RTP E-AC-3 Header Fields ........................................7
4. RTP E-AC-3 Payload Format .......................................8
4.1. Payload Specific Header ....................................8
4.2. Fragmentation of E-AC-3 Frames .............................9
4.3. Concatenation of E-AC-3 Frames .............................9
4.4. Carriage of AC-3 Frames ...................................10
5. Types and Names ................................................10
5.1. Media Type Registration ...................................10
5.2. SDP Usage .................................................13
6. Security Considerations ........................................14
7. Congestion Control .............................................15
8. IANA Considerations ............................................15
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
The Enhanced AC-3 (E-AC-3) [ETSI] audio coding system is built on a foundation of AC-3. It is an enhancement and extension to AC-3, which is an existing audio coding standard commonly used for DVD, broadcast, cable, and satellite television content. E-AC-3 is designed to enable operation at both higher and lower data rates than AC-3, provide expanded channel configurations, and provide greater flexibility for carriage of multiple audio program elements. The relationship between E-AC-3 and AC-3 provides for low-loss, low-cost conversion between the two and makes E-AC-3 especially suitable in applications that require compatibility with the existing broadcast-reception and audio/video decoding infrastructure. Dolby Digital Plus is a branded version of Enhanced AC-3.
強化されたAC-3（E-AC-3）[ETSI]オーディオコーディングシステムは、AC-3の基礎の上に構築されています。これは、AC-3、一般DVD、放送、ケーブル、衛星テレビコンテンツに使用される既存のオーディオコーディング標準での拡張及び拡張です。 E-AC-3、AC-3より両方より高い及びより低いデータレートで動作を可能にする拡張チャネル構成を提供し、複数のオーディオプログラム要素のキャリッジのためのより大きな柔軟性を提供するように設計されています。 E-AC-3、AC-3との間の関係は、両者の低損失、低コストの変換を提供し、E-AC-3既存の放送受信とオーディオとの互換性を必要とする用途に特に適し/ビデオデコードを行いますインフラ。ドルビーデジタルプラスは、強化されたAC-3のブランドバージョンです。
E-AC-3 has been standardized within both the European Telecommunications Standards Institute (ETSI) and the Advanced Television Systems Committee (ATSC). It is an optional audio format for use in US (ATSC) and Digital Video Broadcasting (DVB) television transmission. It is also a required audio format for use in the High Definition (HD)-DVD optical-storage media format and included in the Blu-ray Disc format.
E-AC-3は、欧州電気通信標準化機構（ETSI）と高度テレビジョンシステム委員会（ATSC）の両方の中に標準化されています。これは、米国（ATSC）およびデジタルビデオ放送（DVB）テレビジョン伝送で使用するためのオプションのオーディオフォーマットです。また、高精細度（HD）-DVD光ストレージメディアフォーマットとBlu-ray Discフォーマットに含まで使用するために必要なオーディオフォーマットです。
There is a need to stream E-AC-3 content over IP networks. E-AC-3 is primarily used in audio-for-video applications, so RTP serves well as a transport solution with its mechanism for synchronizing streams. Applications for streaming E-AC-3 include Internet Protocol television (IPTV), video on demand, interactive features of next generation DVD formats, and transfer of movies across a home network.
IPネットワーク上でE-AC-3コンテンツをストリーミングする必要があります。 RTPストリームを同期させるためにその機構を備えた搬送液として十分機能するようにE-AC-3は、主に、オーディオ用のビデオアプリケーションで使用されています。 E-AC-3をストリーミングするためのアプリケーションは、インターネットプロトコルテレビ（IPTV）、ビデオオンデマンド、次世代DVDフォーマットのインタラクティブ機能、およびホームネットワークを介して動画の転送が含まれます。
Section 2 gives a brief overview of the E-AC-3 algorithm. Section 3 specifies values for fields in the RTP header, and Section 4 specifies the E-AC-3 payload format, itself. Section 5 discusses media types and Session Description Protocol (SDP) usage. Security considerations are covered in Section 6, congestion control in Section 7, and IANA considerations in Section 8.
第2節では、E-AC-3アルゴリズムの概要を示します。セクション3は、RTPヘッダ内のフィールドの値を指定し、セクション4は、それ自体、E-AC-3ペイロードのフォーマットを指定します。第5節では、メディアタイプとセッション記述プロトコル（SDP）の使用について説明します。セキュリティの考慮事項は、第8章では第6、第7における輻輳制御、およびIANA問題でカバーされています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Enhanced AC-3 (E-AC-3) is a frequency-domain perceptual audio coding system. Time blocks of an audio signal are converted from the time domain to the frequency domain by a transform (the Modified Discrete Cosine Transform (MDCT)) so that a model of the human auditory perceptual system can be applied. In this domain, quantization noise can be constrained to specific frequency regions. The perceptual model predicts in which frequency regions the auditory system will be least able to detect the quantization noise from data rate reduction. A more detailed technical description of E-AC-3 can be found in [2004AES].
強化AC-3（E-AC-3）は、周波数領域の知覚オーディオコーディングシステムです。オーディオ信号の時間ブロックは、によって時間ドメインから周波数ドメインに変換され、変換（修正離散コサイン変換（MDCT））人間の聴覚の知覚システムのモデルを適用することができます。このドメインでは、量子化雑音は、特定の周波数領域に制限することができます。知覚モデルは、周波数領域において聴覚システムは、データレートの減少から量子化雑音を検出する少なくともできます予測します。 E-AC-3のより詳細な技術的説明は[2004AES]に見出すことができます。
E-AC-3 is built upon a foundation of AC-3. More background on AC-3 can be found in the AC-3 specification [ETSI], a technical paper [1994AES], and the AC-3 RTP payload format [RFC4184]. The frame structure and meta-data of AC-3 are maintained. E-AC-3 content is not directly compatible with AC-3 decoders, but it can be converted to the AC-3 format to provide compatibility with existing decoders. Because AC-3 is the foundation of E-AC-3, conversion between the two formats can be done in a way that minimizes the degradations associated with tandem coding. In addition, the computational cost of the conversion is reduced compared to a full decode and re-encode.
E-AC-3は、AC-3の基礎の上に構築されています。 AC-3についての追加の背景は、AC-3仕様[ETSI]、テクニカルペーパー[1994AES]、及びAC-3 RTPペイロードフォーマット[RFC4184]に見出すことができます。 AC-3のフレーム構造およびメタデータが維持されます。 E-AC-3含量は、AC-3デコーダと直接互換性がないが、既存デコーダとの互換性を提供するために、AC-3フォーマットに変換することができます。 AC-3、E-AC-3の基盤であるため、二つのフォーマット間の変換は、タンデム符号化に関連付けられた劣化を最小限に抑える方法で行うことができます。加えて、変換の計算コストは、フルデコードおよび再エンコードに比べて低減されます。
E-AC-3 exploits psychoacoustic 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.
典型的なオーディオ信号に含まれる情報のかなりの割合を引き起こすE-AC-3悪用音響心理学の現象が聞こえないことにします。かなりのデータ削減は、オーディオストリームに含まれて聞こえない情報の除去を介して起こります。ソース符号化技術は、データ・レートを低下させるために使用されています。
Like most perceptual coders, E-AC-3 operates in the frequency domain. A 512-point MDCT 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 spectral components associated with them. Audibility is determined via a masking curve. Bits for mantissas are allocated from a global bit pool.
最も知覚的コーダーと同様に、E-AC-3は、周波数領域で動作します。 512ポイントMDCT変換256新たな周波数サンプルを提供し、50％のオーバーラップで撮影されています。周波数サンプルは、その後、指数と仮数に変換されます。指数は、差動符号化されています。仮数は、それらに関連するスペクトル成分の可聴性に応じてビットの変化数を割り当てられます。聴感マスキングカーブを経て決定されます。仮数のためのビットは、グローバルビットプールから割り振られます。
E-AC-3 adds new coding tools, such as a longer filter bank, vector quantization, and spectral extension, to provide greater data efficiency and to operate at lower data rates than AC-3. In the other direction, an expanded bit stream syntax and new frame constraints permit operation at higher data rates than AC-3. The E-AC-3 syntax also allows a larger number of audio channels in one bit stream. E-AC-3 operates at data rates from 32 kbps to 6.144 Mbps and at three sampling rates: 32 kHz, 44.1 kHz, and 48 kHz.
E-AC-3は、より高いデータ効率を提供し、AC-3より低いデータレートで動作するように、そのようなより長いフィルタバンク、ベクトル量子化、およびスペクトル拡張などの新しい符号化ツールを追加します。他の方向では、拡張ビットストリームのシンタックスと新しいフレーム制約がAC-3よりも高いデータレートでの動作を可能にします。 E-AC-3構文はまた、1つのビットストリームにおけるオーディオチャネルの多数を可能にします。 32 kHzの、44.1kHz、48kHzと：E-AC-3は、6.144 Mbpsの32 kbpsのデータレートで三のサンプリングレートで動作します。
E-AC-3 supports the carriage of multiple programs and the carriage of programs with more than a baseline of 5.1 audio channels. Both of these extensions beyond AC-3 are accomplished by time multiplexing additional data with baseline data. In the case of multiple programs, frames with data for the programs are interleaved. In the case of more than 5.1 channels, frames from substreams carrying the extra channels are interleaved with the independent substream that carries a 5.1-channel compatible mix. Both of these forms of multiplexing can occur in the same bit stream. In other words, mixing multiple programs, some or all with more than 5.1 channels, is permitted.
E-AC-3は、複数のプログラムのキャリッジと5.1オーディオチャンネルのベースラインよりも持つプログラムのキャリッジを支持しています。 AC-3を超えてこれらの拡張機能の両方がベースラインデータと時間多重化する付加的なデータによって達成されます。複数のプログラムの場合、プログラムのためのデータを有するフレームがインターリーブされます。以上5.1チャンネルの場合には、余分なチャネルを運ぶサブフレームから5.1チャンネル互換ミックスを運ぶ独立サブストリームとインターリーブされます。多重化のこれらの形態の両方が同一のビットストリームで起こり得ます。換言すれば、複数のプログラム、以上5.1チャンネルの一部又は全部を混合、許可されています。
Additional channel capacity is enabled by adding substreams to a program. One primary substream, called the "independent substream", is required for each program. This substream carries a self-contained mix of the audio, using a maximum of 5.1 channels, which makes its channel configuration compatible with AC-3. Then, additional, optional substreams are used in the program to carry additional channels. The data for each additional channel carries an indication of whether that channel provides data for an additional speaker location or replacement data for one of the speaker locations already defined by a previous substream. For example, one common 7.1-channel format uses three front channels and four surround channels. It is packaged with a primary substream, which contains a 5.1-channel downmix of the 7.1-channel content, using left, center, right, left surround, right surround, and low-frequency effects channels. One dependent substream supplies four channels: replacements for left surround and right surround, along with two additional surround channels (left back and right back).
追加のチャネル容量は、プログラムにサブを追加することで有効になっています。 「独立したサブ」と呼ばれる一つの主要なサブは、各プログラムに必要です。このサブストリームは、AC-3と互換性のチャネル構成を作る5.1チャンネルの最大値を用いて、音声の自己完結型のミックスを運びます。その後、追加、オプションのサブは、追加のチャネルを運ぶためのプログラムで使用されています。追加の各チャネルのデータは、そのチャネルが既に以前のサブによって定義されたスピーカーの位置のいずれかの付加的なスピーカ位置または交換データのためのデータを提供するかどうかの指示を運びます。例えば、1つの一般的な7.1チャンネルフォーマットは、3つのフロントチャンネルと4つのサラウンドチャンネルを使用します。これは、左、中央、右、左サラウンド、右サラウンド、及び低周波数効果チャネルを使用して、7.1チャンネルコンテンツの5.1チャンネルダウンミックスを含有する一次サブと共に包装されます。 （背中と右バック左）二つの追加サラウンドチャンネルと一緒に、左サラウンド、右サラウンドの代替：一つの従属サブは、4つのチャネルを提供します。
The specification for E-AC-3 [ETSI] requires that all E-AC-3 decoders be capable of decoding at least a baseline portion of any E-AC-3 bit stream, which consists of the first independent substream of the first program, and of ignoring the other elements of the bit stream. This baseline is limited to 5.1 channels, and a system is also able to convert to configurations with fewer channels for a presentation that matches its output capabilities, if needed. More capable decoders can optionally choose among and mix multiple programs, and also decode configurations with more channels than the baseline by decoding dependent substreams.
E-AC-3 [ETSI]の仕様は、すべてのE-AC-3デコーダは最初のプログラムの最初の独立したサブストリームから構成され、任意のE-AC-3ビットストリームの少なくともベースライン部分復号化することができることを必要と、ビットストリームの他の要素を無視します。このベースラインは、5.1チャンネルに制限されており、このシステムはまた、必要に応じて、その出力能力と一致して、プレゼンテーションのための少ないチャネルを有する構成に変換することができます。より多くの可能なデコーダは、任意の中から選択し、複数のプログラムを混合し、さらに従属サブストリームをデコードして、ベースラインよりも多くのチャネルを有する構成を復号することができます。
The basic organizational building block in an E-AC-3 bit stream is the sync frame (also called a frame in this document). A sync frame contains the data necessary to decode time domain audio samples for one or more channels over a time of one or more audio blocks, so a frame is an Application Data Unit (ADU). Each E-AC-3 frame contains a Sync Information (SI) field, a Bit Stream Information (BSI) field, an Audio Frame (AF) field, and up to six audio blocks (ABs). Each AB represents 256 Pulse Code Modulation (PCM) samples for each channel. The frame ends with an optional auxiliary data field (AUX) and an error correction field (CRC). Figure 1 shows the structure of an E-AC-3 frame, where N is the number of blocks in the frame.
E-AC-3ビットストリームにおける基本的な組織構築ブロックが同期フレームである（また、この文書に記載されているフレームと呼ばれます）。同期フレームはとてもフレームがアプリケーションデータユニット（ADU）は、1つまたは複数のオーディオブロックの時間をかけて1つまたは複数のチャネルの時間領域オーディオサンプルをデコードするために必要なデータを含みます。各E-AC-3フレームは、同期情報（SI）フィールド、ビットストリーム情報（BSI）フィールド、オーディオフレーム（AF）フィールド、6つのオーディオブロックまで（ABS）を含みます。各ABは、各チャネルのために256パルスコード変調（PCM）サンプルを表します。フレームは、オプションの補助データフィールド（AUX）と誤り訂正フィールド（CRC）で終わります。図1は、Nは、フレーム内のブロックの数であり、E-AC-3フレームの構造を示しています。
+---+---+---+---------+- ... -+---------+---+---+
|SI |BSI|AF | AB(0) | ... | AB(N) |AUX|CRC|
+---+---+---+---------+- ... -+---------+---+---+
Figure 1. E-AC-3 frame format with more than one block
複数のブロックを有する図1のE-AC-3フレームフォーマット
The SI field contains information needed to acquire and maintain codec synchronization. The BSI field contains parameters that describe the coded audio service. It carries an indication of the size of the frame in 16-bit words ('frmsiz', Section E.1.3 of [ETSI]) and an indication of the sampling rate ('fscod'). It also carries an indication of the number of blocks in the frame ('numblkscod'); permitted values are one, two, three, or six blocks. The AF field contains information about coding tools that applies to the entire frame. Each block has a duration of 256 samples, so a frame's duration is the corresponding multiple of 256 samples. The time duration of the frame is also dependent on the sampling rate, as shown in Table 1.
SIフィールドは、コーデックの同期を獲得し、維持するために必要な情報が含まれています。 BSIフィールドは、符号化されたオーディオサービスを記述するパラメータが含まれています。これは、16ビットワード内のフレームのサイズ（「frmsiz」のセクションE.1.3 [ETSI]）、サンプリングレート（「fscod」）の表示の指示を運びます。また、フレーム（「numblkscod」）内のブロックの数の表示を運びます。許容値は、1つ、2つ、3つ、または6つのブロックです。 AFフィールドは、フレーム全体に適用されるツールのコーディングに関する情報が含まれています。各ブロックは256個のサンプルの長さを持っているので、フレームの持続時間は、256個のサンプルの対応する複数あります。表1に示すように、フレームの持続時間は、また、サンプリングレートに依存しています。
Table 1. Time duration of E-AC-3 frame (number of blocks vs. sampling rate)
E-AC-3フレームの表1持続時間（サンプリングレート対ブロックの数）
+------------------+--------+-----------------+-----------------+
| blocks per frame | 32 kHz | 44.1 kHz | 48 kHz |
+------------------+--------+-----------------+-----------------+
| 1 | 8 ms | approx. 5.8 ms | approx. 5.3 ms |
| 2 | 16 ms | approx. 11.6 ms | approx. 10.7 ms |
| 3 | 24 ms | approx. 17.4 ms | 16 ms |
| 6 | 48 ms | approx. 34.8 ms | 32 ms |
+------------------+--------+-----------------+-----------------+
Each audio block contains header fields that indicate the use of various coding tools: block switching, dither, coupling, spectral extension, and exponent strategy. They also contain metadata, optionally used to enhance 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 format of audio blocks is described in detail in [ETSI].
ブロックスイッチング、ディザ、結合、スペクトル拡張、および指数戦略：各オーディオブロックは、様々な符号化ツールの使用を示すヘッダフィールドを含みます。彼らはまた、必要に応じて、ダイナミックレンジ制御として、再生を増強するために使用される、メタデータを含みます。最後に、指数及び音声データに仮数をデコードするために必要なビット割り当てデータ、および仮数自体が、含まれています。オーディオブロックのフォーマットは[ETSI]に詳細に記載されています。
An E-AC-3 bit stream is logically arranged into programs. A bit stream contains one or more programs, up to a maximum of eight. When multiple programs are present in a bit stream, the frames that constitute them are interleaved in time.
E-AC-3ビットストリームは、論理的にプログラムに配置されています。ビットストリームは、最大8つの最大の、1つまたは複数のプログラムが含まれています。複数のプログラムがビットストリーム中に存在する場合、それらを構成するフレームが時間的にインターリーブされます。
+----------+- -+----------+----------+- -+----------+-
|Program(1)| ... |Program(N)|Program(1)| ... |Program(N)| ...
| Frame 0 | | Frame 0 | Frame 1 | | Frame 1 |
+----------+- -+----------+----------+- -+----------+-
Figure 2. Interleaving of multiple programs in an E-AC-3 bit stream
E-AC-3ビットストリーム内の複数のプログラムの図2インターリーブ
Each program contains one independent substream and optionally contains up to eight dependent substreams. The independent substream carries a soundtrack of up to 5.1 channels, the multichannel format that matches the capabilities of AC-3, and can be meaningfully decoded and presented without any of the associated dependent substreams. The dependent substreams are used to provide alternate channel data that enable different channel configurations, for example, to increase the number of channels beyond 5.1. A frame of a dependent substream can be decoded by itself, but its content can only be meaningfully presented in conjunction with the corresponding independent substream. The type and identity of the substream to which a frame belongs can be determined from parameters in the frame's BSI (strmtyp and substreamid, in Section E.1.3.1 of [ETSI]).
各プログラムは、一つの独立したサブが含まれており、必要に応じて8つの依存サブまでを含みます。独立したサブは、最大5.1チャンネルのサウンドトラック、AC-3の機能と一致するマルチチャンネルフォーマットを運び、そして有意義に関連付けられた従属サブストリームの任意なく復号及び提示することができます。従属サブストリームは、5.1を超えてチャネルの数を増加させるために、例えば、異なるチャネル構成を有効に代替チャネルデータを提供するために使用されます。依存サブフレームは単独で復号することができるが、その含有量は、唯一の意味の対応する独立したサブストリームと関連して提示することができます。サブタイプと同一のフレームは、フレームのBSIのパラメータから決定することができる属する（セクションE.1.3.1に、strmtypとsubstreamid [ETSI]）。
When a program contains more than one substream, the frames belonging to those substreams are interleaved in time, and taken together, the frames of a program that correspond to the same time period are called a 'program set'. Figure 3 shows the interleaving of substreams for a single program.
プログラムが複数のサブストリームを含む場合、これらのサブストリームに属するフレームが時間的にインターリーブし、一緒になって、同じ期間に対応するプログラムのフレームが「プログラムセット」と呼ばれます。図3は、単一のプログラムのためのサブストリームのインターリーブを示します。
/ --------- program set for frame 0 ------- \
: :
+-------------+-------------+- -+-------------+-------------+-
| Program(1) | Program(1) | | Program(1) | Program(1) |
| Independent | Dependent | ... | Dependent | Independent | ...
| Substream | Substream(0)| | Substream(n)| Substream |
| Frame 0 | Frame 0 | | Frame 0 | Frame 1 |
+-------------+-------------+- -+-------------+-------------+-
Figure 3. Interleaving of multiple substreams in an E-AC-3 program
E-AC-3プログラム内の複数のサブの図3インターリーブ
A further logical organization of the E-AC-3 bit stream is applied to facilitate conversion of E-AC-3 bit streams to AC-3 bit streams. In this organization, the frames carrying six consecutive audio blocks are treated as a group, called a 'frame set', regardless of the number of frames needed to carry six audio blocks. This grouping extends across all programs and substreams that cover the time period of the six blocks. Since E-AC-3 frames may carry one, two, three, or six blocks, a frame set will consist of six, three, two, or one frames. AC-3 frames always carry six blocks, so the frame set provides framing synchronization between an E-AC-3 bit stream and an AC-3 bit stream. Metadata that indicates the alignment is carried in the first frame (which will be part of an independent substream) of each frame set in an E-AC-3 stream. This first frame can be identified by a parameter in the BSI field of the bit stream: the Converter Synchronization flag (convsync, in Section E.1.3.1.34 of [ETSI]) is set to true (1).
E-AC-3ビットストリームのさらに論理編成は、AC-3ビットストリームにE-AC-3ビットストリームの変換を容易にするために適用されます。この組織では、6つの連続した音声ブロックを運ぶフレームは、グループとして扱われかかわらず6つのオーディオブロックを運ぶために必要なフレームの数の、「フレームセット」と呼ばれます。このグループ化は、6つのブロックの期間をカバーするすべてのプログラムとサブ横切って延びています。 E-AC-3フレームは1つ、2つ、3つまたは6つのブロックを運ぶことができるので、フレームセットは、6つの三、2個、または1つのフレームで構成されます。フレームセットは、E-AC-3ビットストリームとAC-3ビットストリーム間の同期をフレーミング提供するようにAC-3フレームは常に、6つのブロックを運びます。アラインメントを示すメタデータは、E-AC-3ストリームに設定された各フレームの（独立したサブの一部となる）最初のフレームで運ばれます。この最初のフレームは、ビットストリームのBSIフィールドのパラメータによって識別することができる：（[ETSI]のセクションE.1.3.1.34に、convsync）コンバータ同期フラグがtrueに設定されている（1）。
The RTP header is defined in the RTP specification [RFC3550]. This section defines how a number of fields in the header are used.
RTPヘッダは、RTP仕様[RFC3550]で定義されています。このセクションでは、ヘッダー内のフィールドの数が使用される方法を定義します。
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 E-AC-3 frame or contains the final fragment of an E-AC-3 frame.
Oマーカ（M）ビット：Mビットは、RTPパケットのペイロードは、少なくとも1つの完全なE-AC-3フレームを含むか、E-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 E-AC-3 frame in the RTP packet. Packets containing fragments of the same frame MUST have the same timestamp. The timestamp of the first RTP packet sent SHOULD be selected at random; thereafter, it increases linearly according to the number of samples included in each frame. Note that the number of samples in a frame depends on the number of blocks in the frame, with 256 samples in each block. Also note that more than one frame might correspond to the same time period when multiple channel configurations or programs are present. If these frames occupy multiple packets, it is possible that the resulting packets will have the same timestamp value.
Oタイムスタンプ：RTPパケット内の最初のE-AC-3フレームのサンプリング瞬間に対応する32ビット・ワード。同じフレームの断片を含むパケットは、同じタイムスタンプを持たなければなりません。送信された最初のRTPパケットのタイムスタンプは、ランダムに選択されるべきです。その後、各フレームに含まれるサンプルの数に応じて直線的に増加します。フレーム内のサンプル数は、各ブロック内の256個のサンプルと、フレーム内のブロックの数に依存することに留意されたいです。また、複数のチャンネル構成、またはプログラムが存在する場合、複数のフレームが同じ時間に対応するかもしれないことに注意してください。これらのフレームは、複数のパケットを占有した場合、結果としてパケットが同じタイムスタンプ値を持つことも可能です。
This payload format is defined for E-AC-3, as defined in Annex E of [ETSI]. Note that E-AC-3 decoders are required to be capable of decoding AC-3 bit streams, so a receiver capable of receiving the E-AC-3 payload format defined in this document MUST also receive the payload format for AC-3 defined in [RFC4184].
付属書E [ETSI]で定義されるように、このペイロードフォーマットは、E-AC-3のために定義されています。 E-AC-3デコーダは、AC-3ビットストリームを復号することが可能なことが要求されるので、この文書で定義されたE-AC-3ペイロードフォーマットを受信できる受信機はまた、AC-3に定義のペイロードのフォーマットを受けなければならないことに注意してください[RFC4184]インチ
According to [RFC2736], RTP payload formats should contain an integral number of application data units (ADUs). The E-AC-3 frame corresponds to an ADU in the context of this payload format. Each RTP payload MUST start with the two-byte payload specific header followed by an integral number of complete E-AC-3 frames, or a single fragment of an E-AC-3 frame.
[RFC2736]によれば、RTPペイロードフォーマットは、アプリケーション・データ・ユニット（のADU）の整数を含むべきです。 E-AC-3フレームは、このペイロード形式の文脈でADUに相当します。各RTPペイロードは、完全なE-AC-3フレームの整数、またはE-AC-3フレームの単一のフラグメントに続く2バイトのペイロード固有のヘッダで始まる必要があります。
If an E-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.
E-AC-3フレームはネットワークのMTUを超えた場合、それは、RTPパケット内の送信のために断片化されるべきです。 4.2節では、フレームの断片を作成するためのガイドラインを提供します。
There is a two-octet Payload header at the beginning of each payload. Each E-AC-3 RTP payload MUST begin with the following Payload header.
各ペイロードの先頭に2オクテットペイロードヘッダがあります。各E-AC-3 RTPペイロードは、次のペイロードヘッダで開始しなければなりません。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F| NF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. E-AC-3 RTP Payload header
図4. E-AC-3 RTPペイロードヘッダ
o Must Be Zero (MBZ): 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 Frame Type (F): This one-bit field indicates the type of frame(s) present in the payload. It takes the following values: 0 - One or more complete frames. 1 - Fragment of frame. (Note that the M bit in the RTP header is set for the final fragment.)
Oフレームタイプ（F）：この1ビットのフィールドは、ペイロード内に存在するフレーム（複数可）のタイプを示します。一つ以上の完全なフレーム - 0：それは次の値を取ります。 1 - フレームのフラグメント。 （RTPヘッダ内のMビットは、最終的な断片のために設定されることに注意してください。）
o Number of frames/fragments (NF): An 8-bit field whose meaning depends on the Frame Type (F) in this payload. For complete frames (F of 0), it is used to indicate the number of E-AC-3 frames in the RTP payload. For frame fragments (F of 1), it is used to indicate the number of fragments (and therefore packets) that make up the current frame. NF MUST be identical for packets containing fragments of the same frame.
フレーム/断片（NF）のO番号：その意味は、このペイロードにフレームタイプ（F）に依存して8ビットのフィールド。完全なフレーム（0 F）の場合には、RTPペイロード内のE-AC-3フレームの数を示すために使用されます。フレームフラグメント（1 F）のために、現在のフレームを構成する断片（したがって、パケット）の数を示すために使用されます。 NFは、同じフレームのフラグメントを含むパケットに対して同一でなければなりません。
When receiving E-AC-3 payloads with F = 0 and more than a single frame (NF > 1), a receiver needs to use the "frmsiz" field in the BSI header in each E-AC-3 frame to determine the frame's length if the receiver needs to determine the boundary of the next frame. Note that the frame length varies from frame to frame in some circumstances.
フレーム者を決定するために、F = 0と単一フレーム（NF> 1）、受信機は、各E-AC-3フレームにBSIヘッダに「frmsiz」フィールドを使用する必要がある以上でE-AC-3ペイロードを受信した場合長さは受信機は、次のフレームの境界を決定する必要がある場合。フレームの長さは、いくつかの状況では、フレームからフレームへ変化することに留意されたいです。
The size of an E-AC-3 frame is signaled in the Frame Size (frmsiz) field in a frame's BSI header. The value of this field is one less than the number of 16-bit words in the frame. If the size of an E-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 E-AC-3 frame SHALL be sent in consecutive order, from first to last fragment. This enables a receiver to assemble the fragments in the correct order.
E-AC-3フレームのサイズは、フレームのBSIヘッダ内のフレームサイズ（frmsiz）フィールドでシグナリングされます。このフィールドの値は、フレーム内の16ビット・ワードの数より1つ少ないです。 E-AC-3フレームのサイズがMTUサイズを超える場合、フレームは、RTPレベルで断片化されるべきです。断片化は、フレーム内の任意のバイト境界で行うことができます。同じE-AC-3フレームの断片を含むRTPパケットは、最初から最後のフラグメントに、連続した順序で送付しなければなりません。これは、正しい順序で断片を組み立てる受信を可能にします。
There are cases where E-AC-3 frame sizes are smaller than the MTU size and it is advantageous to include multiple frames in a packet.
E-AC-3フレームのサイズがMTUサイズよりも小さく、パケット内の複数のフレームを含むことが有利である場合があります。
It is useful to take into account the logical arrangement of the bit stream into program sets and frame sets to constrain the effects of the loss of a packet. It is desirable for a complete program set or a complete frame set to be included in one packet. Also, it is undesirable for frames from more than one program set or frame set to be in the same packet, unless the sets are complete. In this way, the loss of a packet is kept from causing the contents of another packet to be unusable.
パケットの損失の影響を制限するためのプログラムセットとフレームセットに考慮されたビットストリームの論理的な構成を取ることに有用です。これは、完全なプログラムのセットまたは1つのパケットに含まれるように設定され、完全なフレームのために望ましいです。セットが完了しない限り、また、それは、同じパケットに設定複数のプログラムセットまたはフレームからフレームには望ましくありません。このように、パケットの損失が別のパケットの内容が使用不能であることが原因で維持されます。
Frames from more than one program set SHOULD NOT be included in the same packet unless all program sets in the packet are complete. Frames from more than one frame set SHOULD NOT be included in the same packet unless all frame sets in the packet are complete.
パケット内のすべてのプログラムのセットが完了しない限り、複数のプログラムセットのフレームは同じパケットに含まれるべきではありません。パケット内のすべてのフレームセットが完了している場合を除き、複数のフレームセットからフレームは同じパケットに含まれるべきではありません。
The E-AC-3 specification [ETSI] requires that E-AC-3 decoders be capable of decoding AC-3 frames. That specification also supports carriage of AC-3 frames in an E-AC-3 bit stream. Due to differences between E-AC-3 and AC-3 frames, there are restrictions placed on the use of AC-3 frames: they are only used for the independent substream of the first (or only) program in an E-AC-3 bit stream. Note that carriage of only E-AC-3 frames, only AC-3 frames, and a mixture of E-AC-3 and AC-3 frames are all legal configurations. It is legal to change among the configurations in a bit stream. The AC-3 frame format is described in [RFC4184] and specified in [ETSI].
E-AC-3仕様[ETSI]はE-AC-3デコーダはAC-3フレームを復号することが可能であることを必要とします。その仕様はまた、E-AC-3ビットストリーム中にAC-3フレームのキャリッジを支持しています。彼らは唯一のE-AC-の最初の（または唯一の）プログラムとは独立してサブのために使用される：によるE-AC-3、AC-3フレームとの間の差に、AC-3フレームの使用に配置制約があります3ビットストリーム。フレームは、すべての法的構成のみE-AC-3フレームのみAC-3フレーム、及びE-AC-3、AC-3の混合物のキャリッジに留意されたいです。ビットストリームのコンフィギュレーションの間で変更することが合法です。 AC-3フレームフォーマットは、[RFC4184]に記載の[ETSI]で指定されています。
This registration uses the template defined in [RFC4288] and follows [RFC3555].
この登録は[RFC4288]で定義されたテンプレートを使用して、[RFC3555]に従います。
To: ietf-types@iana.org Subject: Registration of media type audio/eac3
To：ietf-types@iana.org件名：メディアタイプのオーディオの登録/ eac3
Type name: audio
型名：オーディオ
Subtype name: eac3
サブタイプ名：eac3
Required parameter:
必要なパラメータ：
o rate: The RTP timestamp clock rate that is equal to the audio sampling rate. Permitted rates are 32000, 44100, and 48000.
Oレート：オーディオサンプリングレートに等しいRTPタイムスタンプのクロックレート。許容レートは32000、44100、および48000です。
Optional parameter:
オプションのパラメータ：
o bitStreamConfig: The configuration of programs and substreams in the bit stream, expressed as a sequence of ASCII characters. This parameter can serve two purposes. First, during the creation of a session, the bitStreamConfig parameter might be used to negotiate a match between the requirements of a bit stream and the capabilities of a receiver to avoid using network bandwidth for data that cannot be used. Second, it makes the configuration of the bit stream explicit to the receiver so that whenever a packet is lost, the receiver can identify which kind of frame(s) has been lost to aid error mitigation.
O bitStreamConfig：ビットストリーム内のプログラムとサブの構成は、ASCII文字のシーケンスとして表現しました。このパラメータは、2つの目的を果たすことができます。まず、セッションの作成中に、bitStreamConfigパラメータが使用できないデータのためのネットワーク帯域幅の使用を避けるために、ビットストリームの要件と受信機の能力との間の一致を交渉するために使用される可能性があります。パケットが失われたときはいつでも、受信機が誤り軽減を助けるために失われたフレーム（複数可）の種類を識別できるように、第2に、受信機に、ビットストリームの構成が明示させます。
The format for the value for this parameter is to represent each substream of the bit stream by a single character indicating its type, immediately followed by the number of audio channels resulting if a frame of that substream (plus any other required substreams) is decoded. Note that even though Low-Frequency Effects (LFE) channels are often described as "fractional" channels (e.g., the ".1" in 5.1), for this parameter, an LFE channel is counted as one (e.g., a 5.1-channel configuration is indicated as 6). The configuration of the bit stream MUST match the value of this parameter for the duration of the session.
このパラメータの値の形式は、直ちにそのサブ（および任意の他の必要なサブストリーム）のフレームが復号された場合、得られたオーディオチャンネルの数が続くそのタイプを示す単一文字によってビットストリームの各サブストリームを表すことです。低周波効果（LFE）チャネルは、しばしば、「分数」チャネル（5.1例えば、」.1" ）として記載されているにもかかわらずことに注意し、このパラメータに、LFEチャンネルは、1つ（例えば、5.1チャンネルとしてカウントされコンフィギュレーション）6として示されています。ビットストリームの構成は、セッションの間、このパラメータの値と一致しなければなりません。
Allowed values for the substream type are as follows:
次のようにサブタイプのための可能な値は以下のとおりです。
i - Independent substream. d - Dependent substream.
I - 独立したサブ。 D - 依存サブ。
The E-AC-3 specification [ETSI] defines which configurations of bit streams are legal, which constrains the values the bitStreamConfig parameter will take. Each program starts with, and contains exactly one, independent substream ('i'). Each independent substream is followed by between 0 and 8 dependent substreams ('d'), which belong to the same program. See Section 2.1.2 for more discussion of programs and substreams.
E-AC-3仕様[ETSI]はビットストリームの構成はbitStreamConfigパラメータが取る値を制約た、合法であるかを定義します。各プログラムはで始まり、そして正確に一つが含まれている、独立したサブ（「I」）。各独立したサブストリームは、同じプログラムに属し、0〜8依存サブ（「D」）が続きます。プログラムとサブのより多くの議論については、セクション2.1.2を参照してください。
For example, consider a bit stream containing two programs:
例えば、二つのプログラムを含むビットストリームを考慮してください。
* the first program with
*最初のプログラムで
+ a six-channel independent substream + a dependent substream containing the additional channels needed for eight channels + a second dependent substream containing the further channels needed for 14 channels
6チャンネルの独立したサブ+ 8チャンネル+ 14個のチャネルのために必要な更なるチャネルを含む第二の従属サブために必要な追加のチャネルを含む従属サブストリームを+
* along with a second program with
* 2番目のプログラムと一緒に
+ another six-channel independent substream + a dependent substream containing the additional channels needed for eight channels
+別の6チャンネルの独立したサブ+ 8つのチャンネルのために必要な追加のチャネルを含む依存サブ
Then the configuration of the bit stream is indicated as follows:
次のようにビットストリームの構成が示されています。
bitStreamConfig = i6d8d14i6d8
ビットストリームコンフィグ= i6d8d14i6d8
When the bitStreamConfig parameter is being used in an offer/answer exchange, zero (0) for the number of channels for a substream in an answer is used to indicate a substream that the answerer desires not to receive.
bitStreamConfigパラメータは、オファー/アンサー交換に使用されている場合、ゼロ（0）の答えでサブチャネルのための数の回答を受信しないことを望むサブを示すために使用されます。
Encoding considerations:
エンコードの考慮事項：
This media type is framed and contains binary data.
このメディアタイプは、フレームとバイナリデータが含まれています。
Security considerations:
セキュリティの考慮事項：
See Section 6 of RFC 4598.
RFC 4598のセクション6を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
To maintain interoperability with AC-3-capable end-points, in cases where negotiation is possible, an E-AC-3 end-point SHOULD declare itself also as AC-3 capable (i.e., supporting also "audio/ac3" as specified in RFC 4184 [RFC4184]). Note that all E-AC-3 end-points are required to be AC-3 capable.
指定されているAC-3対応のエンドポイントとの相互運用性を維持するために、交渉が可能である場合には、E-AC-3エンドポイントは、AC-3できる（すなわち、また支持「オーディオ/ AC3」としても自身を宣言する必要がありますRFC 4184に[RFC4184]）。すべてのE-AC-3のエンドポイントがAC-3できることが必要であることに留意されたいです。
Published specification:
公開された仕様：
RFC 4598 and ETSI TS 102.366 [ETSI].
RFC 4598およびETSI TS 102366 [ETSI]。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Multichannel audio compression of audio, and audio for video.
マルチチャンネルオーディオオーディオの圧縮、およびビデオのオーディオ。
Additional information:
追加情報：
Magic number(s): The first two octets of an E-AC-3 frame are always the synchronization word, which has the hex value 0x0B77.
マジックナンバー（S）：E-AC-3フレームの最初の2つのオクテットは、常に進値0x0B77を有する同期ワードです。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Brian Link <bdl@dolby.com> IETF AVT working group.
ブライアン・リンク<bdl@dolby.com> IETF AVTワーキンググループ。
Intended usage:
意図している用法：
COMMON
一般
Restrictions on usage:
使用に関する制限事項：
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.
このメディアタイプは、RTPフレーミングに依存し、したがってのみRTP [RFC3550]を介して転送するために定義されています。他のフレーミングプロトコル内の輸送は、この時点で定義されていません。
Author/Change controller:
著者/変更コントローラ：
IETF Audio/Video Transport Working Group delegated from the IESG.
IETFオーディオ/ビデオ輸送ワーキンググループがIESGから委任します。
The information carried in the 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 E-AC-3, the mapping is as follows:
メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC2327]のフィールドに特定のマッピングを有します。 SDPは、E-AC-3を用いたセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The Media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The Media subtype ("eac3") goes in SDP "a=rtpmap" as the encoding name.
メディアサブタイプ（「eac3」）O SDPでエンコーディング名として「= rtpmap」になります。
o The required parameter "rate" also goes in "a=rtpmap" as the clock rate. (The optional "channels" rtpmap encoding parameter is not used. Instead, the information is included in the optional parameter bitStreamConfig.)
O必要なパラメータ「速度」は、クロック・レートとして「A = rtpmap」になります。 （オプションの「チャネル」rtpmap符号化パラメータが使用されていない。その代わりに、情報は、オプションのパラメータbitStreamConfigに含まれています。）
o The optional parameter "bitStreamConfig" goes in the SDP "a=fmtp" attribute.
Oオプションのパラメータ「bitStreamConfigは、」SDP「=のfmtp」属性になります。
The following is an example of the SDP data for E-AC-3:
以下は、E-AC-3のSDPデータの一例です。
m=audio 49111 RTP/AVP 100
a=rtpmap:100 eac3/48000
a=fmtp:100 bitStreamConfig i6d8d14i6d8
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 the answerer removes the payload type.
「レート」は対称パラメータであり、答えは同じ値を使用しなければならないか、回答がペイロードタイプを削除し、O。
o The "bitStreamConfig" parameter is declarative and indicates, for sendonly, the intended arrangement of substreams in the bit stream, along with the channel configuration, to transmit, and for recvonly or sendrecv, the desired bit stream arrangement and channel configuration to receive. The format of the bitStreamConfig value in an answer MAY differ from the offer value by replacing the number of channels for any undesired substreams with '0'. It is valid to zero out dependent substreams containing undesired channel configurations and to zero out all the substreams of an undesired program. Then the sender MAY reoffer the stream in the receiver's preferred configuration if it is capable of providing that configuration. Note that all receivers are capable of receiving, and all decoders are capable of decoding, any of the legal bit stream configurations, so the parameter exchange is not needed for interoperability. The parameter exchange might be used to help optimize the transmission to the number of programs or channels the receiver requests.
「bitStreamConfig」パラメータoを受信する宣言及び送信するために、チャネル構成とともに、sendonlyのため、ビットストリームにおけるサブの意図された配置を示し、がrecvonly又はSENDRECVため、所望のビットストリームの配置およびチャネル構成です。回答でbitStreamConfig値のフォーマットは、「0」と望ましくないサブストリームのためのチャネルの数を置き換えることによってオファー値と異なっていてもよいです。望ましくないチャネル構成を含む従属サブをゼロにし、望ましくないプログラムのすべてのサブをゼロに有効です。それはその構成を提供することが可能である場合、送信者は受信者の好ましい構成では、ストリームをreofferかもしれません。すべての受信機が受信することが可能であり、すべてのデコーダが合法ビットストリーム構成のいずれか、復号化することが可能であるので、パラメータ交換が相互運用性のために必要とされないことに留意されたいです。パラメータ交換は、プログラムやチャンネルの受信要求の数への送信を最適化するために使用される可能性があります。
o Since an AC-3 bit stream is a special case of an E-AC-3 bit stream, it is permissible for an AC-3 bit stream to be carried in the E-AC-3 payload format. To ensure interoperability with receivers that support the AC-3 payload format but not the E-AC-3 payload format, a sender that desires to send an AC-3 bit stream in the E-AC-3 payload format SHOULD also offer the session in the AC-3 payload format by including payload types for both media subtypes: 'ac3' and 'eac3'.
AC-3ビットストリームは、E-AC-3ビットストリームの特別な場合であるので、AC-3ビットストリームは、E-AC-3ペイロード形式で搬送されるため、O、それが許容されます。 AC-3ペイロード形式ではなく、E-AC-3ペイロードフォーマットをサポートする受信機との相互運用性を確保するために、E-AC-3ペイロード形式でAC-3ビットストリームを送信することを望む送信者は、セッションを提供する必要があります「AC3」と「eac3」：両方のメディアサブタイプのためのペイロードタイプを含めることによってAC-3ペイロード形式です。
The payload format described in this document is subject to the security considerations defined in RTP [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 solved by a mechanism external to this payload format, for example, Secure Real-time Transport Protocol (SRTP) [RFC3711].
この文書に記載されたペイロードフォーマットはRTP [RFC3550]で定義されたセキュリティ上の考慮の対象と該当RTPプロファイルである（例えば、[RFC3551]）。ユーザーのプライバシーとあらゆる著作物を保護するために、機密保護が適用されなければなりません。また、中間エンティティによって変更から保護し、ストリームの信頼性を確保するために、完全性保護と認証が必要とされるであろう。機密性、完全性保護、および認証は、例えば、このペイロードフォーマットに外部機構によって解決されなければならない、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]。
The E-AC-3 format is designed so that the validity of data frames can be determined by decoders. The required decoder response to a malformed frame is to discard the malformed data and conceal 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.
データフレームの有効性は、デコーダによって決定することができるように、E-AC-3フォーマットが設計されています。不正な形式のフレームに必要なデコーダ応答が不正な形式のデータを廃棄し、有効なフレームが検出され、デコードされるまで、オーディオ出力のエラーを隠蔽することです。これは、エラーや攻撃に応答して、クラッシュやその他の異常なデコーダの動作を防止することが期待されます。
The general congestion control considerations for transporting RTP data apply to E-AC-3 audio over RTP as well; see RTP [RFC3550], and any applicable RTP profile (e.g., [RFC3551]).
RTPデータを転送するための一般的な輻輳制御の検討事項は、同様にRTPオーバーE-AC-3オーディオに適用されます。 RTP [RFC3550]、および該当RTPプロファイルを参照して（例えば、[RFC3551]）。
E-AC-3 is a variable bit rate coding system so it is possible to use a variety of techniques to adapt to network bandwidth.
E-AC-3は、ネットワーク帯域幅に適応するために様々な技術を使用することが可能であるので、可変ビットレート符号化方式です。
The IANA has registered a new media subtype for E-AC-3 (see Section 5).
IANAは、E-AC-3（セクション5を参照）のための新しいメディアサブタイプを登録しています。
[ETSI] ETSI, "Digital Audio Compression (AC-3, Enhanced AC-3) Standard", TS 102 366, February 2005.
[SO] ETSI、 "デジタルADSL Kompression（PM-V、PM-Enchansed O）標準"、CZ 102 366、Fevroari 2005。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for AC-3 Audio", RFC 4184, October 2005.
[RFC4184]リンク、B.、ヘイガー、T.、およびJ. Flaks、 "AC-3オーディオのためのRTPペイロードフォーマット"、RFC 4184、2005年10月。
[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年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[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月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[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）とのオファー/アンサーモデル"。
[2004AES] Fielder, L., Andersen, R., Crockett, B., Davidson, G., Davis, M., Turner, S., Vinton, M., and P. Williams, "Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System", Preprint 6196, Presented at the 117th Convention of the Audio Engineering Society, October 2004.
【2004AES]フィールダー、L.、アンダーセン、R.、クロケット、B.、ダビッドソン、G.、デイビス、M.、ターナー、S.、ヴィントン、M.、およびP.ウィリアムス、「ドルビーデジタルプラスの紹介オーディオ技術協会、2004年10月の第117回大会で発表され、「ドルビーデジタル符号化システムの強化、プレプリント6196、。
[1994AES] Todd, C., Davidson, G., Davis, M., Fielder, L., Link, B., and S. Vernon, "AC-3: Flexible Perceptual Coding for Audio Transmission and Storage", Preprint 3796, Presented at the 96th Convention of the Audio Engineering Society, May 1994.
【1994AES]トッド、C.、ダビッドソン、G.、デイビス、M.、フィールダー、L.、リンク、B.、およびS.バーノン、 "AC-3音声伝送およびストレージのための柔軟な知覚符号化"、プレプリント3796 、オーディオ技術協会、1994年5月の第96回大会で発表。
[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月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
Author's Address
著者のアドレス
Brian Link Dolby Laboratories 100 Potrero Ave. San Francisco, CA 94103 US
ブライアン・リンクドルビーラボラトリーズ100ポトレロアベニューサンフランシスコ、CA 94103米国
Phone: +1 415 558 0200 EMail: bdl@dolby.com
電話：+1 415 558 0200 Eメール：bdl@dolby.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。