RFC4598 日本語訳
4598 Real-time Transport Protocol (RTP) Payload Format for EnhancedAC-3 (E-AC-3) Audio. B. Link. July 2006. (Format: TXT=39811 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Link Request for Comments: 4598 Dolby Laboratories Category: Standards Track July 2006
コメントを求めるワーキンググループB.リンク要求をネットワークでつないでください: 4598年のドルビー研究所カテゴリ: 標準化過程2006年7月
Real-time Transport Protocol (RTP)
Payload Format for Enhanced AC-3 (E-AC-3) Audio
高められたAC-3(電子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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは、Enhanced AC-3(電子AC-3)のコード化されたオーディオデータを輸送するためにレアル-時間Transportプロトコル(RTP)ペイロード形式について説明します。 電子AC-3は、高品質なマルチチャンネルオーディオ符号化形式であり、AC-3オーディオ符号化形式の拡大です。(それは、Television(HDTV)(DVD)が電報を打つ米国のHigh定義、衛星テレビ、および他のメディアに使用されます)。 電子AC-3は米国の、そして、世界的なデジタル・テレビとハイデフィニッションDVD形式のオプショナルオーディオ形式です。 本書では提示されるRTPペイロード形式はデータ断片化のサポートを含んでいます。
Link Standards Track [Page 1] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[1ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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
1. 序論…2 2. 高められたAC-3の概観…3 2.1. 電子AC-3ビットストリーム…5 2.1.1. フレームとオーディオブロックを同期させてください…5 2.1.2. プログラムとSubstreams…6 2.1.3. セットを縁どってください…7 3. RTP電子AC-3ヘッダーフィールド…7 4. RTP電子AC-3有効搭載量形式…8 4.1. 有効搭載量の特定のヘッダー…8 4.2. 電子AC-3フレームの断片化…9 4.3. 電子AC-3フレームの連結…9 4.4. AC-3フレームのキャリッジ…10 5. タイプと名前…10 5.1. メディアは登録をタイプします…10 5.2. SDP用法…13 6. セキュリティ問題…14 7. 混雑コントロール…15 8. IANA問題…15 9. 参照…15 9.1. 標準の参照…15 9.2. 有益な参照…16
1. Introduction
1. 序論
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.
Enhanced AC-3(電子AC-3)[ETSI]オーディオ記号化体系はAC-3の基礎で組立てられます。 それは、AC-3への増進と拡大です。(それは、DVD、放送、ケーブル、および衛星テレビ内容に一般的に使用される既存のオーディオコーディング標準です)。 電子AC-3は、複数のオーディオプログラムの要素のキャリッジにより高いものと同様にAC-3より低いデータ信号速度で操作を可能にして、拡張チャネル構成を供給して、より大きい柔軟性を供給するように設計されています。 E-AC-3とAC-3との関係で、低い損失、2つの間の安価の変換に備えて、存在との互換性を必要とするアプリケーションで特に適当なE-AC-3はレセプションとインフラストラクチャを解読するオーディオ/ビデオを放送します。 ドルビーデジタル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.
電子AC-3はヨーロッパのTelecommunications Standards Institute(ETSI)とAdvanced Television Systems Committee(ATSC)の両方の中で標準化されました。 それは米国(ATSC)とDigital Video Broadcasting(DVB)テレビのトランスミッションにおける使用のためのオプショナルオーディオ形式です。 また、それはHigh Definition(HD)DVD光記憶装置メディア形式であって含みにされるのにおけるブルーレイディスク形式で使用のための必要なオーディオ形式です。
Link Standards Track [Page 2] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[2ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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内容を流す必要があります。 電子AC-3がビデオ・アプリケーションのためのオーディオで主として使用されるので、メカニズムがある連動する輸送対策が流れるとき、RTPはよく役立ちます。ストリーミングの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はメディアタイプとSession記述プロトコル(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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Overview of Enhanced-AC-3
2. 高められたAC-3の概観
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(電子AC-3)は周波数領域の知覚のオーディオ記号化体系です。 変換(Modified Discrete Cosine Transform(MDCT))で音声信号の時間ブロックは、人間の聴力知覚のシステムのモデルを適用できるように時間領域から周波数領域まで変換されます。 このドメインでは、特定の頻度領域に量子化雑音を抑制できます。 知覚のモデルは、データ信号速度減少から聴覚系がどの頻度領域で量子化雑音を最も検出できないかを予測します。 [2004AES]でE-AC-3の、より詳細な専門的説明を見つけることができます。
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.
電子AC-3はAC-3の基礎で築き上げられます。 AC-3仕様[ETSI]、専門紙[1994AES]、およびAC-3 RTPペイロード形式[RFC4184]でAC-3に関する、より多くのバックグラウンドを見つけることができます。 AC-3に関する枠組構造とメタデータは維持されます。 電子AC-3内容は直接AC-3デコーダと互換性がありませんが、既存のデコーダを互換性に提供するためにAC-3形式にそれを変換できます。 AC-3がE-AC-3の基礎であるので、2つの形式の間で2人乗り自転車コード化に関連している転落を最小にする方法で変換できます。 完全が解読するaと再エンコードと比べて、さらに、変換のコンピュータのコストは削減されます。
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.
電子AC-3は典型的な音声信号に含まれた情報の重要な部分が聞こえないことを引き起こす心理音響の現象を利用します。 かなりのデータ整理がオーディオストリームで含まれた聞こえない情報の取り外しで起こります。 ソースコーディング技法は、データ信号速度を減少させるのにさらに使用されます。
Link Standards Track [Page 3] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[3ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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は周波数領域で作動します。 256個の新しい頻度のサンプルを提供して、50%のオーバラップで512ポイントのMDCT変換を取ります。 そして、頻度のサンプルは解説者と仮数に変換されます。 解説者は特異的にコード化されます。 それらに関連しているスペクトル成分の聴力に依存する異なった数のビットを仮数に割り当てます。 聴力はマスキングカーブで決定しています。 ビットは、グローバルなビットから仮数を割り当てるので、水たまりになります。
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.
電子AC-3は、より大きいデータ効率を提供して、AC-3より低いデータ信号速度で作動するためにさらに長いフィルタ・バンクや、ベクトル量子化や、スペクトル拡大などの新しいコーディング・ツールを加えます。 もう片方の方向に、拡張ビットストリーム構文と新しいフレーム規制はAC-3より高いデータ信号速度で操作を可能にします。 また、E-AC-3構文は1つのビットストリームの、より多くの音声チャンネルを許容します。 電子AC-3は32キロビット毎秒からの6.144Mbpsへのデータ信号速度において3つの標本抽出率で作動します: 32kHz、44.1kHz、および48kHz
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.
電子AC-3は5.1の音声チャンネルの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つの第一の「副-流れ」が各プログラムに必要です。 この「副-流れ」はチャネル構成をAC-3と互換性があるようにする最大5.1個のチャンネルを使用するオーディオの自己の含まれたミックスを運びます。 そして、追加していて、任意の「副-流れ」は、追加チャンネルを運ぶのにプログラムで使用されます。 それぞれの追加チャンネルへのデータはそのチャンネルがスピーカー位置の1つに関する位置か交換データが前の「副-流れ」で既に定義した追加スピーカーにデータを提供するかどうかしるしを運びます。 例えば、1つの一般的な7.1チャンネルの形式が3個の前部チャンネルを使用します、そして、4はチャンネルを囲んでいます。 それは左と、センターと、右と、左の取り囲むもの、正しい取り囲むもの、および長波効果を使用する「副-流れ」(7.1チャンネルの内容の5.1チャンネルのdownmixを含む)が向ける予備選挙でパッケージされます。 依存する「副-流れ」が4を供給する人は以下を精神を集中させます。 左との交換は、2の追加取り囲むものと共にチャンネル(レフトバックと正しい後部)を囲んでいて、まさしく、囲んでいます。
Link Standards Track [Page 4] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[4ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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個のチャンネルに制限されます、そして、また、システムは出力能力に合っているプレゼンテーションのための、より少ないチャンネルで構成に変えることができます、必要であるなら。 よりできるデコーダは、複数のプログラムを中で任意に選んで、混ぜることができます、そして、また、依存する「副-流れ」を解読することによって、基線より多くのチャンネルで構成を解読してください。
2.1. E-AC-3 Bit Stream
2.1. 電子AC-3ビットストリーム
2.1.1. Sync Frames and Audio Blocks
2.1.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つ以上のオーディオブロック以上の時間にわたって時間領域オーディオのサンプルを解読するのに必要なデータを含んでいるので、フレームはApplication Data Unit(ADU)です。 それぞれのE-AC-3フレームはSync情報(SI)分野、Bit Stream情報(BSI)分野、Audio Frame(AF)分野、および最大6つのオーディオブロック(ABs)を含んでいます。 各ABは各チャンネルのために256パルスコードの変調(PCM)のサンプルを表します。 フレームは任意の補助のデータ・フィールド(AUX)とエラー修正分野(CRC)で終わります。 図1はE-AC-3フレームの構造を示しています。(そこでは、Nがフレームのブロックの数です)。
+---+---+---+---------+- ... -+---------+---+---+
|SI |BSI|AF | AB(0) | ... | AB(N) |AUX|CRC|
+---+---+---+---------+- ... -+---------+---+---+
+---+---+---+---------+- ... -+---------+---+---+ |SI|BSI|AF| AB(0)| ... | AB(N)|補助|CRC| +---+---+---+---------+- ... -+---------+---+---+
Figure 1. E-AC-3 frame format with more than one block
図1。 1ブロック以上がある電子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個のサンプルの対応する倍数です。 また、フレームの時間持続時間もTable1に示されるように標本抽出率に依存しています。
Link Standards Track [Page 5] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[5ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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 | +------------------+--------+-----------------+-----------------+
+------------------+--------+-----------------+-----------------+ | 1フレームあたりのブロック| 32kHz| 44.1kHz| 48kHz| +------------------+--------+-----------------+-----------------+ | 1 | 8 ms| およそ5.8ms| およそ5.3ms| | 2 | 16 ms| およそ11.6ms| およそ10.7ms| | 3 | 24 ms| およそ17.4ms| 16 ms| | 6 | 48 ms| およそ34.8ms| 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]で詳細に説明されます。
2.1.2. Programs and Substreams
2.1.2. プログラムとSubstreams
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ビットストリームはプログラムに論理的にアレンジされます。少し、流れは1つ以上のプログラムを含んでいます、最大8まで。 複数のプログラムがいつ現在かは少し流れて、それらを構成するフレームは時間内に、はさみ込まれます。
+----------+- -+----------+----------+- -+----------+-
|Program(1)| ... |Program(N)|Program(1)| ... |Program(N)| ...
| Frame 0 | | Frame 0 | Frame 1 | | Frame 1 |
+----------+- -+----------+----------+- -+----------+-
+----------+- -+----------+----------+- -+----------+- |プログラム(1)| ... |プログラム(N)|プログラム(1)| ... |プログラム(N)| ... | フレーム0| | フレーム0| フレーム1| | フレーム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まで含んでいます。関連依存する「副-流れ」のどれかなしで独立している「副-流れ」を最大5.1個のチャンネルのサウンドトラック、AC-3の能力に合っているマルチチャンネル形式を運んで、意味深長に解読して、寄贈できます。例えば5.1を超えてチャンネルの数を増加させるように異なったチャネル構成を可能にする交代チャネルデータを提供するのに依存する「副-流れ」を使用します。 それ自体で依存する「副-流れ」のフレームを解読できますが、意味深長に対応する独立している「副-流れ」に関連して内容を提示できるだけです。 フレームが属する「副-流れ」のタイプとアイデンティティはフレームのBSI([ETSI]のセクションE.1.3.1のstrmtypとsubstreamid)のパラメタから決定できます。
Link Standards Track [Page 6] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[6ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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.
プログラムが1つ以上の「副-流れ」を含むとき、それらの「副-流れ」に属すフレームを、時間内にはさみ込んで、一緒に取って、同じ期間に対応するプログラムのフレームを'プログラムセット'と呼びます。 図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 |
+-------------+-------------+- -+-------------+-------------+-
/ --------- プログラムはフレーム0にセットしました。------- \ : : +-------------+-------------+- -+-------------+-------------+- | プログラム(1)| プログラム(1)| | プログラム(1)| プログラム(1)| | 無党派| 扶養家族| ... | 扶養家族| 無党派| ... | Substream| Substream(0)| | Substream(n)| Substream| | フレーム0| フレーム0| | フレーム0| フレーム1| +-------------+-------------+- -+-------------+-------------+-
Figure 3. Interleaving of multiple substreams in an E-AC-3 program
図3。 E-AC-3プログラムにおける、複数の「副-流れ」のインターリービング
2.1.3. Frame Sets
2.1.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ビットストリームに容易にするために適用されます。'フレームセット'は、この組織では、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分野のパラメタでこの最初のフレームを特定できます: Converter Synchronizationが弛む、(セクションE.1.3のconvsync、.1、.34、[ETSI)は本当の(1)に設定されます。
3. RTP E-AC-3 Header Fields
3. RTP電子AC-3ヘッダーフィールド
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 有効搭載量タイプ(太平洋標準時の): このドキュメントの範囲の外にこのパケット・フォーマットのためのRTPペイロードタイプの課題があります。 それはこのペイロード形式がバンドの外(例えば、SDPを使用する)で使用されるか、またはダイナミックに合図されるRTPプロフィールによって指定されます。
Link Standards Track [Page 7] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[7ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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)は噛み付きました: 1つにMビットが、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パケットに関するタイムスタンプはSHOULDを送りました。無作為に選択されてください。 その後、各フレームにサンプルの数に従った直線的を含んでいて、それは増加します。 256個のサンプルが各ブロックにある状態で、フレームのサンプルの数をフレームのブロックの数に依存することに注意してください。 また、1個以上のフレームが複数のチャネル構成かプログラムが存在しているのと同じ期間に対応するかもしれないことに注意してください。 これらのフレームが複数のパケットを占領するなら、結果として起こるパケットには同じタイムスタンプ値があるのは、可能です。
4. RTP E-AC-3 Payload Format
4. RTP電子AC-3有効搭載量形式
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-AC-3のために[ETSI]のAnnex Eで定義されるように定義されます。 また、本書では定義されたE-AC-3ペイロード書式を受けることができる受信機が[RFC4184]で定義されたAC-3のためにペイロード書式を受けなければならないように、E-AC-3デコーダがAC-3ビットストリームを解読できるように必要であることに注意してください。
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ペイロード形式は整数のアプリケーションデータ単位(ADUs)を含むべきです。 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を超えて、それはSHOULDです。RTPパケットの中のトランスミッションのために、断片化されます。 セクション4.2はフレーム断片を作成するためのガイドラインを提供します。
4.1. Payload Specific Header
4.1. 有効搭載量の特定のヘッダー
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ペイロードは以下の有効搭載量ヘッダーと共に始まらなければなりません。
Link Standards Track [Page 8] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[8ページ]RFC4598RTP有効搭載量形式をリンクしてください。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F| NF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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): ビットは値へのセットがゼロとSHALLであったならMBZ SHALLをマークしました。受信機で、無視されます。 ビットは今後の拡大のために予約されます。
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)の数: 意味がこのペイロードのFrame Type(F)による8ビットの分野。 完全なフレーム(0のF)に関しては、それは、RTPペイロードのE-AC-3フレームの数を示すのに使用されます。 フレーム断片(1のF)において、それは、現在のフレームを作る断片(そして、したがって、パケット)の数を示すのに使用されます。 NF MUST、同じフレームの断片を含むパケットにおいて、同じであってください。
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"分野を使用する必要があります。 フレームによってフレームの長さがいくつかの事情において異なることに注意してください。
4.2. Fragmentation of E-AC-3 Frames
4.2. 電子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ヘッダーのFrame Size(frmsiz)分野で合図されます。 この分野の値はフレームの16ビットの単語の数よりそれほど1です。 E-AC-3フレームのサイズはMTUサイズ、フレームSHOULDを超えています。RTPレベルでは、断片化されます。 断片化はフレームのどんなバイト境界でも実行されるかもしれません。 連続したオーダーで同じE-AC-3フレームSHALLの断片を含むRTPパケットを送って、最初から最後まで、断片化してください。 これは、受信機が正しいオーダーで断片を組み立てるのを可能にします。
4.3. Concatenation of E-AC-3 Frames
4.3. 電子AC-3フレームの連結
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サイズよりわずかであり、パケットの複数のフレームを含んでいるのが有利であるところにあります。
Link Standards Track [Page 9] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[9ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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つのパケットに含まれているのは、望ましいです。 また、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.
含まれていて、パケットのすべてのプログラムセットが完全であるというわけではないなら、1つ以上のプログラムからのフレームは同じパケットにSHOULD NOTを設定します。 含まれていて、パケットのすべてのフレームセットが完全であるというわけではないなら、1個以上のフレームからのフレームは同じパケットにSHOULD NOTを設定します。
4.4. Carriage of AC-3 Frames
4.4. AC-3フレームのキャリッジ
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]で指定されます。
5. Types and Names
5. タイプと名前
5.1. Media Type Registration
5.1. メディアは登録をタイプします。
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 Subject: メディアタイプオーディオ/eac3の登録
Type name: audio
型名: オーディオ
Subtype name: eac3
Subtypeは以下を命名します。 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です。
Link Standards Track [Page 10] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[10ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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.
このパラメタのための値のための形式はその「副-流れ」(いかなる他のも「副-流れ」を必要とした)のフレームが解読されるなら結果として生じる音声チャンネルの数がすぐにあとに続いたタイプを示す単独のキャラクタでビットストリームの各「副-流れ」を表すことです。 「Low-頻度Effects(LFE)チャンネルがしばしば「断片的な」チャンネルとして記述されていますが、それに注意してください、(例えば、」 5.1における0.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パラメタが取る値を抑制するどれ。 各プログラムは、ちょうど1、独立している「副-流れ」('i')を始めて、含んでいます。 0と8の依存するsubstreams ('d'の間で独立している「副-流れ」のあとに続くそれぞれ)、同じプログラムに属す。 プログラムと「副-流れ」の、より多くの議論に関してセクション2.1.2を見てください。
For example, consider a bit stream containing two programs:
例えば、2つのプログラムを含む流れを少し考えてください:
* the first program with
* 1番目はプログラムを作ります。
+ 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チャンネルの独立している「副-流れ」は+ さらなるチャンネルを含む依存する「副-流れ」が14にチャンネルを必要とした1秒あたり8個のチャンネルに必要である追加チャンネルを含む依存する「副-流れ」です。
Link Standards Track [Page 11] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[11ページ]RFC4598RTP有効搭載量形式をリンクしてください。
* along with a second program with
* 2分の1はプログラムを作ります。
+ 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
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)は、全くanswererが受け取らないことを望んでいる「副-流れ」を示すのに使用されません。
Encoding considerations:
問題をコード化します:
This media type is framed and contains binary data.
このメディアタイプは、縁どられて、2進のデータを含んでいます。
Security considerations:
セキュリティ問題:
See Section 6 of RFC 4598.
RFC4598のセクション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.
交渉が可能であるケース、E-AC-3エンドポイントにおけるAC-3できるエンドポイントがある相互運用性がSHOULDであることを支持するために、AC-3としてもそれ自体ができると宣言してください。(すなわち、また、「RFC4184[RFC4184)の指定されるとしてのオーディオ/ac3"」を支持すること。 すべてのE-AC-3エンドポイントができるAC-3になるのに必要であることに注意してください。
Published specification:
広められた仕様:
RFC 4598 and ETSI TS 102.366 [ETSI].
RFC4598とETSI t102.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.
マジックナンバー(s): いつもE-AC-3フレームの最初の2つの八重奏が同期単語です。(その単語には、十六進法価値の0x0B77があります)。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Brian Link <bdl@dolby.com> IETF AVT working group.
ブライアン Link <bdl@dolby.com 、gt;、IETF AVTワーキンググループ。
Link Standards Track [Page 12] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[12ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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.
IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
5.2. SDP Usage
5.2. SDP用法
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:
仕様が特定のマッピングを持っているメディアタイプで運ばれた情報はSessionで記述プロトコル(SDP)[RFC2327]をさばきます。(それは、RTPセッションについて説明するのに一般的に使用されます)。 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.
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
オーディオの49111RTP/AVP100m=a=rtpmap: 100eac3/48000 a=fmtp: 100bitStreamConfig 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 「レート」は左右対称のパラメタです、そして、答えが同じ値を使用しなければならない、さもなければ、answererはペイロードタイプを外します。
Link Standards Track [Page 13] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[13ページ]RFC4598RTP有効搭載量形式をリンクしてください。
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"パラメタは、叙述的であり、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'.
o AC-3ビットストリームがE-AC-3ビットストリームの特別なケースであるので、AC-3ビットストリームがE-AC-3ペイロード形式で運ばれるのは、許されています。 また、E-AC-3ペイロード形式ではなく、AC-3ペイロード形式を支持する受信機、AC-3ビットストリームを送ることを望んでいる送付者と共に相互運用性を確実にするために、E-AC-3ペイロード形式SHOULDは両方のためのペイロードタイプを含んでいるのによるAC-3ペイロード形式におけるセッションにメディア血液型亜型を提供します: 'ac3'と'eac3'。
6. Security Considerations
6. セキュリティ問題
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])を受けることがあります。 ユーザのプライバシーとどんな著作権で保護されたもの、秘密性保護も保護するのは適用されていなければならないでしょう。 また、中間的実体で変更から守って、流れ、保全保護、および認証の信憑性を確実にするのが必要でしょう。 このペイロード形式への外部のメカニズム、例えば、Secureレアル-時間Transportプロトコル(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形式は、データフレームの正当性がデコーダで決定できるように、設計されています。 奇形のフレームへの必要なデコーダ応答は、有効なフレームが検出されて、解読されるまで、奇形のデータを捨てて、オーディオ出力における誤りを隠すことです。 これが誤りか攻撃に対応してクラッシュと他の異常なデコーダの振舞いを防ぐと予想されます。
Link Standards Track [Page 14] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[14ページ]RFC4598RTP有効搭載量形式をリンクしてください。
7. Congestion Control
7. 輻輳制御
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.
電子AC-3が可変ビット伝送速度記号化体系であるので、ネットワーク回線容量に順応するのにさまざまなテクニックを使用するのは可能です。
8. IANA Considerations
8. IANA問題
The IANA has registered a new media subtype for E-AC-3 (see Section 5).
IANAはE-AC-3のためにニューメディア「副-タイプ」を登録しました(セクション5を見てください)。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[ETSI] ETSI, "Digital Audio Compression (AC-3, Enhanced AC-3)
Standard", TS 102 366, February 2005.
[ETSI]ETSI、「デジタル・オーディオ圧縮(AC-3、高められたAC-3)規格」、t102 366、2005年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for
AC-3 Audio", RFC 4184, October 2005.
B.とヘーガー、T.とJ.対空砲火、「AC-3オーディオのためのRTP有効搭載量形式」RFC4184、[RFC4184]はリンクして、10月は2005です。
[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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、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の種類登録」、RFC3555、2003年7月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2327] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Link Standards Track [Page 15] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[15ページ]RFC4598RTP有効搭載量形式をリンクしてください。
9.2. Informative References
9.2. 有益な参照
[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.
野手(L.とアンダーセンとR.とクロケットとB.とディヴィッドソンとG.とデイヴィスとM.とターナーとS.とビントン、M.とP.ウィリアムズ、「ドルビーデジタルプラスへの序論、ドルビーデジタル記号化体系への増進」前印刷6196)がオーディオ技術学会(2004年10月)の第117コンベンションに提示した[2004AES。]
[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:」 「音声通信のためのフレキシブルな知覚のコード化と格納」はオーディオ技術学会の第96コンベンションに提示された3796を前印刷します、1994年5月。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December
1999.
[RFC2736]ハンドレー、M.とC.パーキンス、「RTP有効搭載量書式仕様の作家へのガイドライン」BCP36、1999年12月のRFC2736。
[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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Author's Address
作者のアドレス
Brian Link Dolby Laboratories 100 Potrero Ave. San Francisco, CA 94103 US
ブライアンリンクドルビー研究所100Potrero Ave。 サンフランシスコ、カリフォルニア94103米国
Phone: +1 415 558 0200 EMail: bdl@dolby.com
以下に電話をしてください。 +1 0200年の415 558メール: bdl@dolby.com
Link Standards Track [Page 16] RFC 4598 RTP Payload Format for E-AC-3-Audio July 2006
2006年7月に電子AC-3のオーディオのために標準化過程[16ページ]RFC4598RTP有効搭載量形式をリンクしてください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Link Standards Track [Page 17]
リンク標準化過程[17ページ]
一覧
スポンサーリンク
