[要約] RFC 4598は、E-AC-3オーディオのためのRTPペイロードフォーマットを定義しています。目的は、E-AC-3オーディオをリアルタイムで転送するための標準化と相互運用性の確保です。
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
強化されたAC-3（E-AC-3）オーディオ用のリアルタイムトランスポートプロトコル（RTP）ペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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の基礎の上に構築されています。これは、DVD、ブロードキャスト、ケーブル、衛星テレビコンテンツに一般的に使用される既存のオーディオコーディング標準であるAC-3の拡張と拡張です。E-AC-3は、AC-3よりも高いデータレートと低いデータレートの両方で操作を可能にし、拡張されたチャネル構成を提供し、複数のオーディオプログラム要素のキャリッジの柔軟性を高めるように設計されています。E-AC-3とAC-3の関係は、2つの間の低損失、低コストの変換を提供し、E-AC-3は、既存のブロードキャスト受信とオーディオ/ビデオデコードとの互換性を必要とするアプリケーションで特に適しています。インフラストラクチャー。Dolby Digital Plusは、Enhanced 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）とAdvanced Television Systems Committee（ATSC）の両方で標準化されています。これは、米国（ATSC）およびデジタルビデオブロードキャスト（DVB）テレビ送信で使用するためのオプションのオーディオ形式です。また、高解像度（HD）-DVD光ストレージメディア形式で使用するために必要なオーディオ形式であり、Blu-rayディスク形式に含まれています。
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コンテンツをストリーミングする必要があります。E-AC-3は主にAudio-for-Videoアプリケーションで使用されるため、RTPは、ストリームを同期するメカニズムを備えたトランスポートソリューションとして機能します。Streaming 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）の使用について説明します。セキュリティ上の考慮事項は、セクション6、セクション7の混雑制御、およびセクション8の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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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].
Enhanced 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の基礎であるため、2つの形式間の変換は、タンデムコーディングに関連する分解を最小限に抑える方法で実行できます。さらに、コンバージョンの計算コストは、完全なデコードと再エンコードと比較して削減されます。
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変換が50％のオーバーラップで採取され、256の新しい周波数サンプルを提供します。その後、周波数サンプルは指数およびマンティッサに変換されます。指数は差別的にエンコードされます。マンティサは、それらに関連するスペクトルコンポーネントの可聴性に応じて、さまざまな数のビットを割り当てられます。可聴性はマスキング曲線を介して決定されます。Mantissasのビットは、グローバルなビットプールから割り当てられています。
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つのビットストリームでより多くのオーディオチャネルが可能になります。E-AC-3は、32 kbpsから6.144 Mbpsのデータレート、32 kHz、44.1 kHz、および48 kHzの3つのサンプリングレートで動作します。
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).
プログラムにサブストリームを追加することにより、追加のチャネル容量が有効になります。「独立したサブストリーム」と呼ばれる1つの主要なサブストリームが、各プログラムに必要です。このサブストリームは、最大5.1チャネルを使用して、オーディオの自己完結型のミックスを搭載しており、チャネル構成をAC-3と互換性のあるものにします。次に、追加のオプションのサブストリームをプログラムで使用して、追加のチャネルを運ぶために使用されます。各追加チャネルのデータには、そのチャネルが以前のサブストリームによって既に定義されているスピーカーの場所のいずれかの追加のスピーカーの位置または交換データのデータを提供するかどうかを示しています。たとえば、1つの一般的な7.1チャンネル形式では、3つのフロントチャネルと4つのサラウンドチャネルを使用します。左、中央、右、左サラウンド、右サラウンド、および低周波効果チャネルを使用して、7.1チャネルコンテンツの5.1チャネルダウンミックスを含む一次サブストリームでパッケージ化されています。1つの依存したサブストリームは、4つのチャネルを供給します。左サラウンドと右サラウンドの交換、および2つの追加のサラウンドチャネル（左後部と右側）です。
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ビットストリームの基本的な組織ビルディングブロックは、同期フレームです（このドキュメントのフレームとも呼ばれます）。同期フレームには、1つ以上のオーディオブロックの時間にわたって1つ以上のチャネルの時間ドメインオーディオサンプルをデコードするために必要なデータが含まれているため、フレームはアプリケーションデータユニット（ADU）です。各E-AC-3フレームには、同期情報（SI）フィールド、ビットストリーム情報（BSI）フィールド、オーディオフレーム（AF）フィールド、最大6つのオーディオブロック（ABS）が含まれています。各ABは、各チャネルの256個のパルスコード変調（PCM）サンプルを表します。フレームは、オプションの補助データフィールド（AUX）とエラー修正フィールド（CRC）で終了します。図1は、e-ac-3フレームの構造を示しています。ここで、nはフレーム内のブロックの数です。
+---+---+---+---------+- ... -+---------+---+---+
|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」、[ETSI]のセクションE.1.3）、およびサンプリングレート（ '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)
表1. E-AC-3フレームの期間（ブロック数とサンプリングレート）
+------------------+--------+-----------------+-----------------+
| 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
図2. e-ac-3ビットストリームでの複数のプログラムのインターリーブ
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]).
各プログラムには、1つの独立したサブストリームが含まれており、オプションで最大8つの従属サブストリームが含まれています。独立したサブストリームには、AC-3の機能に一致するマルチチャネル形式である最大5.1チャネルのサウンドトラックがあり、関連する依存性のサブストリームなしで有意義にデコードおよび提示できます。従属サブストリームは、たとえば5.1を超えるチャネルの数を増やすために、異なるチャネル構成を可能にする代替チャネルデータを提供するために使用されます。従属サブストリームのフレームは単独でデコードできますが、そのコンテンツは、対応する独立したサブストリームと組み合わせてのみ有意義に表示できます。フレームが属するサブストリームのタイプとアイデンティティは、フレームのBSIのパラメーターから決定できます（[ETSI]のセクションE.1.3.1）。
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
図3. E-AC-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ビットストリームのE-AC-3ビットストリームのAC-3ビットストリームへの変換を容易にするために、E-AC-3ビットストリームのさらなる論理的な組織が適用されます。この組織では、6つの連続したオーディオブロックを搭載したフレームは、6つのオーディオブロックを運ぶために必要なフレームの数に関係なく、「フレームセット」と呼ばれるグループとして扱われます。このグループ化は、6つのブロックの期間をカバーするすべてのプログラムとサブストリームに拡張されます。E-AC-3フレームは1、2、3、または6ブロックを搭載する可能性があるため、フレームセットは6、3、2、または1つのフレームで構成されます。AC-3フレームには常に6つのブロックがあります。そのため、フレームセットは、E-AC-3ビットストリームとAC-3ビットストリームの間のフレーミング同期を提供します。アライメントを示すメタデータは、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ペイロードタイプの割り当ては、このドキュメントの範囲外です。これは、このペイロード形式が使用されるRTPプロファイルによって指定されているか、動的に帯域外に合図されます（例：SDPを使用）。
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ビットは1に設定されており、RTPパケットペイロードに少なくとも1つの完全なE-AC-3フレームが含まれているか、E-AC-3フレームの最終的なフラグメントが含まれていることを示します。
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].
このペイロード形式は、[ETSI]の付録Eで定義されているように、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ペイロードは、2バイトのペイロード固有のヘッダーから開始する必要があります。その後、完全な数の完全なE-AC-3フレーム、またはE-AC-3フレームの単一のフラグメントが必要です。
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つ以上の完全なフレーム。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.
o フレーム/フラグメント数（NF）：このペイロードのフレームタイプ（f）に意味が依存する8ビットフィールド。完全なフレーム（Fの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ペイロードを受信する場合、受信者は各e-ac-3フレームのBSIヘッダーの「frmsiz」フィールドを使用してフレームを決定する必要があります。レシーバーが次のフレームの境界を決定する必要がある場合。フレームの長さは、状況によってはフレームごとに異なることに注意してください。
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-3フレームとAC-3フレームの違いにより、AC-3フレームの使用には制限があります。それらは、E-AC-の最初の（または唯一の）プログラムの独立したサブストリームにのみ使用されます。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
宛先：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つの目的を果たすことができます。まず、セッションの作成中に、ビットストリームコンスミッジパラメーターを使用して、使用できないデータにネットワーク帯域幅を使用しないように、ビットストリームの要件と受信機の機能との一致を交渉するために使用できます。第二に、ビットストリームの構成を受信機に明示的にし、パケットが失われるたびに、エラー緩和を支援するためにどの種類のフレームが失われたかを識別できるようにします。
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 -Independent Substream。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'）から始まり、正確に1つ含まれています。それぞれの独立したサブストリームの後には、同じプログラムに属する0〜8の従属サブストリーム（ 'd'）が続きます。プログラムとサブストリームの詳細については、セクション2.1.2を参照してください。
For example, consider a bit stream containing two programs:
たとえば、2つのプログラムを含む少しストリームを検討してください。
* 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チャネルに必要なさらなるチャネルを含む2番目の従属サブストリーム
* 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
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の有能とも宣言する必要があります（つまり、指定された「Audio/AC3」もサポートしますRFC 4184 [RFC4184]）。すべてのE-AC-3エンドポイントは、AC-3対応である必要があることに注意してください。
Published specification:
公開された仕様：
RFC 4598 and ETSI TS 102.366 [ETSI].
RFC 4598およびETSI TS 102.366 [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.
マジック番号：E-AC-3フレームの最初の2オクテットは、常に同期単語であり、HEX値0x0B77です。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
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:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC2327]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPがE-AC-3を使用するセッションを指定するために使用される場合、マッピングは次のとおりです。
o The Media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The Media subtype ("eac3") goes in SDP "a=rtpmap" as the encoding name.
o メディアサブタイプ（ "EAC3"）は、エンコーディング名としてSDP "a = 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 "a = 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.
o 「BitStreamConfig」パラメーターは宣言的であり、センドンリーでは、ビットストリームのサブストリームの意図された配置、チャネル構成、送信、およびRecvonlyまたはSendRecvについて、受信する目的のビットストリーム配置とチャネル構成を示します。回答のBitStreamConfig値の形式は、望ましくないサブストリームのチャネルの数を「0」に置き換えることにより、オファー値とは異なる場合があります。これは、望ましくないチャネル構成を含む従属サブストリームをゼロアウトし、望ましくないプログラムのすべてのサブストリームをゼロにすることが有効です。その後、送信者は、その構成を提供できる場合、レシーバーの優先構成内のストリームを再現できます。すべての受信機は受信可能であり、すべてのデコーダーは法的ビットストリーム構成のいずれかでデコードできるため、相互運用性にパラメーター交換は必要ありません。パラメーター交換は、受信者要求のプログラムの数またはチャネルの数への送信を最適化するために使用される場合があります。
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'.
o AC-3ビットストリームはE-AC-3ビットストリームの特別なケースであるため、AC-3ビットストリームをE-AC-3ペイロード形式で運ぶことが許されます。E-AC-3ペイロード形式ではなくAC-3ペイロード形式をサポートする受信機との相互運用性を確保するために、E-AC-3ペイロード形式でAC-3ビットストリームを送信したい送信者もセッションを提供するはずですAC-3ペイロード形式では、メディアサブタイプ「AC3」と「EAC3」の両方にペイロードタイプを含めることにより。
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.
[ETSI] ETSI、「デジタルオーディオ圧縮（AC-3、強化されたAC-3）標準」、TS 102 366、2005年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Link、B.、Hager、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.、Frederick、R。、およびV. Jacobson、「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] Freed、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] Handley、M。and 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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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] Fielder、L.、Andersen、R.、Crockett、B.、Davidson、G.、Davis、M.、Turner、S.、Vinton、M。、およびP. Williams、 "Dolby Digital Plusの紹介、2004年10月、オーディオエンジニアリング協会の第117回大会で発表されたプリプリント6196、Dolby Digital Coding Systemの強化」。
[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] Todd、C.、Davidson、G.、Davis、M.、Fielder、L.、Link、B。、およびS. Vernon、「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] Handley、M。およびC. Perkins、「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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
Author's Address
著者の連絡先
Brian Link Dolby Laboratories 100 Potrero Ave. San Francisco, CA 94103 US
ブライアンリンクドルビーラボラトリーズ100ポトレロアベニューサンフランシスコ、カリフォルニア94103 US
Phone: +1 415 558 0200
EMail: bdl@dolby.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。