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