RFC4352 日本語訳
4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband(AMR-WB+) Audio Codec. J. Sjoberg, M. Westerlund, A. Lakaniemi, S.Wenger. January 2006. (Format: TXT=91297 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Sjoberg
Request for Comments: 4352 M. Westerlund
Category: Standards Track Ericsson
A. Lakaniemi
S. Wenger
Nokia
January 2006
コメントを求めるワーキンググループJ.シェーベリの要求をネットワークでつないでください: 4352年のM.Westerlundカテゴリ: 標準化過程エリクソンA.Lakaniemi S.ウェンガーノキア2006年1月
RTP Payload Format for the
Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec
拡張適応型のマルチレート広帯域(AMR-WB+)オーディオコーデックのための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 specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification.
このドキュメントはExtended Adaptive Multi-レートWideband(AMR-WB+)のためのTransportプロトコル(RTP)ペイロード形式が音声信号をコード化したレアル-時代に指定します。 AMR-WB+コーデックはAMR-WBスピーチコーデックのオーディオ拡大です。それは高品質な音楽とスピーチを支持するように設計されたAMR-WBフレームタイプと多くの新しいフレームタイプを包含します。 AMR-WB+のためのメディアタイプ登録はこの仕様に含まれています。
Sjoberg, et al. Standards Track [Page 1] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[1ページ]RFC4352RTP有効搭載量形式
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Glossary ...................................................4
2.2. Terminology ................................................4
3. Background of AMR-WB+ and Design Principles .....................4
3.1. The AMR-WB+ Audio Codec ....................................4
3.2. Multi-rate Encoding and Rate Adaptation ....................8
3.3. Voice Activity Detection and Discontinuous Transmission ....8
3.4. Support for Multi-Channel Session ..........................8
3.5. Unequal Bit-Error Detection and Protection .................9
3.6. Robustness against Packet Loss .............................9
3.6.1. Use of Forward Error Correction (FEC) ...............9
3.6.2. Use of Frame Interleaving ..........................10
3.7. AMR-WB+ Audio over IP Scenarios ...........................11
3.8. Out-of-Band Signaling .....................................11
4. RTP Payload Format for AMR-WB+ .................................12
4.1. RTP Header Usage ..........................................13
4.2. Payload Structure .........................................14
4.3. Payload Definitions .......................................14
4.3.1. Payload Header .....................................14
4.3.2. The Payload Table of Contents ......................15
4.3.3. Audio Data .........................................20
4.3.4. Methods for Forming the Payload ....................21
4.3.5. Payload Examples ...................................21
4.4. Interleaving Considerations ...............................24
4.5. Implementation Considerations .............................25
4.5.1. ISF Recovery in Case of Packet Loss ................26
4.5.2. Decoding Validation ................................28
5. Congestion Control .............................................28
6. Security Considerations ........................................28
6.1. Confidentiality ...........................................29
6.2. Authentication and Integrity ..............................29
7. Payload Format Parameters ......................................29
7.1. Media Type Registration ...................................30
7.2. Mapping Media Type Parameters into SDP ....................32
7.2.1. Offer-Answer Model Considerations ..................32
7.2.2. Examples ...........................................34
8. IANA Considerations ............................................34
9. Contributors ...................................................34
10. Acknowledgements ..............................................34
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................35
1. 序論…3 2. 定義…4 2.1. 用語集…4 2.2. 用語…4 3. AMR-WB+と設計原理のバックグラウンド…4 3.1. AMR-WB+オーディオコーデック…4 3.2. マルチレートコード化とレート適合…8 3.3. アクティビティ検出と不連続なトランスミッションを声に出してください…8 3.4. マルチチャンネルセッションのために、支持します。8 3.5. 不平等なビット誤り検出と保護…9 3.6. パケット損失に対する丈夫さ…9 3.6.1. 前進型誤信号訂正(FEC)の使用…9 3.6.2. フレームインターリービングの使用…10 3.7. IPシナリオの上のAMR-WB+オーディオ…11 3.8. バンドで出ているシグナリング…11 4. AMR-WB+のためのRTP有効搭載量形式…12 4.1. RTPヘッダー用法…13 4.2. 有効搭載量構造…14 4.3. 有効搭載量定義…14 4.3.1. 有効搭載量ヘッダー…14 4.3.2. 有効搭載量目次…15 4.3.3. オーディオデータ…20 4.3.4. 有効搭載量を形成するための方法…21 4.3.5. 有効搭載量の例…21 4.4. インターリービング問題…24 4.5. 実現問題…25 4.5.1. パケット損失の場合のISF回復…26 4.5.2. 合法化を解読します…28 5. 混雑コントロール…28 6. セキュリティ問題…28 6.1. 秘密性…29 6.2. 認証と保全…29 7. 有効搭載量形式パラメタ…29 7.1. メディアは登録をタイプします…30 7.2. マッピングメディアはSDPにパラメタをタイプします…32 7.2.1. 申し出答えモデル問題…32 7.2.2. 例…34 8. IANA問題…34 9. 貢献者…34 10. 承認…34 11. 参照…35 11.1. 標準の参照…35 11.2. 有益な参照…35
Sjoberg, et al. Standards Track [Page 2] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[2ページ]RFC4352RTP有効搭載量形式
1. Introduction
1. 序論
This document specifies the payload format for packetization of Extended Adaptive Multi-Rate Wideband (AMR-WB+) [1] encoded audio signals into the Real-time Transport Protocol (RTP) [3]. The payload format supports the transmission of mono or stereo audio, aggregating multiple frames per payload, and mechanisms enhancing the robustness of the packet stream against packet loss.
このドキュメントはレアル-時間Transportプロトコル(RTP)[3]へのExtended Adaptive Multi-レートWideband(AMR-WB+)の[1]のコード化された音声信号のpacketizationにペイロード形式を指定します。 ペイロード形式はモノタイプかステレオオーディオのトランスミッションを支持します、複数の1ペイロードあたりのフレーム、およびパケット損失に対してパケットの流れの丈夫さを高めるメカニズムに集めて。
The AMR-WB+ codec is an extension of the Adaptive Multi-Rate Wideband (AMR-WB) speech codec. New features include extended audio bandwidth to enable high quality for non-speech signals (e.g., music), native support for stereophonic audio, and the option to operate on, and switch between, several internal sampling frequencies (ISFs). The primary usage scenario for AMR-WB+ is the transport over IP. Therefore, interworking with other transport networks, as discussed for AMR-WB in [7], is not a major concern and hence not addressed in this memo.
AMR-WB+コーデックはAdaptive Multi-レートWideband(AMR-WB)スピーチコーデックの拡大です。新機能は、いくつかの内部のサンプリング周波数(ISFs)の間で非スピーチ信号(例えば、音楽)のための高い品質、ステレオのオーディオのネイティブのサポート、およびオプションが作動するのを可能にして、切り替わるように拡張オーディオ帯域幅を含んでいます。 AMR-WB+のための第一の用法シナリオはIPの上の輸送です。 したがって、[7]のAMR-WBのために議論するように他の輸送でネットワークを織り込むのは、関心であってしたがって、このメモに記述されなかった少佐ではありません。
The expected key application for AMR-WB+ is streaming. To make the packetization process on a streaming server as efficient as possible, an octet-aligned payload format is desirable. Therefore, a bandwidth-efficient mode (as defined for AMR-WB in [7]) is not specified herein; the bandwidth savings of the bandwidth-efficient mode would be very small anyway, since all extension frame types are octet aligned.
AMR-WB+の予想された主要なアプリケーションはストリーミングです。 ストリーミングサーバのpacketizationの過程をできるだけ効率的にするように、八重奏で並べられたペイロード形式は望ましいです。 したがって、帯域幅効率的なモード、(AMR-WBのために中で定義されるように、[7])はここに指定されません。 帯域幅効率的なモードの帯域幅貯蓄は、すべての拡大フレームタイプが並べられた八重奏であるので、とにかく非常にわずかでしょう。
The stereo encoding capability of AMR-WB+ renders the support for multi-channel transport at RTP payload format level, as specified for AMR-WB [7], obsolete. Therefore, this feature is not included in this memo.
+がAMR-WB[7]に指定されて、時代遅れとしてRTPペイロード形式レベルでマルチチャンネル輸送のサポートをするAMR-WBのステレオコード化能力。 したがって、この特徴はこのメモに含まれていません。
This specification does not include a definition of a file format for AMR-WB+. Instead, it refers to the ISO-based 3GP file format [14], which supports AMR-WB+ and provides all functionality required. The 3GP format also supports storage of AMR, AMR-WB, and many other multi-media formats, thereby allowing synchronized playback.
この仕様はAMR-WB+のためのファイル形式の定義を含んでいません。代わりに、それはISOベースの3GPファイル形式[14]について言及します。(それは、AMR-WB+を支持して、機能性が必要としたすべてを提供します)。 また、3GP形式はAMR、AMR-WB、および他の多くのマルチメディア形式の格納を支持して、その結果、連動している再生を許容します。
The rest of the document is organized as follows: Background information on the AMR-WB+ codec, and design principles, can be found in Section 3. The payload format itself is specified in Section 4. Sections 5 and 6 discuss congestion control and security considerations, respectively. In Section 7, a media type registration is provided.
ドキュメントの残りは以下の通り組織化されます: セクション3でAMR-WB+コーデック、および設計原理に関する基礎的な情報を見つけることができます。 ペイロード形式自体はセクション4で指定されます。 セクション5と6はそれぞれ輻輳制御とセキュリティ問題について論じます。 セクション7、登録が提供されるメディアタイプで。
Sjoberg, et al. Standards Track [Page 3] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[3ページ]RFC4352RTP有効搭載量形式
2. Definitions
2. 定義
2.1. Glossary
2.1. 用語集
3GPP - Third Generation Partnership Project
AMR - Adaptive Multi-Rate (Codec)
AMR-WB - Adaptive Multi-Rate Wideband (Codec)
AMR-WB+ - Extended Adaptive Multi-Rate Wideband (Codec)
CN - Comfort Noise
DTX - Discontinuous Transmission
FEC - Forward Error Correction
FT - Frame Type
ISF - Internal Sampling Frequency
SCR - Source-Controlled Rate Operation
SID - Silence Indicator (the frames containing only CN
parameters)
TFI - Transport Frame Index
TS - Timestamp
VAD - Voice Activity Detection
UED - Unequal Error Detection
UEP - Unequal Error Protection
3GPP--第三世代パートナーシッププロジェクトAMR--適応型のマルチレート(コーデック)AMR-WB--+--拡張適応型のマルチレート広帯域(コーデック)CN--安らぎ雑音DTX(不連続なトランスミッションFEC)がエラー修正フィートを送る適応型のマルチレート広帯域(コーデック)AMR-WB--フレームタイプ; ISF--内部のSampling Frequency SCR--ソースによって制御されたRate Operation SID--沈黙Indicator(CNパラメタだけを含むフレーム)TFI--輸送Frame Index TS--タイムスタンプVAD--声のActivity Detection UED--不平等なError Detection UEP--不平等なError Protection
2.2. Terminology
2.2. 用語
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 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. Background of AMR-WB+ and Design Principles
3. AMR-WB+と設計原理のバックグラウンド
The Extended Adaptive Multi-Rate Wideband (AMR-WB+) [1] audio codec is designed to compress speech and audio signals at low bit-rate and good quality. The codec is specified by the Third Generation Partnership Project (3GPP). The primary target applications are 1) the packet-switched streaming service (PSS) [13], 2) multimedia messaging service (MMS) [18], and 3) multimedia broadcast and multicast service (MBMS) [19]. However, due to its flexibility and robustness, AMR-WB+ is also well suited for streaming services in other highly varying transport environments, for example, the Internet.
Extended Adaptive Multi-レートWideband(AMR-WB+)[1]オーディオコーデックは、低ビット伝送速度で湿布スピーチと音声信号に設計されていて良質です。 コーデックはThird Generation Partnership Project(3GPP)によって指定されます。 第一の目標アプリケーションはパケットで切り換えられたストリーミングが修理する1(PSS)です)。 [13]、サービス(MMS)を通信させる2つの)マルチメディア 3の)[18]、マルチメディア放送、およびマルチキャストサービス(MBMS) [19]. しかしながら、また、柔軟性と丈夫さ、AMR-WBのため、+は他の非常に異なった輸送環境、例えば、インターネットでのストリーミングのサービスによく合っています。
3.1. The AMR-WB+ Audio Codec
3.1. AMR-WB+オーディオコーデック
3GPP originally developed the AMR-WB+ audio codec for streaming and messaging services in Global System for Mobile communications (GSM) and third generation (3G) cellular systems. The codec is designed as an audio extension of the AMR-WB speech codec. The extension adds new functionality to the codec in order to provide high audio quality
3GPPは、元々、モバイルコミュニケーション(GSM)と第三世代(3G)セルラ方式のためにGlobal Systemでサービスを流して、通信させるためにAMR-WB+オーディオコーデックを開発しました。コーデックはAMR-WBスピーチコーデックのオーディオ拡大として設計されています。拡大は、高いオーディオ音質を提供するために新しい機能性をコーデックに加えます。
Sjoberg, et al. Standards Track [Page 4] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[4ページ]RFC4352RTP有効搭載量形式
for a wide range of signals including music. Stereophonic operation has also been added. A new, high-efficiency hybrid stereo coding algorithm enables stereo operation at bit-rates as low as 6.2 kbit/s.
音楽を含むさまざまな信号のために。 また、ステレオの操作は加えられます。 新しくて、高い効率のハイブリッドステレオコード化アルゴリズムはビット伝送速度で6.2kbit/sと同じくらい低くステレオ操作を可能にします。
The AMR-WB+ codec includes the nine frame types specified for AMR-WB, extended by new bit-rates ranging from 5.2 to 48 kbit/s. The AMR-WB frame types can employ only a 16000 Hz sampling frequency and operate only on monophonic signals. The newly introduced extension frame types, however, can operate at a number of internal sampling frequencies (ISFs), both in mono and stereo. Please see Table 24 in [1] for details. The output sampling frequency of the decoder is limited to 8, 16, 24, 32, or 48 kHz.
AMR-WB+コーデックは5.2〜48kbit/sから変化する新しいビット伝送速度によって広げられたAMR-WBに指定された9つのフレームタイプを含んでいます。 AMR-WBフレームタイプは、16000Hzのサンプリング周波数だけを使って、モノラル信号だけを作動させることができます。 しかしながら、新たに導入された拡大フレームタイプは多くの内部のサンプリング周波数(ISFs)で働くことができます、モノタイプとステレオで。 詳細のための[1]でTable24を見てください。 デコーダの出力サンプリング周波数は8kHzか16kHzか24kHzか32kHzか48kHzに制限されます。
An overview of the AMR-WB+ encoding operations is provided as follows. The encoder receives the audio sampled at, for example, 48 kHz. The encoding process starts with pre-processing and resampling to the user-selected ISF. The encoding is performed on equally sized super-frames. Each super-frame corresponds to 2048 samples per channel, at the ISF. The codec carries out a number of encoding decisions for each super-frame, thereby choosing between different encoding algorithms and block lengths, so as to achieve a fidelity- optimized encoding adapted to the signal characteristics of the source. The stereo encoding (if used) executes separately from the monophonic core encoding, thus enabling the selection of different combinations of core and stereo encoding rates. The resulting encoded audio is produced in four transport frames of equal length. Each transport frame corresponds to 512 samples at the ISF and is individually usable by the decoder, provided that its position in the super-frame structure is known.
以下の通りAMR-WB+コード化作業の概観を提供します。 エンコーダは例えば、48kHzで抽出されたオーディオを受けます。 コード化の過程はユーザによって選択されたISFに前処理とリサンプリングから始まります。 コード化は等しく大きさで分けられた超フレームに実行されます。 それぞれの超フレームはISFで1チャンネルあたり2048個のサンプルに対応しています。 コーデックはそれぞれの超フレームのための決定をコード化して、その結果、異なったコード化アルゴリズムとブロック長を選ぶ数を行います、最適化されたコード化がソースの信号の特性に適合させた信義を達成するために。 ステレオコード化(使用されるなら)は別々に単旋律のコアからコード化を実行します、その結果、レートをコード化するコアとステレオの異なった組み合わせの品揃えを可能にします。 結果として起こるコード化されたオーディオは等しい長さの4個の輸送フレームで生産されます。 それぞれの輸送フレームは、ISFの512個のサンプルに対応している、デコーダで個別に使用可能です、超枠組構造の位置が知られていれば。
The codec supports 13 different ISFs, ranging from 12.8 to 38.4 kHz, as described by Table 24 of [1]. The high number of ISFs allows a trade-off between the audio bandwidth and the target bit-rate. As encoding is performed on 2048 samples at the ISF, the duration of a super-frame and the effective bit-rate of the frame type in use varies.
[1]のTable24によって説明されるように12.8〜38.4kHzに及んで、コーデックは13異なったISFsを支持します。 ISFsの大きい数はオーディオ帯域幅と目標ビット伝送速度の間のトレードオフを許容します。 コード化がISFの2048個のサンプルに実行されるとき、超フレームの持続時間と使用中であるフレームタイプの有効なビット伝送速度は異なります。
The ISF of 25600 Hz has a super-frame duration of 80 ms. This is the 'nominal' value used to describe the encoding bit-rates henceforth. Assuming this normalization, the ISF selection results in bit-rate variations from 1/2 up to 3/2 of the nominal bit-rate.
25600HzのISFには、80原稿の超フレーム持続時間があります。Thisは今後はコード化ビット伝送速度について説明するのに使用される'名目上'の値です。 ISF選択は1/2上からの3/2の名目上のビット伝送速度へのビット伝送速度変化をもたらして、この正常化を仮定します。
The encoding for the extension modes is performed as one monophonic core encoding and one stereo encoding. The core encoding is executed by splitting the monophonic signal into a lower and a higher frequency band. The lower band is encoded employing either algebraic code excited linear prediction (ACELP) or transform coded excitation (TCX). This selection can be made once per transport frame, but must
拡大モードのためのコード化は1つ単旋律のコアコード化と1のステレオコード化として実行されます。 コアコード化は、モノラル信号を下側の周波数帯と、より高い周波数帯に分けることによって、実行されます。 下側のバンドは、直線的な予測(ACELP)か変換が励振(TCX)をコード化したのに興奮している代数的なコードを使うことでコード化されます。 しかし、輸送フレーム、必須に一度この選択をすることができます。
Sjoberg, et al. Standards Track [Page 5] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[5ページ]RFC4352RTP有効搭載量形式
obey certain limitations of legal combinations within the super- frame. The higher band is encoded using a low-rate parametric bandwidth extension approach.
超フレームの中に法的な組み合わせのある制限に従ってください。 より高いバンドは、低率パラメトリック帯域幅拡大アプローチを使用することでコード化されます。
The stereo signal is encoded employing a similar frequency band decomposition; however, here the signal is divided into three bands that are individually parameterized.
ステレオ信号は同様の周波数帯分解を使うことでコード化されます。 しかしながら、ここで、信号は個別にparameterizedされる3つのバンドに分割されます。
The total bit-rate produced by the extension is the result of the combination of the encoder's core rate, stereo rate, and ISF. The extension supports 8 different core encoding rates, producing bit- rates between 10.4 and 24.0 kbit/s; see Table 22 in [1]. There are 16 stereo encoding rates generating bit-rates between 2.0 and 8.0 kbit/s; see Table 23 in [1]. The frame type uniquely identifies the AMR-WB modes, 4 fixed extension rates (see below), 24 combinations of core and stereo rates for stereo signals, and the 8 core rates for mono signals, as listed in Table 25 in [1]. This implies that the AMR-WB+ supports encoding rates between 10.4 and 32 kbit/s, assuming an ISF of 25600 Hz.
拡大で生産された総ビット伝送速度はエンコーダのコアレート、ステレオレート、およびISFの組み合わせの結果です。 レートをコード化する8の異なったコアが拡大は支持されて、ビットを作り出すと、10.4〜24.0kbit/sは評定されます。 [1]でTable22を見てください。 2.0の間のビット伝送速度を発生させるレートをコード化する16ステレオと8.0kbit/sがあります。 [1]でTable23を見てください。 フレームタイプは唯一AMR-WBモード、4つの固定拡大率(以下を見る)、コアの24の組み合わせ、ステレオ信号のステレオレート、およびモノタイプ信号の8つのコアレートを特定します、[1]にTable25に記載されているように。 25600HzのISFを仮定して、これは、+がコード化するのを支持するAMR-WBが10.4〜32kbit/sを評定するのを含意します。
Different ISFs allow for additional freedom in the produced bit-rates and audio quality. The selection of an ISF changes the available audio bandwidth of the reconstructed signal, and also the total bit- rate. The bit-rate for a given combination of frame type and ISF is determined by multiplying the frame type's bit-rate with the used ISF's bit-rate factor; see Table 24 in [1].
異なったISFsは生産されたビット伝送速度とオーディオ音質における追加自由を考慮します。 ISFの選択は、再建された信号の利用可能なオーディオ帯域幅を変えて、また、総ビットレートを変えます。 フレームタイプとISFの与えられた組み合わせのためのビット伝送速度はフレームタイプのビット伝送速度を掛けることによって、中古のISFのビット伝送速度要素に決定しています。 [1]でTable24を見てください。
The extension also has four frame types which have fixed ISFs. Please see frame types 10-13 in Table 21 in [1]. These four pre- defined frame types have a fixed input sampling frequency at the encoder, which can be set at either 16 or 24 kHz. Like the AMR-WB frame types, transport frames encoded utilizing these frame types represent exactly 20 ms of the audio signal. However, they are also part of 80 ms super-frames. Frame types 0-13 (AMR-WB and fixed extension rates), as listed in Table 21 in [1], do not require an explicit ISF indication. The other frame types, 14-47, require the ISF employed to be indicated.
また、拡大には、ISFsを修理した4つのフレームタイプがあります。 [1]でTable21のフレームタイプ10-13を見てください。 これらの4つのあらかじめ定義されたフレームタイプがエンコーダに固定的投入量サンプリング周波数を持っています。(16kHzか24kHzでそれを設定できます)。 AMR-WBフレームタイプ、これらのフレームタイプを利用するフレームがコード化した輸送のように、ちょうど音声信号の20msを表してください。 しかしながら、また、それらは80個のms超フレームの一部です。 [1]にTable21に記載されているフレームタイプ0-13(AMR-WBと固定拡大率)は明白なISF指示を必要としません。 14-47に、示されるのに使われたISFは、もう片方のフレームがタイプされるのを必要とします。
The 32 different frame types of the extension, in combination with 13 ISFs, allows for a great flexibility in bit-rate and selection of desired audio quality. A number of combinations exist that produce the same codec bit-rate. For example, a 32 kbit/s audio stream can be produced by utilizing frame type 41 (i.e., 25.6 kbit/s) and the ISF of 32kHz (5/4 * (19.2+6.4) = 32 kbit/s), or frame type 47 and the ISF of 25.6 kHz (1 * (24 + 8) = 32 kbit/s). Which combination is more beneficial for the perceived audio quality depends on the content. In the above example, the first case provides a higher audio bandwidth, while the second one spends the same number of bits
13ISFsと組み合わせて、拡大の32の異なったフレームタイプが必要なオーディオ音質のビット伝送速度と選択におけるかなりの柔軟性を考慮します。 同じコーデックビット伝送速度を生産する多くの組み合わせが存在しています。 例えば、フレームタイプ41(すなわち、25.6kbit/s)と32kHzのISFを利用することによって32kbit/sオーディオストリームを起こすことができる、(5/4、*、(19.2、+6.4、)、=32kbit/s)か、フレームタイプ47と25.6kHzのISF(1*(24+8)は32kbit/sと等しいです)。 知覚されたオーディオ音質には、どちらの組み合わせが、より有益であるかは内容によります。 上記の例に、最初のこの件は、より高いオーディオ帯域幅を供給します、2番目のものが同じ数のビットを費やしますが
Sjoberg, et al. Standards Track [Page 6] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[6ページ]RFC4352RTP有効搭載量形式
on somewhat narrower audio bandwidth but provides higher fidelity. Encoders are free to select the combination they deem most beneficial.
しかし、いくらか狭いオーディオ帯域幅、より高い忠実度を提供します。 エンコーダは無料で彼らが最も有益であると考える組み合わせを選択できます。
Since a transport frame always corresponds to 512 samples at the used ISF, its duration is limited to the range 13.33 to 40 ms; see Table 1. An RTP Timestamp clock rate of 72000 Hz, as mandated by this specification, results in AMR-WB+ transport frame lengths of 960 to 2880 timestamp ticks, depending solely on the selected ISF.
輸送フレームがいつも中古のISFの512個のサンプルに対応しているので、持続時間は40msへの範囲13.33に制限されます。 Table1を見てください。 この仕様で強制される72000HzのRTP Timestampクロックレートは960〜2880タイムスタンプの長さがカチカチと音を立てるAMR-WB+輸送フレームをもたらします、唯一選択されたISFによって。
Index ISF Duration(ms) Duration(TS Ticks @ 72 kHz)
------------------------------------------------------
0 N/A 20 1440
1 12800 40 2880
2 14400 35.55 2560
3 16000 32 2304
4 17067 30 2160
5 19200 26.67 1920
6 21333 24 1728
7 24000 21.33 1536
8 25600 20 1440
9 28800 17.78 1280
10 32000 16 1152
11 34133 15 1080
12 36000 14.22 1024
13 38400 13.33 960
インデックスISF持続時間(ms)持続時間(tは@72kHzのカチカチと音を立てます)------------------------------------------------------ 0、なし、20 1440、1、12800 40 2880、2、14400 35.55 2560、3、16000 32 2304、4、17067 30 2160、5、19200 26.67 1920、6、21333 24 1728、7、24000 21.33 1536、8、25600 20 1440、9、28800 17.78 1280 10 32000 16 1152 11 34133 15 1080 12 36000 14.22 1024 13 38400 13.33、960
Table 1: Normative number of RTP Timestamp Ticks for each
Transport Frame depending on ISF (ISF and Duration in
ms are rounded)
テーブル1: ISFによる各Transport Frameのための標準の数のRTP Timestampティックス(msのISFとDurationは丸いです)
The encoder is free to change both the ISF and the encoding frame type (both mono and stereo) during a session. For the extension frame types with index 10-13 and 16-47, the ISF and frame type changes are constrained to occur at super-frame boundaries. This implies that, for the frame types mentioned, the ISF is constant throughout a super-frame. This limitation does not apply for frame types with index 0-9, 14, and 15; i.e., the original AMR-WB frame types.
エンコーダはセッションの間、無料で、ISFとコード化フレームがタイプする両方(モノタイプとステレオの両方)を変えることができます。 インデックス10-13と16-47がある拡大フレームタイプにおいて、ISFとフレームタイプ変化が超フレーム境界に起こるのが抑制されます。 これは、ISFが超フレーム中でタイプが言及したフレームに関して一定であることを含意します。 この制限はインデックス0-9、14、および15でフレームタイプに申し込みません。 すなわち、オリジナルのAMR-WBフレームはタイプされます。
A number of features of the AMR-WB+ codec require special consideration from a transport point of view, and solutions that could perhaps be viewed as unorthodox. First, there are constraints on the RTP timestamping, due to the relationship of the frame duration and the ISFs. Second, each frame of encoded audio must maintain information about its frame type, ISF, and position in the super-frame.
AMR-WB+コーデックの多くの特徴が輸送観点、および恐らく正統でないとして見なすことができた解決策から特別の配慮を必要とします。 まず最初に、規制がフレーム持続時間とISFsの関係のためにRTP timestampingにあります。 2番目に、コード化されたオーディオの各フレームは超フレームでフレームタイプ、ISF、および位置の情報を保守しなければなりません。
Sjoberg, et al. Standards Track [Page 7] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[7ページ]RFC4352RTP有効搭載量形式
3.2. Multi-rate Encoding and Rate Adaptation
3.2. マルチレートコード化とレート適合
The multi-rate encoding capability of AMR-WB+ is designed to preserve high audio quality under a wide range of bandwidth requirements and transmission conditions.
さまざまな帯域幅要件とトランスミッション状態の+が設計されているAMR-WBの能力をコード化するマルチレート保護区高値オーディオの品質。
AMR-WB+ enables seamless switching between frame types that use the same number of audio channels and the same ISF. Every AMR-WB+ codec implementation is required to support all frame types defined by the codec and must be able to handle switching between any two frame types. Switching between frame types employing a different number of audio channels or a different ISF must also be supported, but it may not be completely seamless. Therefore, it is recommended to perform such switching infrequently and, if possible, during periods of silence.
AMR-WB+は同じ数の音声チャンネルと同じISFを使用するフレームタイプの間のシームレスの切り換えを可能にします。 あらゆるAMR-WB+コーデック実現が、タイプがコーデックで定義して、扱うことができなければならないすべてのフレームを支えるのにどんな2つのフレームタイプも切り換えながら、必要です。 また、異なった数の音声チャンネルか異なったISFを使うフレームタイプを切り換えるのを支持しなければなりませんが、それは完全にシームレスであるかもしれないというわけではありません。 したがって、まれにとできれば、沈黙の期間、切り替わるそのようなものを実行するのはお勧めです。
3.3. Voice Activity Detection and Discontinuous Transmission
3.3. 声のアクティビティ検出と不連続なトランスミッション
AMR-WB+ supports the same algorithms as AMR-WB for voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. However, these functionalities can only be used in conjunction with the AMR-WB frame types (FT=0-8). This option allows reducing the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR-WB+ frames containing CN parameters are called Silence Indicator (SID) frames. More details about the VAD and DTX functionality are provided in [4] and [5].
AMR-WB+は安らぎ雑音(CN)パラメタの声のアクティビティ検出(VAD)と世代のために沈黙の期間、AMR-WBと同じアルゴリズムを支持します。 しかしながら、AMR-WBフレームタイプ(FT=0-8)に関連してこれらの機能性を使用できるだけです。 このオプションで、沈黙の期間、伝えられたビットとパケットの数を最小限まで減少させます。 通常、一定の間隔を置いて沈黙の期間、パラメタをCNに送る操作は不連続なトランスミッション(DTX)かソース統制相場(SCR)操作と呼ばれます。 CNパラメタを含むAMR-WB+フレームはSilence Indicator(SID)フレームと呼ばれます。 VADとDTXの機能性に関するその他の詳細を[4]と[5]に提供します。
3.4. Support for Multi-Channel Session
3.4. マルチチャンネルセッションのサポート
Some of the AMR-WB+ frame types support the encoding of stereophonic audio. Because of this native support for a two-channel stereophonic signal, it does not seem necessary to support multi-channel transport with separate codec instances, as specified in the AMR-WB RTP payload [7]. The codec has the capability of stereo to mono downmixing as part of the decoding process. Thus, a receiver that is only capable of playout of monophonic audio must still be able to decode and play signals originally encoded and transmitted as stereo. However, to avoid spending bits on a stereo encoding that is not going to be utilized, a mechanism is defined in this specification to signal mono-only audio.
AMR-WB+フレームタイプの中には、ステレオのオーディオのコード化を支持する人もいます。 2チャンネルのステレオの信号のこのネイティブのサポートのために、別々のコーデック例でマルチチャンネル輸送を支持するのは必要に思えません、AMR-WB RTPペイロード[7]で指定されるように。 コーデックは解読過程の一部としてdownmixingされるモノタイプにステレオの能力を持っています。 したがって、単旋律のオーディオの再生ができるだけである受信機がまだ解読できなければならなくて、プレー信号は、元々、ステレオとしてコード化して、送信されました。 しかしながら、それをコード化しながらビットをステレオに費やすのを避けるのが利用されていない、メカニズムは、モノタイプだけオーディオに合図するためにこの仕様に基づき定義されます。
Sjoberg, et al. Standards Track [Page 8] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[8ページ]RFC4352RTP有効搭載量形式
3.5. Unequal Bit-Error Detection and Protection
3.5. 不平等なビット誤り検出と保護
The audio bits encoded in each AMR-WB frame are sorted according to their different perceptual sensitivity to bit errors. In cellular systems, for example, this property can be exploited to achieve better voice quality, by using unequal error protection and detection (UEP and UED) mechanisms. However, the bits of the extension frame types of the AMR-WB+ codec do not have a consistent perceptual significance property and are not sorted in this order. Thus, UEP or UED is meaningless with the extension frame types. If there is a need to use UEP or UED for AMR-WB frame types, it is recommended that RFC 3267 [7] be used.
それらの異なった知覚の感度に従って、それぞれのAMR-WBフレームでコード化されたオーディオビットは噛み付いている誤りに分類されます。 例えば、セルラ方式では、より良い音声の品質を達成するのにこの特性を利用できます、不平等な誤り保護と検出(UEPとUED)メカニズムを使用することによって。しかしながら、AMR-WB+コーデックの拡大フレームタイプのビットは、一貫した知覚の意味の特性を持たないで、またこの順で分類されません。 したがって、拡大フレームタイプに、UEPかUEDが無意味です。 AMR-WBフレームタイプにUEPかUEDを使用する必要があれば、RFC3267[7]が使用されるのは、お勧めです。
3.6. Robustness against Packet Loss
3.6. パケット損失に対する丈夫さ
The payload format supports two mechanisms to improve robustness against packet loss: simple forward error correction (FEC) and frame interleaving.
ペイロード形式はパケット損失に対して丈夫さを改良するために2つのメカニズムをサポートします: 簡単な前進型誤信号訂正(FEC)とフレームインターリービング。
3.6.1. Use of Forward Error Correction (FEC)
3.6.1. 前進型誤信号訂正の使用(FEC)
Generic forward error correction within RTP is defined, for example, in RFC 2733 [11]. Audio redundancy coding is defined in RFC 2198 [12]. Either scheme can be used to add redundant information to the RTP packet stream and make it more resilient to packet losses, at the expense of a higher bit rate. Please see either RFC for a discussion of the implications of the higher bit rate to network congestion.
例えば、RTPの中の一般的な前進型誤信号訂正はRFC2733[11]で定義されます。 オーディオ冗長コード化はRFC2198[12]で定義されます。 RTPパケットの流れに余分な情報を加えて、それをパケット損失により弾力があるようにするのにどちらの計画も使用できます、より高いビット伝送速度を犠牲にして。 より高いビット伝送速度の含意の議論に関してネットワークの混雑にRFCを見てください。
In addition to these media-unaware mechanisms, this memo specifies an AMR-WB+ specific form of audio redundancy coding, which may be beneficial in terms of packetization overhead.
これらのメディア気づかないメカニズムに加えて、このメモはAMR-WB+特定のフォームのオーディオ冗長コード化を指定します。(それは、packetizationオーバーヘッドで有益であるかもしれません)。
Conceptually, previously transmitted transport frames are aggregated together with new ones. A sliding window is used to group the frames to be sent in each payload. Figure 1 below shows an example.
概念的に、以前に伝えられた輸送フレームは新しいものと共に集められます。 引窓は、各ペイロードで送られるフレームを分類するのに使用されます。 以下の図1は例を示しています。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
--+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2)| f(n-1)| f(n)| f(n+1)| f(n+2)| f(n+3)| f(n+4)| --+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
<。---- p(n-1)----><。----- p(n)-----><。---- p(n+1)----><。---- p(n+2)----><。---- p(n+3)----><。---- p(n+4)---->。
Figure 1: An example of redundant transmission
図1: 余分なトランスミッションに関する例
Sjoberg, et al. Standards Track [Page 9] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[9ページ]RFC4352RTP有効搭載量形式
Here, each frame is retransmitted once in the following RTP payload packet. F(n-2)...f(n+4) denote a sequence of audio frames, and p(n-1)...p(n+4) a sequence of payload packets.
ここに、各フレームは以下のRTPペイロードパケットで一度再送されます。 F(n-2)…f(n+4)はオーディオフレーム、およびp(n-1)の系列を指示します…ペイロードパケットのp(n+4)a系列。
The mechanism described does not require signaling at the session setup. In other words, the audio sender can choose to use this scheme without consulting the receiver. For a certain timestamp, the receiver may receive multiple copies of a frame containing encoded audio data or frames indicated as NO_DATA. The cost of this scheme is bandwidth and the receiver delay necessary to allow the redundant copy to arrive.
説明されたメカニズムは、セッションセットアップのときに合図するのを必要としません。 言い換えれば、オーディオ送付者は、受信機に相談しないでこの計画を使用するのを選ぶことができます。あるタイムスタンプに関して、受信機はいいえ_DATAとして示された複本のコード化されたオーディオデータを含むフレームかフレームを受けるかもしれません。 この計画の費用は、帯域幅と余分なコピーが届くのを許容するのに必要な受信機遅れです。
This redundancy scheme provides a functionality similar to the one described in RFC 2198, but it works only if both original frames and redundant representations are AMR-WB+ frames. When the use of other media coding schemes is desirable, one has to resort to RFC 2198.
この冗長計画はRFC2198で説明されたものと同様の機能性を提供しますが、それはオリジナルのフレームと余分な表現の両方がAMR-WB+フレームである場合にだけ働いています。 他のメディアコード構成の使用が望ましいときに、人はRFC2198に頼らなければなりません。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel conditions, e.g., in the RTP Control Protocol (RTCP) [3] receiver reports. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 5 for more details).
送付者はチャンネル状態に関するフィードバックに基づく適切な量の冗長を選択するのに責任があります、例えば、RTP Controlプロトコル(RTCP)[3]受信機レポートで。 また、送付者も混雑を避けるのに責任があります(その他の詳細に関してセクション5を見てください)。(混雑は冗長によって悪化させられるかもしれません)。
3.6.2. Use of Frame Interleaving
3.6.2. フレームインターリービングの使用
To decrease protocol overhead, the payload design allows several audio transport frames to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that in case of packet loss several consecutive frames are lost. Consecutive frame loss normally renders error concealment less efficient and usually causes clearly audible and annoying distortions in the reconstructed audio. Interleaving of transport frames can improve the audio quality in such cases by distributing the consecutive losses into a number of isolated frame losses, which are easier to conceal. However, interleaving and bundling several frames per payload also increases end-to-end delay and sets higher buffering requirements. Therefore, interleaving is not appropriate for all use cases or devices. Streaming applications should most likely be able to exploit interleaving to improve audio quality in lossy transmission conditions.
プロトコルオーバーヘッドを下げるために、ペイロードデザインは、いくつかのオーディオ輸送フレームが単一のRTPパケットに要約されるのを許容します。 そのようなアプローチの欠点の1つはパケット損失の場合にいくつかの連続したフレームが無くなるということです。 連続したフレームの損失は、通常、誤り補正をより効率的でなくして、通常、明確に再建されたオーディオにおける聞きとれて煩わしいひずみを引き起こします。 輸送フレームのインターリービングは、そのような場合多くの孤立しているフレームの損失に連敗を広げることによって、オーディオ音質を改良できます。(損失は、より隠しやすいです)。 しかしながら、いくつかの1ペイロードあたりのフレームをはさみ込んで、束ねるのは、また、終わりから終わりへの遅れを増加させて、要件をバッファリングしながら、より高くセットします。 したがって、インターリービングはすべての使用のためにケースか装置を当てないことです。 ストリーミング・アプリケーションは、損失性トランスミッション状態のオーディオ音質を改良するのにたぶんインターリービングを利用できるべきです。
Note that this payload design supports the use of frame interleaving as an option. The usage of this feature needs to be negotiated in the session setup.
このペイロードデザインがオプションとしてフレームインターリービングの使用を支持することに注意してください。 この特徴の用法は、セッションセットアップで交渉される必要があります。
The interleaving supported by this format is rather flexible. For example, a continuous pattern can be defined, as depicted in Figure 2.
この形式で後押しされているインターリービングはかなりフレキシブルです。 例えば、図2に表現されるように連続したパターンを定義できます。
Sjoberg, et al. Standards Track [Page 10] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[10ページ]RFC4352RTP有効搭載量形式
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
--+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2)| f(n-1)| f(n)| f(n+1)| f(n+2)| f(n+3)| f(n+4)| --+--------+--------+--------+--------+--------+--------+--------+--
[ P(n) ]
[ P(n+1) ] [ P(n+1) ]
[ P(n+2) ] [ P(n+2) ]
[ P(n+3) ] [P(
[ P(n+4) ]
[P(n) ][P(n+1)][P(n+1)][P(n+2)][P(n+2)][P(n+3)]、[P、([P(n+4)]
Figure 2: An example of interleaving pattern that has constant delay
図2: 一定の遅れを持っているインターリービングパターンに関する例
In Figure 2 the consecutive frames, denoted f(n-2) to f(n+4), are aggregated into packets P(n) to P(n+4), each packet carrying two frames. This approach provides an interleaving pattern that allows for constant delay in both the interleaving and deinterleaving processes. The deinterleaving buffer needs to have room for at least three frames, including the one that is ready to be consumed. The storage space for three frames is needed, for example, when f(n) is the next frame to be decoded: since frame f(n) was received in packet P(n+2), which also carried frame f(n+3), both these frames are stored in the buffer. Furthermore, frame f(n+1) received in the previous packet, P(n+1), is also in the deinterleaving buffer. Note also that in this example the buffer occupancy varies: when frame f(n+1) is the next one to be decoded, there are only two frames, f(n+1) and f(n+3), in the buffer.
f(n+4)へのf(n-2)は、図2の連続したフレームがP(n+4)(2個のフレームを運ぶ各パケット)へのパケットP(n)に集められるのを指示しました。 このアプローチはインターリービングと「反-はさみ込」みの過程の両方の一定の遅れを考慮するインターリービングパターンを提供します。 「反-はさみ込」みバッファは少なくとも3個のフレームの余地を必要とします、消費される準備ができているものを含んでいて。 f(n)が隣のフレームであるときに、例えば、3個のフレームへの集積スペースが解読されるのに必要です: パケットP(n+2)(また、フレームf(n+3)を運んだ)にフレームf(n)を受け取ったので、これらのフレームの両方がバッファに格納されます。 その上、前のパケットに受け取られたフレームf(n+1)(P(n+1))が「反-はさみ込」みバッファにもあります。 また、バッファ占有が変えるこの例でそれに注意してください: フレームf(n+1)が次の解読されるべきものであるときに、2個のフレームだけ、f(n+1)とf(n+3)があります、バッファで。
3.7. AMR-WB+ Audio over IP Scenarios
3.7. IPシナリオの上のAMR-WB+オーディオ
Since the primary target application for the AMR-WB+ codec is streaming over packet networks, the most relevant usage scenario for this payload format is IP end-to-end between a server and a terminal, as shown in Figure 3.
AMR-WB+コーデックの第一の目標アプリケーションがパケット網の上でストリーミングであるので、このペイロード形式のための最も関連している用法シナリオは、図3に示されるようにサーバと端末の間のIPの終わりから終わりです。
+----------+ +----------+
| | IP/UDP/RTP/AMR-WB+ | |
| SERVER |<------------------------>| TERMINAL |
| | | |
+----------+ +----------+
+----------+ +----------+ | | IP/UDP/RTP/AMR Wb+| | | サーバ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 端末| | | | | +----------+ +----------+
Figure 3: Server to terminal IP scenario
図3: 端末のIPシナリオへのサーバ
3.8. Out-of-Band Signaling
3.8. バンドで出ているシグナリング
Some of the options of this payload format remain constant throughout a session. Therefore, they can be controlled/negotiated at the session setup. Throughout this specification, these options and variables are denoted as "parameters to be established through out-
このペイロード形式のオプションのいくつかがセッションの間中一定のままで残っています。 したがって、セッションセットアップのときにそれらを制御するか、または交渉できます。 この仕様中では、これらのオプションと変数は「外で通じて確立されるべきパラメタ」として指示されます。
Sjoberg, et al. Standards Track [Page 11] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[11ページ]RFC4352RTP有効搭載量形式
of-band means". In Section 7, all the parameters are formally specified in the form of media type registration for the AMR-WB+ encoding. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 7.2 provides a mapping of the parameters into the Session Description Protocol (SDP) [6] for those applications that use SDP.
「バンドの手段。」 セクション7では、すべてのパラメタがAMR-WB+コード化のためのメディアタイプ登録の形で正式に指定されます。 セッションセットアップでこれらのパラメタを示唆するか、または関係者の事前同意をアレンジするのに使用される方法はこのドキュメントの範囲を超えています。 しかしながら、セクション7.2はSDPを使用するそれらのアプリケーションのためのSession記述プロトコル(SDP)[6]にパラメタに関するマッピングを提供します。
4. RTP Payload Format for AMR-WB+
4. AMR-WB+のためのRTP有効搭載量形式
The main emphasis in the payload design for AMR-WB+ has been to minimize the overhead in typical use cases, while providing full flexibility with a slightly higher overhead. In order to keep the specification reasonably simple, we refrained from defining frame- specific parameters for each frame type. Instead, a few common parameters were specified that cover all types of frames.
AMR-WBのための+がオーバーヘッドを最小にしに典型的に行ったことがあるペイロードデザインにおける主な強調はわずかに高いオーバーヘッドを完全な柔軟性に提供している間、ケースを使用します。 合理的に簡単に仕様を守るために、私たちは、それぞれのフレームタイプのためにフレームの特定のパラメタを定義するのを控えました。 代わりに、すべてのタイプのフレームに関するいくつかの一般的なパラメタが指定されました。
The payload format has two modes: basic mode and interleaved mode. The main structural difference between the two modes is the extension of the table of content entries with frame displacement fields when operating in the interleaved mode. The basic mode supports aggregation of multiple consecutive frames in a payload. The interleaved mode supports aggregation of multiple frames that are non-consecutive in time. In both modes it is possible to have frames encoded with different frame types in the same payload. The ISF must remain constant throughout the payload of a single packet.
ペイロード形式には、2つのモードがあります: 基本のモードとはさみ込まれたモード。 はさみ込まれたモードで作動するとき、2つのモードの主な構造的な違いはフレーム置換え分野がある満足しているエントリーのテーブルの拡大です。 基本のモードはペイロードの複数の連続したフレームの集合を支持します。 はさみ込まれたモードは複数の時間内に非連続したフレームの集合を支持します。 両方のモードで、同じペイロードで異なったフレームタイプでフレームをコード化させるのは可能です。 ISFは単一のパケットのペイロード中で一定のままで残らなければなりません。
The payload format is designed around the property of AMR-WB+ frames that the frames are consecutive in time and share the same frame duration (in the absence of an ISF change). This enables the receiver to derive the timestamp for an individual frame within a payload. In basic mode, the deriving process is based on the order of frames. In interleaved mode, it is based on the compact displacement fields. The frame timestamps are used to regenerate the correct order of frames after reception, identify duplicates, and detect lost frames that require concealment.
ペイロード形式はAMR-WB+フレームの所有地の周りで設計されています。フレームは、時間内に、連続して、同じフレーム持続時間を共有します(ISF変化がないとき)。 これは、受信機がペイロードの中の個々のフレームのためのタイムスタンプを引き出すのを可能にします。 基本のモードで、派生の過程はフレームの注文に基づいています。 はさみ込まれたモードで、それはコンパクトな置換え分野に基づいています。 フレームタイムスタンプは、レセプションの後にフレームの正しい注文を作り直して、写しを特定して、隠すことを必要とする無くなっているフレームを検出するのに使用されます。
The interleaving scheme of this payload format is significantly more flexible than the one specified in RFC 3267. The AMR and AMR-WB payload format is only capable of using periodic patterns with frames taken from an interleaving group at fixed intervals. The interleaving scheme of this specification, in contrast, allows for any interleaving pattern, as long as the distance in decoding order between any two adjacent frames is not more than 256 frames. Note that even at the highest ISF this allows an interleaving depth of up to 3.41 seconds.
このペイロード形式のインターリービング計画はものがRFC3267で指定したよりかなりフレキシブルです。 AMRとAMR-WBペイロード形式はインターリービンググループから定期的に抜粋されるフレームは周期的なパターンを使用できるだけです。 対照的に、この仕様のインターリービング計画はどんなインターリービングパターンも考慮します、どんな2個の隣接しているフレームの間のオーダーを解読することにおける距離が256個以上のフレームでない限り。 これが最大3.41秒のインターリービングの深さに許容する中で最も高いISFでさえそれに注意してください。
Sjoberg, et al. Standards Track [Page 12] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[12ページ]RFC4352RTP有効搭載量形式
To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any audio frame multiple times. All redundantly sent frames MUST use the same frame type and ISF, and MUST have the same RTP timestamp, or MUST be a NO_DATA frame (FT=15).
余分なトランスミッションで誤りの弾性を考慮するために、複数のパケットでカバーされた期間は時間内に、重なるかもしれません。 複数の回あらゆるオーディオフレームを受け取るように受信機を準備しなければなりません。 同じフレームのタイプとISFを使用しなければならなくて、同じRTPタイムスタンプを持たなければならない、さもなければ、すべての冗長に送られたフレームが、いいえ_DATAフレームであるに違いありません(FT=15)。
The payload consists of octet-aligned elements (header, ToC, and audio frames). Only the audio frames for AMR-WB frame types (0-9) require padding for octet alignment. If additional padding is desired, then the P bit in the RTP header MAY be set, and padding MAY be appended as specified in [3].
ペイロードは八重奏で並べられた要素(ヘッダー、ToC、およびオーディオフレーム)から成ります。 AMR-WBフレームタイプ(0-9)のためのオーディオフレームだけが、八重奏整列のためにそっと歩くのを必要とします。 追加詰め物を望んでいるなら、RTPヘッダーのPビットを設定するかもしれません、そして、指定されるとして[3]で詰め物を追加するかもしれません。
4.1. RTP Header Usage
4.1. RTPヘッダー用法
The format of the RTP header is specified in [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[3]で指定されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame in the packet. The timestamp clock frequency SHALL be 72000 Hz. This frequency allows the frame duration to be integer RTP timestamp ticks for the ISFs specified in Table 1. It also provides reasonable conversion factors to the input/output audio sampling frequencies supported by the codec. See Section 4.3.2.3 for guidance on how to derive the RTP timestamp for any audio frame beyond the first one.
RTPタイムスタンプはパケットにおける最初のフレームにコード化された最初のサンプルの標本抽出の瞬間に対応しています。 タイムスタンプクロック周波数SHALL、72000Hzになってください。 この頻度は、フレーム持続時間がTable1で指定されたISFsのための整数RTPタイムスタンプカチカチする音であることを許容します。 また、それはコーデックによって支持された入力/出力オーディオサンプリング周波数に妥当な換算率を提供します。セクション4.3を見てください。.2 .3 どうどんなオーディオのためのRTPタイムスタンプも引き出すかにおける指導には、1番目を超えて1つを縁どってください。
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame carried in the packet is the first frame in a talkspurt (see the definition of talkspurt in Section 4.1 of [9]). For all other packets, the marker bit SHALL be set to zero (M=0).
パケットで運ばれた最初のフレームがtalkspurtで最初のフレームであるときはいつも、1に設定されてください。RTPヘッダーマーカーが(M) SHALLに噛み付いた、([9])のセクション4.1とのtalkspurtの定義を見てください。 他のすべてのパケットに関しては、マーカーはゼロへのセットが(M=0)であったならSHALLに噛み付きました。
The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profile in use either assigns a static payload type or mandates binding the payload type dynamically.
このドキュメントの範囲の外にこのメモで定義された書式のためのRTPペイロードタイプの課題があります。 使用中であるRTPプロフィールは静的なペイロードタイプかダイナミックにペイロードタイプを縛る命令を選任します。
The media type parameter "channels" is used to indicate the maximum number of channels allowed for a given payload type. A payload type where channels=1 (mono) SHALL only carry mono content. A payload type for which channels=2 has been declared MAY carry both mono and stereo content. Note that this definition is different from the one in RFC 3551 [9]. As mentioned before, the AMR-WB+ codec handles the support of stereo content and the (eventual) downmixing of stereo to mono internally. This makes it unnecessary to negotiate for the number of channels for reasons other than bit-rate efficiency.
「チャンネル」というメディア型引数は、チャンネルの最大数が与えられたペイロードタイプを考慮したのを示すのに使用されます。 チャンネルが1(モノタイプ)SHALLと等しいペイロードタイプはモノタイプ内容を運ぶだけです。 チャンネル=2が宣言されたペイロードタイプはモノタイプとステレオ内容の両方を運ぶかもしれません。 この定義がRFC3551[9]のものと異なっていることに注意してください。 以前言及されるように、AMR-WB+コーデックは内部的にステレオ内容のサポートとステレオの(最後)のdownmixingをモノタイプに扱います。 これで、ビット伝送速度効率以外の理由でチャンネルの数を交渉するのは不要になります。
Sjoberg, et al. Standards Track [Page 13] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[13ページ]RFC4352RTP有効搭載量形式
4.2. Payload Structure
4.2. 有効搭載量構造
The payload consists of a payload header, a table of contents, and the audio data representing one or more audio frames. The following diagram shows the general payload format layout:
ペイロードは1個以上のオーディオフレームを表すペイロードヘッダー、目次、およびオーディオデータから成ります。 以下のダイヤグラムは一般的なペイロード形式レイアウトを示しています:
+----------------+-------------------+---------------- | payload header | table of contents | audio data ... +----------------+-------------------+----------------
+----------------+-------------------+---------------- | ペイロードヘッダー| 目次| オーディオデータ… +----------------+-------------------+----------------
Payloads containing more than one audio frame are called compound payloads.
1個以上のオーディオフレームを含む有効搭載量は合成ペイロードと呼ばれます。
The following sections describe the variations taken by the payload format depending on the mode in use: basic mode or interleaved mode.
以下のセクションは使用中のモードに依存するペイロード形式によって取られた変化について説明します: 基本のモードかはさみ込まれたモード。
4.3. Payload Definitions
4.3. 有効搭載量定義
4.3.1. Payload Header
4.3.1. 有効搭載量ヘッダー
The payload header carries data that is common for all frames in the payload. The structure of the payload header is described below.
ペイロードヘッダーはペイロードですべてのフレームに、一般的なデータを運びます。 ペイロードヘッダーの構造は以下で説明されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ISF |TFI|L|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | ISF|TFI|L| +-+-+-+-+-+-+-+-+
ISF (5 bits): Indicates the Internal Sampling Frequency employed for
all frames in this payload. The index value corresponds to
internal sampling frequency as specified in Table 24 in [1]. This
field SHALL be set to 0 for payloads containing frames with Frame
Type values 0-13.
ISF(5ビット): このペイロードのすべてのフレームに使われたInternal Sampling Frequencyを示します。 インデックス値は[1]でTable24の指定されるとしての内部のサンプリング周波数に対応しています。 これはSHALLをさばきます。ペイロードのためにFrame Type値0-13があるフレームを含むのを0に用意ができさせてください。
TFI (2 bits): Transport Frame Index, from 0 (first) to 3 (last),
indicating the position of the first transport frame of this
payload in the AMR-WB+ super-frame structure. For payloads with
frames of only Frame Type values 0-9, this field SHALL be set to 0
by the sender. The TFI value for a frame of type 0-9 SHALL be
ignored by the receiver. Note that the frame type is coded in the
table of contents (as discussed later); hence, the mentioned
dependencies of the frame type can be applied easily by
interpreting only values carried in the payload header. It is not
necessary to interpret the audio bit stream itself.
TFI(2ビット): (最後に)(最初に)Frame Indexを0から3に輸送してください、超AMR-WB+枠組構造でこのペイロードの最初の輸送フレームの位置を示して。 唯一のフレームがあるペイロードのために、Frame Typeは0-9、この分野SHALLを評価します。0に、送付者は用意ができています。 タイプ0-9SHALLのフレームに関しては、受信機によって無視されてください。TFIが評価する、フレームタイプが目次(後で議論するように)でコード化されることに注意してください。 したがって、ペイロードヘッダーで運ばれた値だけを解釈することによって、容易にフレームタイプの言及された依存を適用できます。 オーディオビットストリーム自体を解釈するのは必要ではありません。
Sjoberg, et al. Standards Track [Page 14] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[14ページ]RFC4352RTP有効搭載量形式
L (1 bit): Long displacement field flag for payloads in interleaved
mode. If set to 0, four-bit displacement fields are used to
indicate interleaving offset; if set to 1, displacement fields of
eight bits are used (see Section 4.3.2.2). For payloads in the
basic mode, this bit SHALL be set to 0 and SHALL be ignored by the
receiver.
L(1ビット): はさみ込まれたモードによるペイロードのための長い置換え分野旗。 0に設定されるなら、4ビットの置換え分野はインターリービングが相殺されたのを示すのに使用されます。 セクション4.3を見てください。1に設定されるなら、8ビットの置換え分野が使用されている、(.2 .2)。 0とSHALLにはセットがあります。基本のモードによるペイロードのために、これがSHALLに噛み付いた、受信機で、無視されます。
Note that frames employing different ISF values require encapsulation in separate packets. Thus, special considerations apply when generating interleaved packets and an ISF change is executed. In particular, frames that, according to the previously used interleaving pattern, would be aggregated into a single packet have to be separated into different packets, so that the aforementioned condition (all frames in a packet share the ISF) remains true. A naive implementation that splits the frames with different ISF into different packets can result in up to twice the number of RTP packets, when compared to an optimal interleaved solution. Alteration of the interleaving before and after the ISF change may reduce the need for extra RTP packets.
雇用の異なったISFが評価するフレームが別々のパケットでカプセル化を必要とすることに注意してください。 はさみ込まれたパケットを発生させるとき、したがって、特別な問題は適用されます、そして、ISF変化は実行されます。 特に、以前中古のインターリービングパターンによると、単一のパケットに集められるフレームは異なったパケットに分離されなければなりません、前述の条件(パケットのすべてのフレームがISFを共有する)が本当のままで残るように。 異なったISFと共にフレームを異なったパケットに分けるナイーブな実現はRTPパケットの数を二度までもたらすことができます、最適のはさみ込まれた解決策と比べると。 ISF変化の前後にインターリービングの変更は余分なRTPパケットの必要性を減少させるかもしれません。
4.3.2. The Payload Table of Contents
4.3.2. 有効搭載量目次
The table of contents (ToC) consists of a list of entries, each entry corresponds to a group of audio frames carried in the payload, as depicted below.
目次(ToC)はエントリーのリストから成って、各エントリーはペイロードで運ばれたオーディオフレームのグループに対応しています、以下に表現されるように。
+----------------+----------------+- ... -+----------------+ | ToC entry #1 | ToC entry #2 | ToC entry #N | +----------------+----------------+- ... -+----------------+
+----------------+----------------+- ... -+----------------+ | ToCエントリー#1| ToCエントリー#2| ToCエントリー#N| +----------------+----------------+- ... -+----------------+
When multiple groups of frames are present in a payload, the ToC entries SHALL be placed in the packet in order of increasing RTP timestamp value (modulo 2^32) of the first transport frame the TOC entry represents.
フレームの複数のグループであるときに、置かれたコネがTOCのエントリーが表す最初の輸送フレームの増加するRTPタイムスタンプ価値(法2^32)の順にパケットであったなら、ペイロードでのプレゼント、ToCはエントリーSHALLですか?
4.3.2.1. ToC Entry in the Basic Mode
4.3.2.1. 基本のモードにおけるToCエントリー
A ToC entry of a payload in the basic mode has the following format:
基本のモードにおける、ペイロードのToCエントリーには、以下の形式があります:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Frame Type | #frames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| フレームタイプ| #フレーム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F (1 bit): If set to 1, indicates that this ToC entry is followed by
another ToC entry; if set to 0, indicates that this ToC entry is
the last one in the ToC.
F(1ビット): 1にセットして、別のToCエントリーがこのToCエントリーのあとに続くのを示します。 0にセットして、このToCエントリーがToCで最後のものであることを示します。
Sjoberg, et al. Standards Track [Page 15] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[15ページ]RFC4352RTP有効搭載量形式
Frame Type (FT) (7 bits): Indicates the audio codec frame type used
for the group of frames referenced by this ToC entry. FT
designates the combination of AMR-WB+ core and stereo rate, one of
the special AMR-WB+ frame types, the AMR-WB rate, or comfort
noise, as specified by Table 25 in [1].
Type(FT)(7ビット)を縁どってください: このToCエントリーで参照をつけられるフレームのグループに使用されるオーディオコーデックフレームタイプを示します。 FTは[1]でTable25による指定されるとしてのAMR-WB+コアとステレオレートの組み合わせ、特別なAMR-WB+フレームタイプのひとり、AMR-WBレート、または安らぎ雑音を指定します。
#frames (8 bits): Indicates the number of frames in the group
referenced by this ToC entry. ToC entries with this field equal
to 0 (which would indicate zero frames) SHALL NOT be used, and
received packets with such a TOC entry SHALL be discarded.
#フレーム(8ビット): このToCエントリーで参照をつけられるグループにおける、フレームの数を示します。 捨てられて、この分野があるToCエントリーはそのようなTOCのエントリーがある中古の、そして、容認されたパケットがSHALLであったなら0(フレームを全く示さない)とSHALL NOTと等しいです。
4.3.2.2. ToC Entry in the Interleaved Mode
4.3.2.2. はさみ込まれたモードにおけるToCエントリー
Two different ToC entry formats are defined in interleaved mode. They differ in the length of the displacement field, 4 bits or 8 bits. The L-bit in the payload header differentiates between the two modes.
2つの異なったToC入力フォーマットがはさみ込まれたモードで定義されます。 彼らは置換え分野、4ビットまたは8ビットの長さにおいて異なります。 ペイロードヘッダーのL-ビットは2つのモードを区別します。
If L=0, a ToC entry has the following format:
L=0であるなら、ToCエントリーには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Frame Type | #frames | DIS1 | ... | DISi | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | DISn | Padd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| フレームタイプ| #フレーム| DIS1| ... | DISi| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | DISn| Padd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F (1 bit): See definition in 4.3.2.1.
F(1ビット): .1に定義コネ4.3.2を見てください。
Frame Type (FT) (7 bits): See definition in 4.3.2.1.
Type(FT)(7ビット)を縁どってください: .1に定義コネ4.3.2を見てください。
#frames (8 bits): See definition in 4.3.2.1.
#フレーム(8ビット): .1に定義コネ4.3.2を見てください。
DIS1...DISn (4 bits): A list of n (n=#frames) displacement fields
indicating the displacement of the i:th (i=1..n) audio frame
relative to the preceding audio frame in the payload, in units of
frames. The four-bit unsigned integer displacement values may be
between 0 and 15, indicating the number of audio frames in
decoding order between the (i-1):th and the i:th frame in the
payload. Note that for the first ToC entry of the payload, the
value of DIS1 is meaningless. It SHALL be set to zero by a sender
and SHALL be ignored by a receiver. This frame's location in the
decoding order is uniquely defined by the RTP timestamp and TFI in
the payload header. Note also that for subsequent ToC entries,
DIS1 indicates the number of frames between the last frame of the
previous group and the first frame of this group.
DIS1…DISn(4ビット): iの置換えを示すn(n=#フレーム)置換え分野のリスト:、ペイロード、ユニットのフレームの前のオーディオフレームに比例した(i=1..n)オーディオ第フレーム。 第そして、4ビットの符号のない整数置換え値は、0〜15であるかもしれません、解読におけるフレームが間に(i-1)を命令するオーディオの数を示して:、i:、ペイロードで第縁どってください。 ペイロードの最初のToCエントリーに、DIS1の値が無意味であることに注意してください。 送付者とSHALLによってゼロに設定されて、受信機によって無視されてください。それ、SHALL、解読オーダーにおけるこのフレームの位置がRTPタイムスタンプとTFIによってペイロードヘッダーで唯一定義されるということになってください。 また、その後のToCエントリーに、DIS1が前のグループの最後のフレームとこのグループの最初のフレームの間のフレームの数を示すことに注意してください。
Sjoberg, et al. Standards Track [Page 16] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[16ページ]RFC4352RTP有効搭載量形式
Padd (4 bits): To ensure octet alignment, four padding bits SHALL be
included at the end of the ToC entry in case there is odd number
of frames in the group referenced by this entry. These bits SHALL
be set to zero and SHALL be ignored by the receiver. If a group
containing an even number of frames is referenced by this ToC
entry, these padding bits SHALL NOT be included in the payload.
Padd(4ビット): このエントリーで参照をつけられるグループにおける、フレームの奇数があるといけないのでSHALLがToCエントリーの端のときに含まれているのを八重奏整列、4詰め物ビット保証するために。 ゼロとSHALLに設定されて、受信機によって無視されてください。これらのビットSHALL、このToCエントリー(含まれているコネがペイロードであったならビットSHALL NOTを水増しするこれら)でフレームの偶数を含むのがグループであるなら参照をつけられるということになってください。
If L=1, a ToC entry has the following format:
L=1であるなら、ToCエントリーには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Frame Type | #frames | DIS1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | DISn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| フレームタイプ| #フレーム| DIS1| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | DISn| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F (1 bit): See definition in 4.3.2.1.
F(1ビット): .1に定義コネ4.3.2を見てください。
Frame Type (FT) (7 bits): See definition in 4.3.2.1.
Type(FT)(7ビット)を縁どってください: .1に定義コネ4.3.2を見てください。
#frames (8 bits): See definition in 4.3.2.1.
#フレーム(8ビット): .1に定義コネ4.3.2を見てください。
DIS1...DISn (8 bits): A list of n (n=#frames) displacement fields
indicating the displacement of the i:th (i=1..n) audio frame
relative to the preceding audio frame in the payload, in units of
frames. The eight-bit unsigned integer displacement values may be
between 0 and 255, indicating the number of audio frames in
decoding order between the (i-1):th and the i:th frame in the
payload. Note that for the first ToC entry of the payload, the
value of DIS1 is meaningless. It SHALL be set to zero by a sender
and SHALL be ignored by a receiver. This frame's location in the
decoding order is uniquely defined by the RTP timestamp and TFI in
the payload header. Note also that for subsequent ToC entries,
DIS1 indicates the displacement between the last frame of the
previous group and the first frame of this group.
DIS1…DISn(8ビット): iの置換えを示すn(n=#フレーム)置換え分野のリスト:、ペイロード、ユニットのフレームの前のオーディオフレームに比例した(i=1..n)オーディオ第フレーム。 第そして、8ビットの符号のない整数置換え値は、0〜255であるかもしれません、解読におけるフレームが間に(i-1)を命令するオーディオの数を示して:、i:、ペイロードで第縁どってください。 ペイロードの最初のToCエントリーに、DIS1の値が無意味であることに注意してください。 送付者とSHALLによってゼロに設定されて、受信機によって無視されてください。それ、SHALL、解読オーダーにおけるこのフレームの位置がRTPタイムスタンプとTFIによってペイロードヘッダーで唯一定義されるということになってください。 また、その後のToCエントリーに、DIS1が前のグループの最後のフレームとこのグループの最初のフレームの間の置換えを示すことに注意してください。
4.3.2.3. RTP Timestamp Derivation
4.3.2.3. RTPタイムスタンプ派生
The RTP Timestamp value for a frame SHALL be the timestamp value of the first audio sample encoded in the frame. The timestamp value for a frame is derived differently depending on the payload mode, basic or interleaved. In both cases, the first frame in a compound packet has an RTP timestamp equal to the one received in the RTP header. In the basic mode, the RTP time for any subsequent frame is derived in two steps. First, the sum of the frame durations (see Table 1) of all the preceding frames in the payload is calculated. Then, this sum is added to the RTP header timestamp value. For example, let's
RTP Timestampはタイムスタンプがフレームでコード化された最初のオーディオのサンプルの値であったならフレームにSHALLを評価します。 基本的であるかはさみ込まれたペイロードモードに異なってよって、フレームへのタイムスタンプ値は引き出されます。 どちらの場合も、合成パケットにおける最初のフレームには、RTPヘッダーに受け取られたものと等しいRTPタイムスタンプがあります。 基本のモードで、どんなその後のフレームへのRTP時間も2ステップで引き出されます。 まず最初に、ペイロードでのすべての前のフレームのフレーム持続時間(Table1を見る)の合計は計算されます。 そして、この合計はRTPヘッダータイムスタンプ価値に加えられます。 例えばなろう
Sjoberg, et al. Standards Track [Page 17] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[17ページ]RFC4352RTP有効搭載量形式
assume that the RTP Header timestamp value is 12345, the payload carries four frames, and the frame duration is 16 ms (ISF = 32 kHz) corresponding to 1152 timestamp ticks. Then the RTP timestamp of the fourth frame in the payload is 12345 + 3 * 1152 = 15801.
ペイロードは4個のフレームを運びます、そして、RTP Headerタイムスタンプ価値が12345であると仮定してください、そして、フレーム持続時間は1152年のタイムスタンプに対応する16ms(ISFは32kHzと等しい)がカチカチするということです。 そして、ペイロードにおける4番目のフレームに関するRTPタイムスタンプは*1152 = 15801に12345+3です。
In interleaved mode, the RTP timestamp for each frame in the payload is derived from the RTP header timestamp and the sum of the time offsets of all preceding frames in this payload. The frame timestamps are computed based on displacement fields and the frame duration derived from the ISF value. Note that the displacement in time between frame i-1 and frame i is (DISi + 1) * frame duration because the duration of the (i-1):th must also be taken into account. The timestamp of the first frame of the first group of frames (TS(1)) (i.e., the first frame of the payload) is the RTP header timestamp. For subsequent frames in the group, the timestamp is computed by
はさみ込まれたモードで、このペイロードにおける、すべての前のフレームの時間オフセットのRTPヘッダータイムスタンプと合計からペイロードの各フレームのためのRTPタイムスタンプを得ます。 フレームタイムスタンプはISF値から得られた置換え分野とフレーム持続時間に基づいて計算されます。 フレームi-1とフレームiの間で時間内にの置換えが(DISi+1)*フレーム持続時間であることに注意してください、(i-1)の持続時間:、また、第考慮に入れなければなりません。 1つの番目ものの最初のフレームに関するタイムスタンプはフレームを分類します。(TS(1))(すなわち、ペイロードの最初のフレーム)はRTPヘッダータイムスタンプです。 グループにおけるその後のフレームに関しては、タイムスタンプによって計算されます。
TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 < i < n
TS(i)はTS(i-1)+(DISi+1)*フレーム持続時間と等しく、2<はi<nです。
For subsequent groups of frames, the timestamp of the first frame is computed by
フレームのその後のグループにおいて、最初のフレームに関するタイムスタンプによって計算されます。
TS(1) = TSprev + (DIS1 + 1) * frame duration,
TS(1)はTSprev+(DIS1+1)*フレーム持続時間と等しいです。
where TSprev denotes the timestamp of the last frame in the previous group. The timestamps of the subsequent frames in the group are computed in the same way as for the first group.
TSprevが前のグループにおける最後のフレームに関するタイムスタンプを指示するところ。 同様に、グループにおけるその後のフレームに関するタイムスタンプは最初のグループのように計算されます。
The following example derives the RTP timestamps for the frames in an interleaved mode payload having the following header and ToC information:
以下の例は以下のヘッダーとToC情報を持ちながら、はさみ込まれたモードペイロードでフレームのためのRTPタイムスタンプを引き出します:
RTP header timestamp: 12345 ISF = 32 kHz Frame 1 displacement field: DIS1 = 0 Frame 2 displacement field: DIS2 = 6 Frame 3 displacement field: DIS3 = 4 Frame 4 displacement field: DIS4 = 7
RTPヘッダータイムスタンプ: 12345 ISFは32kHzのFrame1置換え分野と等しいです: DIS1は0Frame2置換え分野と等しいです: DIS2は6Frame3置換え分野と等しいです: DIS3は4Frame4置換え分野と等しいです: DIS4=7
Assuming an ISF of 32 kHz, which implies a frame duration of 16 ms, one frame lasts 1152 ticks. The timestamp of the first frame in the payload is the RTP timestamp, i.e., TS(1) = RTP TS. Note that the displacement field value for this frame must be ignored. For the second frame in the payload, the timestamp can be calculated as TS(2) = TS(1) + (DIS2 + 1) * 1152 = 20409. For the third frame, the timestamp is TS(3) = TS(2) + (DIS3 + 1) * 1152 = 26169. Finally, for the fourth frame of the payload, we have TS(4) = TS(3) + (DIS4 + 1) * 1152 = 35385.
32kHzのISFを仮定して、どれが、16msのフレーム持続時間、1個のフレームが1152を持続するのを含意するかカチカチします。 ペイロードにおける最初のフレームに関するタイムスタンプがRTPタイムスタンプである、すなわち、TS(1)はRTP TSと等しいです。 このフレームへの置換え分野価値を無視しなければならないことに注意してください。 ペイロードにおける2番目のフレームに関しては、TS(2)が*1152 = 20409にTS(1)+(DIS2+1)と等しいときに、タイムスタンプについて計算できます。 3番目のフレームに関しては、タイムスタンプは*1152 = 26169にTS(2)TS(3)=+(DIS3+1)です。 最終的に、ペイロードの4番目のフレームに関して、私たちはTS(4)に*1152 = 35385にTS(3)+(DIS4+1)と等しくさせます。
Sjoberg, et al. Standards Track [Page 18] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[18ページ]RFC4352RTP有効搭載量形式
4.3.2.4. Frame Type Considerations
4.3.2.4. フレームタイプ問題
The value of Frame Type (FT) is defined in Table 25 in [1]. FT=14 (AUDIO_LOST) is used to denote frames that are lost. A NO_DATA (FT=15) frame could result from two situations: First, that no data has been produced by the audio encoder; and second, that no data is transmitted in the current payload. An example for the latter would be that the frame in question has been or will be sent in an earlier or later packet. The duration for these non-included frames is dependent on the internal sampling frequency indicated by the ISF field.
Frame Type(FT)の値は[1]でTable25で定義されます。 FT=14(AUDIO_LOST)は、無くなっているフレームを指示するのに使用されます。 いいえ_DATA(FT=15)フレームは2つの状況から生じるかもしれません: 最初に、データは全くオーディオエンコーダによって作り出されていません。 そして、2番目、データは全く現在のペイロードで送られません。 後者のための例を問題のフレームがあったということであるだろうか、より初期の、または、より遅いパケットで送るでしょう。 これらの非含まれているフレームへの持続時間はISF分野によって示された内部のサンプリング周波数に依存しています。
For frame types with index 0-13, the ISF field SHALL be set 0. The frame duration for these frame types is fixed to 20 ms in time, i.e., 1440 ticks in 72 kHz. For payloads containing only frames of type 0-9, the TFI field SHALL be set to 0 and SHALL be ignored by the receiver. In a payload combining frames of type 0-9 and 10-13, the TFI values need to be set to match the transport frames of type 10-13. Thus, frames of type 0-9 will also have a derived TFI, which is ignored.
インデックス0-13があるフレームタイプのために、ISFはセットが0であったならSHALLをさばきます。 これらのフレームタイプのためのフレーム持続時間は時間内に20msに固定されています、すなわち、1440が72kHzをチェックします。 0とSHALLに設定されて、受信機によって無視されてください。タイプ0-9、TFI分野SHALLのフレームだけを含むペイロードのための0-9に10-13にタイプのフレームを結合するペイロードではTFI値が、タイプ10-13の輸送フレームを合わせるように設定される必要があるということになってください。 したがって、また、タイプ0-9のフレームには、派生しているTFIがあるでしょう。(TFIは無視されます)。
4.3.2.5. Other TOC Considerations
4.3.2.5. 他のTOC問題
If a ToC entry with an undefined FT value is received, the whole packet SHALL be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a severe degradation in audio quality.
未定義のFTと共に、値はToCエントリーであるなら受け取られていて、全体のパケットはSHALLです。捨てられます。 これは、depacketizationの過程における、データ同期の損失を避けるためのものです。(過程は、オーディオ音質における厳しい退行をもたらすことができます)。
Packets containing only NO_DATA frames SHOULD NOT be transmitted. Also, NO_DATA frames at the end of a frame sequence to be carried in a payload SHOULD NOT be included in the transmitted packet. The AMR-WB+ SCR/DTX is identical with AMR-WB SCR/DTX described in [5] and can only be used in combination with the AMR-WB frame types (0-8).
いいえ_DATAだけを含むパケットがSHOULD NOTを縁どっています。伝えられます。 また、いいえ_DATAは、含まれていて、伝えられたパケットでペイロードSHOULD NOTで運ばれるためにフレーム系列の終わりで縁どっています。 AMR-WB+SCR/DTXは[5]で説明されるAMR-WB SCR/DTXと同じであり、AMR-WBフレームタイプ(0-8)と組み合わせて使用できるだけです。
When multiple groups of frames are present, their ToC entries SHALL be placed in the ToC in order of increasing RTP timestamp value (modulo 2^32) of the first transport frame the TOC entry represents, independent of the payload mode. In basic mode, the frames SHALL be consecutive in time, while in interleaved mode the frames MAY not only be non-consecutive in time but MAY even have varying inter-frame distances.
フレームの複数のグループであるときに、1つの番目ものの増加するRTPタイムスタンプ価値(法2^32)の順にToCがTOCのエントリーが表すフレーム、独立者を輸送する置かれたコネがペイロードモードであったなら、プレゼント、それらのToCはエントリーSHALLですか? 基本のモードで、フレームSHALLには、はさみ込まれたモードで、フレームが時間内に非連続するかもしれないだけではない間の時間で連続していますが、異なったインターフレーム距離がありさえするかもしれません。
4.3.2.6. ToC Examples
4.3.2.6. ToCの例
The following example illustrates a ToC for three audio frames in basic mode. Note that in this case all audio frames are encoded using the same frame type, i.e., there is only one ToC entry.
以下の例は基本のモードで3個のオーディオフレームにToCを例証します。 この場合すべてのオーディオフレームが同じフレームタイプを使用することでコード化されて、すなわち、1つのToCエントリーしかないことに注意してください。
Sjoberg, et al. Standards Track [Page 19] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[19ページ]RFC4352RTP有効搭載量形式
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Frame Type1 | #frames = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| フレームType1| #フレーム=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The next example depicts a ToC of three entries in basic mode. Note that in this case the payload also carries three frames, but three ToC entries are needed because the frames of the payload are encoded using different frame types.
次の例は基本のモードにおける3つのエントリーのToCについて表現します。 ペイロードのフレームが異なったフレームタイプを使用することでコード化されるので、また、この場合、ペイロードが3個のフレームを運びますが、3つのToCエントリーが必要であることに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Frame Type1 | #frames = 1 |1| Frame Type2 | #frames = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Frame Type3 | #frames = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| フレームType1| #フレーム=1|1| フレームType2| #フレーム=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| フレームType3| #フレーム=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following example illustrates a ToC with two entries in interleaved mode using four-bit displacement fields. The payload includes two groups of frames, the first one including a single frame, and the other one consisting of two frames.
4ビットの置換え分野を使用することで以下の例ははさみ込まれたモードにおける2つのエントリーをToCに入れます。 ペイロードはフレームの2つのグループ、2のある成るのが縁どるシングルフレーム、およびもう片方を含む最初のものを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Frame Type1 | #frames = 1 | DIS1 | padd |0| Frame Type2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #frames = 2 | DIS1 | DIS2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| フレームType1| #フレーム=1| DIS1| padd|0| フレームType2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #フレーム=2| DIS1| DIS2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.3. Audio Data
4.3.3. オーディオデータ
Audio data of a payload consists of zero or more audio frames, as described in the ToC of the payload.
ペイロードに関するオーディオデータはペイロードのToCで説明されるようにゼロか、より多くのオーディオフレームから成ります。
ToC entries with FT=14 or 15 represent frame types with a length of 0. Hence, no data SHALL be placed in the audio data section to represent frames of this type.
FT=14か15があるToCエントリーは0の長さでフレームタイプの代理をします。 .、データSHALL。オーディオ資料課に置かれて、このタイプのフレームを表してください。
As already discussed, each audio frame of an extension frame type represents an AMR-WB+ transport frame corresponding to the encoding of 512 samples of audio, sampled with the internal sampling frequency specified by the ISF indicator. As an exception, frame types with index 10-13 are only capable of using a single internal sampling frequency (25600 Hz). The encoding rates (combination of core bit- rate and stereo bit-rate) are indicated in the frame type field of
拡大の既に議論して、それぞれオーディオのフレームとして、フレームタイプはオーディオの512個のサンプルのコード化に対応する、抽出されたISFインディケータで指定されている内部のサンプリング周波数でAMR-WB+輸送フレームを表します。 例外として、インデックス10-13があるフレームタイプはただ一つの内部のサンプリング周波数(25600Hz)を使用できるだけです。 コード化レート(コアの噛み付いているレートとステレオビット伝送速度の組み合わせ)はフレームが分野をタイプする示されたコネです。
Sjoberg, et al. Standards Track [Page 20] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[20ページ]RFC4352RTP有効搭載量形式
the corresponding ToC entry. The octet length of the audio frame is implicitly defined by the frame type field and is given in Tables 21 and 25 of [1]. The order and numbering notation of the bits are as specified in [1]. For the AMR-WB+ extension frame types and comfort noise frames, the bits are in the order produced by the encoder. The last octet of each audio frame MUST be padded with zeroes at the end if not all bits in the octet are used. In other words, each audio frame MUST be octet-aligned.
対応するToCエントリー。 オーディオフレームの八重奏の長さは、フレームタイプ分野でそれとなく定義して、Tables21と25で[1]を与えます。 ビットの注文と付番記法が[1]で指定されるようにあります。 AMR-WB+拡大フレームタイプと安らぎ雑音フレームに関しては、ビットがエンコーダによって作り出されたオーダーにあります。 終わりのゼロでそれぞれのオーディオフレームの最後の八重奏を水増ししなければならない、さもなければ、八重奏におけるすべてのビットが使用されています。 言い換えれば、それぞれのオーディオフレームは八重奏で並べなければなりません。
4.3.4. Methods for Forming the Payload
4.3.4. 有効搭載量を形成するための方法
The payload begins with the payload header, followed by the table of contents, which consists of a list of ToC entries.
ペイロードはToCエントリーのリストから成る目次があとに続いたペイロードヘッダーと共に始まります。
The audio data follows the table of contents. All the octets comprising an audio frame SHALL be appended to the payload as a unit. The audio frames are packetized in timestamp order within each group of frames (per ToC entry). The groups of frames are packetized in the same order as their corresponding ToC entries. Note that there are no data octets in a group having a ToC entry with FT=14 or FT=15.
オーディオデータは目次に従います。 オーディオを包括するすべての八重奏がSHALLを縁どっています。ペイロードに一体にして追加します。 オーディオフレームはフレーム(ToCエントリーあたりの)の各グループの中のタイムスタンプオーダーでpacketizedされます。 フレームのグループは彼らの対応するToCエントリーとして同次でpacketizedされます。 FT=14かFT=15とのToCエントリーを持っているグループにはデータ八重奏が全くないことに注意してください。
4.3.5. Payload Examples
4.3.5. 有効搭載量の例
4.3.5.1. Example 1: Basic Mode Payload Carrying Multiple Frames Encoded
Using the Same Frame Type
4.3.5.1. 例1: 同じフレームタイプを使用することでコード化された複数のフレームを運ぶ基本的なモード有効搭載量
Figure 4 depicts a payload that carries three AMR-WB+ frames encoded using 14 kbit/s frame type (FT=26) with a frame length of 280 bits (35 bytes). The internal sampling frequency in this example is 25.6 kHz (ISF = 8). The TFI for the first frame is 2, indicating that the first transport frame in this payload is the third in a super-frame. Since this payload is in the basic mode, the subsequent frames of the payload are consecutive frames in decoding order, i.e., the fourth transport frame of the current super-frame and the first transport frame of the next super-frame. Note that because the frames are all encoded using the same frame type, only one ToC entry is required.
図4は280ビット(35バイト)のフレームの長さと共に14kbit/sフレームタイプ(FT=26)を使用することでコード化された3個のAMR-WB+フレームを運ぶペイロードについて表現します。 この例の内部のサンプリング周波数は25.6kHz(ISF=8)です。 最初のフレームへのTFIは2歳です、このペイロードにおける最初の輸送フレームが超フレームで3番目であることを示して。 このペイロードが基本のモードであるので、ペイロードのその後のフレームはオーダーを解読することにおける連続したフレーム、すなわち、現在の超フレームと隣の超フレームの最初の輸送フレームの4番目の輸送フレームです。 フレームが同じフレームタイプを使用することですべてコード化されるので1つのToCエントリーだけが必要であることに注意してください。
Sjoberg, et al. Standards Track [Page 21] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[21ページ]RFC4352RTP有効搭載量形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISF = 8 | 2 |0|0| FT = 26 | #frames = 3 | f1(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f1(272...279) | f2(0...7) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(272...279) | f3(0...7) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f3(272...279) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISF=8| 2 |0|0| フィート=26| #フレーム=3| f1(0...7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f1(272...279)| f2(0...7)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(272...279)| f3(0...7)| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f3(272...279)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: An example of a basic mode payload carrying three frames
of the same frame type
図4: 同じフレームタイプの3個のフレームを運ぶ基本的なモードペイロードに関する例
4.3.5.2. Example 2: Basic Mode Payload Carrying Multiple Frames Encoded
Using Different Frame Types
4.3.5.2. 例2: 異なったフレームタイプを使用することでコード化された複数のフレームを運ぶ基本的なモード有効搭載量
Figure 5 depicts a payload that carries three AMR-WB+ frames; the first frame is encoded using 18.4 kbit/s frame type (FT=33) with a frame length of 368 bits (46 bytes), and the two subsequent frames are encoded using 20 kbit/s frame type (FT=35) having frame length of 400 bits (50 bytes). The internal sampling frequency in this example is 32 kHz (ISF = 10), implying the overall bit-rates of 23 kbit/s for the first frame of the payload, and 25 kbit/s for the subsequent frames. The TFI for the first frame is 3, indicating that the first transport frame in this payload is the fourth in a super-frame. Since this is a payload in the basic mode, the subsequent frames of the payload are consecutive frames in decoding order, i.e., the first and second transport frames of the current super-frame. Note that since the payload carries two different frame types, there are two ToC entries.
図5は3個のAMR-WB+フレームを運ぶペイロードについて表現します。 最初のフレームは368ビット(46バイト)のフレームの長さと共に18.4kbit/sフレームタイプ(FT=33)を使用することでコード化されます、そして、2個のその後のフレームが、400ビット(50バイト)のフレームの長さを持ちながら20kbit/sフレームタイプ(FT=35)を使用することでコード化されます。 この例の内部のサンプリング周波数は32kHz(ISF=10)です、ペイロードの最初のフレーム、およびその後のフレームへの25kbit/sのために23kbit/sの総合的なビット伝送速度を含意して。 最初のフレームへのTFIは3歳です、このペイロードにおける最初の輸送フレームが超フレームで4番目であることを示して。 基本のモードでこれがペイロードであるので、ペイロードのその後のフレームはオーダー(すなわち、現在の超フレームの1番目と2番目の輸送フレーム)を解読することにおいて連続したフレームです。 ペイロードが2つの異なったフレームタイプを運ぶので2つのToCエントリーがあることに注意してください。
Sjoberg, et al. Standards Track [Page 22] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[22ページ]RFC4352RTP有効搭載量形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISF=10 | 3 |0|1| FT = 33 | #frames = 1 |0| FT = 35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #frames = 2 | f1(0...7) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f1(360...367) | f2(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(392...399) | f3(0...7) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f3(392...399) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISF=10| 3 |0|1| フィート=33| #フレーム=1|0| フィート=35| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #フレーム=2| f1(0...7)| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f1(360...367)| f2(0...7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(392...399)| f3(0...7)| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f3(392...399)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: An example of a basic mode payload carrying three frames
employing two different frame types
図5: 3を運ぶ基本的なモードペイロードに関する例は2の異なったフレームがタイプする雇用を縁どっています。
4.3.5.3. Example 3: Payload in Interleaved Mode
4.3.5.3. 例3: はさみ込まれたモードによる有効搭載量
The example in Figure 6 depicts a payload in interleaved mode, carrying four frames encoded using 32 kbit/s frame type (FT=47) with frame length of 640 bits (80 bytes). The internal sampling frequency is 38.4 kHz (ISF = 13), implying a bit-rate of 48 kbit/s for all frames in the payload. The TFI for the first frame is 0; hence, it is the first transport frame of a super-frame. The displacement fields for the subsequent frames are DIS2=18, DIS3=15, and DIS4=10, which indicates that the subsequent frames have the TFIs of 3, 3, and 2, respectively. The long displacement field flag L in the payload header is set to 1, which results in the use of eight bits for the displacement fields in the ToC entry. Note that since all frames of this payload are encoded using the same frame type, there is need only for a single ToC entry. Furthermore, the displacement field for the first frame (corresponding to the first ToC entry with DIS1=0) must be ignored, since its timestamp and TFI are defined by the RTP timestamp and the TFI found in the payload header.
図6の例ははさみ込まれたモードでペイロードについて表現します、640ビット(80バイト)のフレームの長さと共に32kbit/sフレームタイプ(FT=47)を使用することでコード化された4個のフレームを運んで。 内部のサンプリング周波数が38.4kHz(ISF=13)である、少し評価するように含意して、48では、すべてのためのkbit/sはペイロードで縁どられます。 最初のフレームへのTFIは0歳です。 したがって、それは超フレームの最初の輸送フレームです。 その後のフレームへの置換え分野は、DIS2=18と、DIS3=15と、DIS4=10です。(そのDIS4=10はそれぞれその後のフレームには3、3、および2のTFIsがあるのを示します)。 ペイロードヘッダーの長い置換え分野旗Lは1へのセットです。(そのセットは8ビットのToCエントリーにおける置換え分野の使用をもたらします)。 このペイロードのすべてのフレームが同じフレームタイプを使用することでコード化されるので単一のToCエントリーだけの必要があることに注意してください。 その上、最初のフレーム(DIS1=0との最初のToCエントリーに対応する)への置換え分野を無視しなければなりません、そのタイムスタンプとTFIがペイロードヘッダーで見つけられたRTPタイムスタンプとTFIによって定義されるので。
The RTP timestamp values of the frames in this example are:
この例のフレームのRTPタイムスタンプ値は以下の通りです。
Frame1: TS1 = RTP Timestamp Frame2: TS2 = TS1 + 19 * 960 Frame3: TS3 = TS2 + 16 * 960 Frame4: TS4 = TS3 + 11 * 960
Frame1: TS1はRTPタイムスタンプFrame2と等しいです: TS2はTS1+19*960Frame3と等しいです: TS3はTS2+16*960Frame4と等しいです: TS4はTS3+11*960と等しいです。
Sjoberg, et al. Standards Track [Page 23] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[23ページ]RFC4352RTP有効搭載量形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISF=13 | 0 |1|0| FT = 47 | #frames = 4 | DIS1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIS2 = 18 | DIS3 = 15 | DIS4 = 10 | f1(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f1(632...639) | f2(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f2(632...639) | f3(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f3(632...639) | f4(0...7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | f4(632...639) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISF=13| 0 |1|0| フィート=47| #フレーム=4| DIS1=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DIS2=18| DIS3=15| DIS4=10| f1(0...7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f1(632...639)| f2(0...7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f2(632...639)| f3(0...7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f3(632...639)| f4(0...7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | f4(632...639)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: An example of an interleaved mode payload carrying four
frames at the same frame type
図6: 同じフレームタイプで4個のフレームを運ぶはさみ込まれたモードペイロードに関する例
4.4. Interleaving Considerations
4.4. インターリービング問題
The use of interleaving requires further considerations. As presented in the example in Section 3.6.2, a given interleaving pattern requires a certain amount of the deinterleaving buffer. This buffer space, expressed in a number of transport frame slots, is indicated by the "interleaving" media type parameter. The number of frame slots needed can be converted into actual memory requirements by considering the 80 bytes per frame used by the largest combination of AMR-WB+'s core and stereo rates.
インターリービングの使用はさらなる問題を必要とします。 セクション3.6.2における例に示されるように、与えられたインターリービングパターンは「反-はさみ込」みバッファのある量を必要とします。 多くの輸送フレームスロットで言い表されたこのバッファ領域は「インターリービング」メディア型引数によって示されます。 +が1AMR-WBの最も大きい組み合わせで使用されるフレームあたり80バイトで、コアとステレオの速度であると考えることによって、スロットが必要としたフレームの数を実際のメモリ要件に変換できます。
The information about the frame buffer size is not always sufficient to determine when it is appropriate to start consuming frames from the interleaving buffer. There are two cases in which additional information is needed: first, when switching of the ISF occurs, and second, when the interleaving pattern changes. The "int-delay" media type parameter is defined to convey this information. It allows a sender to indicate the minimal media time that needs to be present in the buffer before the decoder can start consuming frames from the buffer. Because the sender has full control over ISF changes and the interleaving pattern, it can calculate this value.
フレームバッファサイズの情報は、インターリービングバッファからフレームを消費し始めるのがいつ適切であるかを決定するためにいつも十分であるというわけではありません。 追加情報が必要である2つの場合があります: ISFを切り換えるときの1番目は起こります、そして、インターリービングパターンであることの2番目は変化します。 「int-遅れ」メディア型引数は、この情報を伝えるために定義されます。 それで、送付者はデコーダが、バッファからフレームを消費し始めることができる前にバッファに存在している必要がある最小量のメディア時間を示すことができます。 送付者にはISF変化とインターリービングパターンの完全なコントロールがあるので、それはこの値について計算できます。
Sjoberg, et al. Standards Track [Page 24] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[24ページ]RFC4352RTP有効搭載量形式
In certain cases (for example, if joining a multicast session with interleaving mid-session), a receiver may initially receive only part of the packets in the interleaving pattern. This initial partial reception (in frame sequence order) of frames can yield too few frames for acceptable quality from the audio decoding. This problem also arises when using encryption for access control, and the receiver does not have the previous key.
ある場合には(例えば中間のセッションであるインターリービングとのマルチキャストセッションに参加するなら)、受信機は初めは、インターリービングパターンにパケットの一部だけを受け取るかもしれません。 フレームのこの初期の部分的なレセプション(船体の骨組を組み立て終えて系列オーダー)はオーディオ解読から合格品質のためのあまりにわずかなフレームしかもたらすことができません。 また、アクセス管理に暗号化を使用するとき、この問題は起こります、そして、受信機には、前のキーがありません。
Although the AMR-WB+ is robust and thus tolerant to a high random frame erasure rate, it would have difficulties handling consecutive frame losses at startup. Thus, some special implementation considerations are described. In order to handle this type of startup efficiently, it must be noted that decoding is only possible to start at the beginning of a super-frame, and that holds true even if the first transport frame is indicated as lost. Secondly, decoding is only RECOMMENDED to start if at least 2 transport frames are available out of the 4 belonging to that super-frame.
+はAMR-WBですが、強健であって、その結果、高い無作為のフレーム消去率に許容性がある、それは始動で連続したフレームの損失を扱うのに苦労するでしょう。 したがって、いくつかの特別な実現問題が説明されます。 効率的にこのタイプの始動を扱うために解読が超フレームの始めに単に始めるのにおいて可能であることに注意しなければならなくて、最初の輸送フレームが失われているように示されても、それは有効です。 第二に、少なくとも2個の輸送フレームがその超フレームに属す4から利用可能である場合にだけ、解読は始まるRECOMMENDEDです。
After receiving a number of packets, in the worst case as many packets as the interleaving pattern covers, the previously described effects disappear and normal decoding is resumed.
多くのパケット、インターリービングパターンが覆っているのと最悪の場合には同じくらい多くのパケットを受けた後に、以前に説明された効果は見えなくなります、そして、正常な解読は再開されます。
Similar issues arise when a receiver leaves a session or has lost access to the stream. If the receiver leaves the session, this would be a minor issue since playout is normally stopped. It is also a minor issue for the case of lost access, since the AMR-WB+ error concealment will fade out the audio if massive consecutive losses are encountered.
受信機がセッションを出発するか、または流れにアクセスを失ったとき、同様の問題は起こります。 受信機がセッションを出発するなら、再生が通常止められるので、これは小さな問題でしょう。 また、それは無くなっているアクセスに関するケースのための小さな問題です、大規模な連敗が遭遇するとAMR-WB+誤り補正がオーディオを次第にぼんやりするので。
The sender can avoid this type of problem in many sessions by starting and ending interleaving patterns correctly when risks of losses occur. One such example is a key-change done for access control to encrypted streams. If only some keys are provided to clients and there is a risk of their receiving content for which they do not have the key, it is recommended that interleaving patterns not overlap key changes.
送付者は損失のリスクが起こる正しく始まって、インターリービングパターンを終わらせるのによる多くのセッションのときにこのタイプの問題を避けることができます。 その一例はアクセス管理のためにコード化された流れに行われたキーチェンジです。いくつかだけのキーをクライアントに提供して、彼らが内容を受け取るという彼らがキーを持っていないリスクがあれば、インターリービングパターンがキーチェンジを重ね合わせないのは、お勧めです。
4.5. Implementation Considerations
4.5. 実現問題
An application implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. So an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating.
このペイロード形式を実行するアプリケーションはすべてのペイロードパラメタを理解しなければなりません。 シグナリングプロトコルへのパラメタに関するどんなマッピングもすべてのパラメタを支持しなければなりません。 それで、SDPを使用するアプリケーションにおける、このペイロード形式の実現が、それらのSDPによって写像されたフォームですべてのペイロードパラメタを理解するのに必要です。 この要件は、実現が、いつもそれが交信できるかどうか決めることができるのを確実にします。
Sjoberg, et al. Standards Track [Page 25] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[25ページ]RFC4352RTP有効搭載量形式
Both basic and interleaved mode SHALL be implemented. The implementation burden of both is rather small, and requiring both ensures interoperability. As the AMR-WB+ codec contains the full functionality of the AMR-WB codec, it is RECOMMENDED to also implement the payload format in RFC 3267 [7] for the AMR-WB frame types when implementing this specification. Doing so makes interoperability with devices that only support AMR-WB more likely.
基本的なものと同様にはさみ込まれたモードSHALL、実行されてください。 両方の実現負担はかなり小さいです、そして、両方を必要とすると、相互運用性は確実にされます。 AMR-WB+コーデックがAMR-WBコーデックの完全な機能性を含むとき、それはまた、この仕様を履行するときAMR-WBフレームタイプのためのRFC3267[7]でペイロード形式を実行するRECOMMENDEDです。 そうするのはおそらく、AMR-WBを支持するだけである装置で相互運用性を作ります。
The switching of ISF, when combined with packet loss, could result in concealment using the wrong audio frame length. This can occur if packet losses result in lost frames directly after the point of ISF change. The packet loss would prevent the receiver from noticing the changed ISF and thereby conceal the lost transport frame with the previous ISF, instead of the new one. Although always later detectable, such an error results in frame boundary misalignment, which can cause audio distortions and problems with synchronization, as too many or too few audio samples were created. This problem can be mitigated in most cases by performing ISF recovery prior to concealment as outlined in Section 4.5.1.
パケット損失に結合されると、ISFの切り換えは、間違ったオーディオフレームの長さを使用することで隠すことをもたらすかもしれません。 ISFの先直後無くなっているフレームのパケット損失結果が変化するなら、これは起こることができます。 パケット損失は、変えられたISFに気付くのからの受信機を防いで、その結果、前のISFがある無くなっている輸送フレームを隠すでしょう、新しい方の代わりに。 いつもより遅れていますが、検出可能であることで、そのような誤りはフレーム境界調整不良に結果として生じて、どれが多く過ぎるかわずか過ぎるとしての同期に関するオーディオひずみと問題にオーディオのサンプルを引き起こす場合があるかは作成されました。 多くの場合、隠すことの前にセクション4.5.1に概説されているようにISF回復を実行することによって、この問題を緩和できます。
4.5.1. ISF Recovery in Case of Packet Loss
4.5.1. パケット損失の場合のISF回復
In case of packet loss, it is important that the AMR-WB+ decoder initiates a proper error concealment to replace the frames carried in the lost packet. A loss concealment algorithm requires a codec framing that matches the timestamps of the correctly received frames. Hence, it is necessary to recover the timestamps of the lost frames. Doing so is non-trivial because the codec frame length that is associated with the ISF may have changed during the frame loss.
パケット損失の場合には、AMR-WB+デコーダが無くなっているパケットで運ばれたフレームを取り替えるために適切な誤り補正を開始するのは、重要です。 損失隠すことのアルゴリズムは正しく容認されたフレームに関するタイムスタンプに合っているコーデック縁どりを必要とします。 したがって、無くなっているフレームに関するタイムスタンプを回復するのが必要です。 ISFに関連しているコーデックフレームの長さがフレームの損失の間、変化したかもしれないので、そうするのは重要です。
In the following, the recovery of the timestamp information of lost frames is illustrated by the means of an example. Two frames with timestamps t0 and t1 have been received properly, the first one being the last packet before the loss, and the latter one being the first packet after the loss period. The ISF values for these packets are isf0 and isf1, respectively. The TFIs of these frames are tfi0 and tfi1, respectively. The associated frame lengths (in timestamp ticks) are given as L0 and L1, respectively. In this example three frames with timestamps x1 - x3 have been lost. The example further assumes that ISF changes once from isf0 to isf1 during the frame loss period, as shown in the figure below.
以下では、無くなっているフレームのタイムスタンプ情報の回復は例の手段で例証されます。 適切にタイムスタンプのt0とt1がある2個のフレームを受け取りました、最初のものによる損失の前の最後のパケットと、損失の期間の後の最初のパケットである後者のものであり。 これらのパケットのためのISF値は、それぞれisf0とisf1です。 これらのフレームのTFIsはそれぞれtfi0とtfi1です。 L0とL1としてそれぞれ、関連フレームの長さ(タイムスタンプカチカチする音における)を与えます。 この例では、3はタイムスタンプでx1を縁どっています--x3はなくされました。 例は、ISFがフレーム損失の期間isf0からisf1までの一度変化するとさらに仮定します、以下の図に示されるように。
Since not all information required for the full recovery of the timestamps is generally known in the receiver, an algorithm is needed to estimate the ISF associated with the lost frames. Also, the number of lost frames needs to be recovered.
タイムスタンプの完全な回復に必要であるというわけではないすべての情報が受信機で一般に知られているので、アルゴリズムが無くなっているフレームに関連しているISFを見積もるのに必要です。 また、無くなっているフレームの数は、回復される必要があります。
Sjoberg, et al. Standards Track [Page 26] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[26ページ]RFC4352RTP有効搭載量形式
|<---L0--->|<---L0--->|<-L1->|<-L1->|<-L1->|
| <。---L0--->| <、-、--L0--->| <、-L1>| <、-L1>| <、-L1>|
| Rxd | lost | lost | lost | Rxd |
--+----------+----------+------+------+------+--
| Rxd| 失われています。| 失われています。| 失われています。| Rxd| --+----------+----------+------+------+------+--
t0 x1 x2 x3 t1
t0 x1 x2 x3 t1
Example Algorithm:
例のアルゴリズム:
Start: # check for frame loss If (t0 + L0) == t1 Then goto End # no frame loss
以下を始めてください。 # フレームの損失If(t0+L0)=t1 Then goto End#がないかどうかフレームの損失を全くチェックしないでください。
Step 1: # check case with no ISF change
If (isf0 != isf1) Then goto Step 2 # At least one ISF change
If (isFractional(t1 - t0)/L0) Then goto Step 3
# More than 1 ISF change
ステップ1: # 1回のISF変化よりISF変化If(isf0!はisf1と等しい)の当時のgoto Step2#At1最少のISF変化If(isFractional(t1--t0)/L0)当時のgoto Step3#Moreなしでケースをチェックしてください。
Return recovered timestamps as x(n) = t0 + n*L1 and associated ISF equal to isf0, for 0 < n < (t1 - t0)/L0 goto End
x(n)がt0+n*L1とisf0と等しい関連ISFと等しいので、リターンはタイムスタンプを回復しました、0<n<(t1--t0)/L0 goto Endのために
Step 2:
Loop initialization: n := 4 - tfi0 mod 4
While n <= (t1-t0)/L0
Evaluate m := (t1 - t0 - n*L0)/L1
If (isInteger(m) AND ((tfi0+n+m) mod 4 == tfi1)) Then goto found;
n := n+4
endloop
goto step 3 # More than 1 ISF change
ステップ2: 初期化を輪にしてください: n:=4--tfi0モッズ4While n<は:=(t1--t0--n*L0)/L1 If(isInteger(m)AND(tfi0+n+m)モッズ4=tfi1)当時のgotoが見つけた(t1-t0)/L0 Evaluate mと等しいです。 n:=n+4endloop gotoは1回のISF変化より3#Moreを踏みます。
found: Return recovered timestamps and ISFs as x(i) = t0 + i*L0 and associated ISF equal to isf0, for 0 < i <= n x(i) = t0 + n*L0 + (i-n)*L1 and associated ISF equal to isf1, for n < i <= n+m goto End
設立します: t0+i*L0とisf0と等しい関連x(i)としてのリターンの回復しているタイムスタンプとISFs=ISF、t0+n*L0+(i-n)n i<=x(i)=*L1と関連ISFがisf1と等しい0<、n<に関して、i<はn+m goto Endと等しいです。
Step 3: More than 1 ISF change has occurred. Since ISF changes can be assumed to be infrequent, such a situation occurs only if long sequences of frames are lost. In that case it is probably not useful to try to recover the timestamps of the lost frames. Rather, the AMR-WB+ decoder should be reset, and decoding should be resumed starting with the frame with timestamp t1.
ステップ3: 1回以上のISF変化が起こりました。 ISF変化が珍しいと思うことができるので、フレームの長いひと続きの出来事が無くなる場合にだけ、そのような状況は起こります。 その場合、無くなっているフレームに関するタイムスタンプを回復しようとするのはたぶん役に立ちません。 むしろ、AMR-WB+デコーダはリセットされるべきです、そして、解読はタイムスタンプt1があるフレームをきっかけに再開されるべきです。
End:
以下を終わらせてください。
Sjoberg, et al. Standards Track [Page 27] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[27ページ]RFC4352RTP有効搭載量形式
The above algorithm still does not solve the issue when the receiver buffer depth is shallower than the loss burst. In this kind of case, where the concealment must be done without any knowledge about future frames, the concealment may result in loss of frame boundary alignment. If that occurs, it may be necessary to reset and restart the codec to perform resynchronization.
受信機バッファの深さが損失がはち切れたより浅いときに、上のアルゴリズムはまだ問題を解決していません。 この種類の場合では、隠すことはフレーム境界合せの損失をもたらすかもしれません。そこでは、将来のフレームに関する少しも知識なしで隠すことをしなければなりません。 それが起こるなら、再同期を実行するためにコーデックをリセットして、再開するのが必要であるかもしれません。
4.5.2. Decoding Validation
4.5.2. 合法化を解読します。
If the receiver finds a mismatch between the size of a received payload and the size indicated by the ToC of the payload, the receiver SHOULD discard the packet. This is recommended because decoding a frame parsed from a payload based on erroneous ToC data could severely degrade the audio quality.
容認されたペイロードのサイズとサイズの間のミスマッチがペイロードのToC、受信機SHOULDで示した受信機掘り出し物がパケットを捨てるなら。 誤ったToCデータに基づくペイロードから分析されたフレームを解読するとオーディオ音質が厳しく下げられるかもしれないので、これはお勧めです。
5. Congestion Control
5. 輻輳制御
The general congestion control considerations for transporting RTP data apply; see RTP [3] and any applicable RTP profile like AVP [9]. However, the multi-rate capability of AMR-WB+ audio coding provides a mechanism that may help to control congestion, since the bandwidth demand can be adjusted (within the limits of the codec) by selecting a different coding frame type or lower internal sampling rate.
RTPデータを輸送するための一般的な輻輳制御問題は適用されます。 AVP[9]のようにRTP[3]とあらゆる適切なRTPプロフィールを見てください。 しかしながら、AMR-WB+オーディオ符号化のマルチレート能力は混雑を制御するのを助けるかもしれないメカニズムを提供します、異なったコード化フレームタイプか下側の内部の標本抽出率を選ぶことによって帯域幅要求を調整できるので(コーデックの限界の中で)。
The number of frames encapsulated in each RTP payload highly influences the overall bandwidth of the RTP stream due to header overhead constraints. Packetizing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness.
それぞれのRTPペイロードで要約されたフレームの数はヘッダーオーバーヘッド規制によるRTPの流れの総合的な帯域幅に非常に影響を及ぼします。 それぞれのRTPペイロードで、より多くのフレームをPacketizingすると、送られたパケットの数としたがって、ヘッダーオーバーヘッドを下げることができます、増加する遅れと減少している誤り丈夫さを犠牲にして。
If forward error correction (FEC) is used, the amount of FEC-induced redundancy needs to be regulated such that the use of FEC itself does not cause a congestion problem.
前進型誤信号訂正(FEC)が使用されているなら、FECによって誘発された冗長の量が、規制される必要があるので、FEC自身の使用は混雑問題を引き起こしません。
6. Security Considerations
6. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile such as AVP [9] or SAVP [10]. As this format transports encoded audio, the main security issues include confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used.
この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP[3]で議論した総合証券問題とAVP[9]かSAVP[10]などのどんな適切なプロフィールも受けることがあります。 この形式がコード化されたオーディオを輸送するとき、主な安全保障問題はオーディオ自体の秘密性、保全保護、およびデータ起源認証を含んでいます。 ペイロード形式自体には、どんな内蔵のセキュリティーメカニズムもありません。SRTP[10]などの適当な外部のどんなメカニズムも使用されるかもしれません。
Sjoberg, et al. Standards Track [Page 28] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[28ページ]RFC4352RTP有効搭載量形式
This payload format and the AMR-WB+ decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data.
このペイロード形式とAMR-WB+デコーダは、パケット処理のために受信機サイド計算量で少しの重要な非の一様性も示さないで、その結果、病理学的なデータの領収書のためサービスの否定の脅威を引き起こしそうにはありません。
6.1. Confidentiality
6.1. 秘密性
In order to ensure confidentiality of the encoded audio, all audio data bits MUST be encrypted. There is less need to encrypt the payload header or the table of contents since they only carry information about the frame type. This information could also be useful to a third party, for example, for quality monitoring.
コード化されたオーディオの秘密性を確実にするために、すべてのオーディオデータ・ビットをコード化しなければなりません。 彼らがフレームタイプの情報を運ぶだけであるのでペイロードヘッダーか目次をコード化するより少ない必要があります。 また、例えば、この情報も上質のモニターで第三者の役に立つかもしれません。
The use of interleaving in conjunction with encryption can have a
negative impact on confidentiality, for a short period of time.
Consider the following packets (in brackets) containing frame numbers
as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular
continuous diagonal interleaving pattern). The originator wishes to
deny some participants the ability to hear material starting at time
16. Simply changing the key on the packet with the timestamp at or
after 16, and denying that new key to those participants, does not
achieve this; frames 17, 18, and 21 have been supplied in prior
packets under the prior key, and error concealment may make the audio
intelligible at least as far as frame 18 or 19, and possibly further.
暗号化に関連したインターリービングの使用は秘密性でマイナスの影響がある場合があります、短期間の間。 示されるようにフレーム番号を含んで、以下のパケット(括弧の)を考えてください: 10、14、18、13、17、21、16、20、24(ポピュラーな連続した対角線のインターリービングパターン)。 創始者は材料が時16に始動するのを聞く能力を何人かの関係者に対して否定したがっています。 16か16時以降パケットでタイムスタンプで単にキーを変えて、それらの関係者のその新しいキーを否定するのはこれを達成しません。 先のパケットで先のキー、および誤りの下、そして、隠すことがフレーム18か19と少なくとも同じくらい遠くに明瞭なオーディオをするかもしれないことによるとさらにフレーム17、18、および21を供給しました。
6.2. Authentication and Integrity
6.2. 認証と保全
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits).
スピーチの送付者を認証するために、外部のメカニズムを使用しなければなりません。 そのようなメカニズムが完全なRTPヘッダーとペイロード(スピーチとデータ・ビット)の両方を保護するのは、RECOMMENDEDです。
Data tampering by a man-in-the-middle attacker could replace audio content and also result in erroneous depacketization/decoding that could lower the audio quality.
中央の男性攻撃者にいじられるデータは、オーディオ音質を下げることができた誤ったdepacketization/解読では、オーディオ内容を置き換えて、また、結果を置き換えるかもしれません。
7. Payload Format Parameters
7. 有効搭載量形式パラメタ
This section defines the parameters that may be used to select features of the AMR-WB+ payload format. The parameters are defined as part of the media type registration for the AMR-WB+ audio codec. A mapping of the parameters into the Session Description Protocol (SDP) [6] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use MIME or SDP.
このセクションはAMR-WB+ペイロード形式の特徴を選択するのに使用されるかもしれないパラメタを定義します。 メディアの一部と定義されて、AMR-WB+オーディオコーデックのための登録をタイプしてください。パラメタはまた、Session記述プロトコル(SDP)[6]へのパラメタに関するマッピングをSDPを使用するそれらのアプリケーションに提供するということです。 同等なパラメタは使用のためのほかの場所でMIMEかSDPを使用しない制御プロトコルで定義されるかもしれません。
The data format and parameters are only specified for real-time transport in RTP.
データの形式とパラメタはRTPのリアルタイムの輸送に指定されるだけです。
Sjoberg, et al. Standards Track [Page 29] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[29ページ]RFC4352RTP有効搭載量形式
7.1. Media Type Registration
7.1. メディアは登録をタイプします。
The media type for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) codec is allocated from the IETF tree, since AMR-WB+ is expected to be a widely used audio codec in general streaming applications.
IETF木からExtended Adaptive Multi-レートWideband(AMR-WB+)コーデックのためのメディアタイプを割り当てて、AMR-WB以来、一般に、アプリケーションを流す広く使用されたオーディオコーデックであると+を予想します。
Note: Parameters not listed below MUST be ignored by the receiver.
以下に注意してください。 受信機で以下にリストアップされなかったパラメタを無視しなければなりません。
Media Type name: audio
メディアTypeは以下を命名します。 オーディオ
Media subtype name: AMR-WB+
メディア「副-タイプ」は以下を命名します。 AMR Wb+
Required parameters:
必要なパラメタ:
None
なし
Optional parameters:
任意のパラメタ:
channels: The maximum number of audio channels used by the
audio frames. Permissible values are 1 (mono) or 2
(stereo). If no parameter is present, the maximum
number of channels is 2 (stereo). Note: When set to
1, implicitly the stereo frame types cannot be used.
チャンネル: オーディオフレームによって使用される音声チャンネルの最大数。 許容値は、1(モノタイプ)か2(ステレオの)です。 どんなパラメタも存在していないなら、チャンネルの最大数は2(ステレオの)です。 以下に注意してください。 1に設定されると、それとなく、ステレオフレームタイプを使用できません。
interleaving: Indicates that interleaved mode SHALL
be used for the payload. The parameter specifies
the number of transport frame slots required in a
deinterleaving buffer (including the frame that is
ready to be consumed). Its value is equal to one
plus the maximum number of frames that precede any
frame in transmission order and follow the frame in
RTP timestamp order. The value MUST be greater than
zero. If this parameter is not present,
interleaved mode SHALL NOT be used.
インターリービング: はさみ込まれたモードSHALLがペイロードに使用されるのを示します。 パラメタは「反-はさみ込」みバッファで必要である輸送フレームスロットの数を指定します(消費される準備ができているフレームを含んでいて)。 値は1とトランスミッション命令でどんなフレームにも先行して、RTPタイムスタンプオーダーでフレームに続くフレームの最大数と等しいです。 値はゼロ以上でなければなりません。 このパラメタが現在の、そして、はさみ込まれたモードSHALL NOTでないなら、使用されてください。
int-delay: The minimal media time delay in RTP timestamp ticks
that is needed in the deinterleaving buffer, i.e.,
the difference in RTP timestamp ticks between the
earliest and latest audio frame present in the
deinterleaving buffer.
int-遅れ: 「反-はさみ込」みバッファで必要である、RTPタイムスタンプカチカチする音の最小量のメディア時間遅れ、すなわち、RTPタイムスタンプの違いは「反-はさみ込」みバッファの現在の最も早くて最新のオーディオフレームの間をチェックします。
ptime: See Section 6 in RFC 2327 [6].
ptime: RFC2327[6]でセクション6を見てください。
maxptime: See Section 8 in RFC 3267 [7].
maxptime: RFC3267[7]でセクション8を見てください。
Restriction on Usage:
This type is only defined for transfer via RTP (STD 64).
用法における制限: このタイプは転送のためにRTP(STD64)を通して定義されるだけです。
Sjoberg, et al. Standards Track [Page 30] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[30ページ]RFC4352RTP有効搭載量形式
Encoding considerations:
An RTP payload according to this format is binary data
and thus may need to be appropriately encoded in non-
binary environments. However, as long as used within
RTP, no encoding is necessary.
問題をコード化します: この形式に従ったRTPペイロードは、2進のデータであり、その結果、非バイナリーの環境で適切にコード化される必要があるかもしれません。 しかしながら、RTPの中で使用されて、コード化は必要ではありません。
Security considerations:
See Section 6 of RFC 4352.
セキュリティ問題: RFC4352のセクション6を見てください。
Interoperability considerations:
To maintain interoperability with AMR-WB-capable end-
points, in cases where negotiation is possible and the
AMR-WB+ end-point supporting this format also supports
RFC 3267 for AMR-WB transport, an AMR-WB+ end-point
SHOULD declare itself also as AMR-WB capable (i.e.,
supporting also "audio/AMR-WB" as specified in RFC
3267).
相互運用性問題: AMR-WBできる終わりのポイントがある相互運用性が交渉が可能であり、またこの形式を支持するAMR-WB+エンドポイントがAMR-WB輸送のためにRFC3267を支持する場合でAMR-WB+エンドポイントであることを支持するために、SHOULDは、AMR-WBとしてもそれ自体ができると(すなわち、また、RFC3267の指定されるとしての「オーディオ/AMR-WB」を支持します)宣言します。
As the AMR-WB+ decoder is capable of performing stereo
to mono conversions, all receivers of AMR-WB+ should be
able to receive both stereo and mono, although the
receiver is only capable of playout of mono signals.
AMR-WB+デコーダができるように、モノタイプ変換、+ができるべきであるAMR-WBのすべての受信機にステレオを実行するのにおいて、ステレオとモノタイプの両方を受けてください、受信機はモノタイプ信号の再生ができるだけですが。
Public specification:
RFC 4352
3GPP TS 26.290, see reference [1] of RFC 4352
公共の仕様: RFC4352 3GPP TS26.290、RFC4352の参照[1]を見てください。
Additional information:
This MIME type is not applicable for file storage.
Instead, file storage of AMR-WB+ encoded audio is
specified within the 3GPP-defined ISO-based multimedia
file format defined in 3GPP TS 26.244; see reference
[14] of RFC 4352. This file format has the MIME types
"audio/3GPP" or "video/3GPP" as defined by RFC 3839
[15].
追加情報: ファイル記憶装置には、このMIMEの種類は適切ではありません。 代わりに、AMR-WB+コード化されたオーディオのファイル記憶装置は3GPP TS26.244で定義された3GPPによって定義されたISOベースのマルチメディアファイル形式の中で指定されます。 RFC4352の参照[14]を見てください。 このファイル形式に、MIMEの種類「オーディオ/3GPP」か「ビデオ/3GPP」がRFC3839[15]によって定義されるようにあります。
Person & email address to contact for further information:
magnus.westerlund@ericsson.com
ari.lakaniemi@nokia.com
詳細のために連絡する人とEメールアドレス: magnus.westerlund@ericsson.com ari.lakaniemi@nokia.com
Intended usage: COMMON.
It is expected that many IP-based streaming
applications will use this type.
意図している用法: 一般的。 多くのIPベースのストリーミング・アプリケーションがこのタイプを使用すると予想されます。
Change controller:
IETF Audio/Video Transport working group delegated from
the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
Sjoberg, et al. Standards Track [Page 31] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[31ページ]RFC4352RTP有効搭載量形式
7.2. Mapping Media Type Parameters into SDP
7.2. メディア型引数をSDPに写像します。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [6], which is commonly used to describe RTP sessions. When SDP is used to specify an RTP session using this RTP payload format, the mapping is as follows:
仕様が特定のマッピングを持っているメディアタイプで運ばれた情報はSession記述プロトコル(SDP)で[6]をさばきます。([6]は、RTPセッションについて説明するのに一般的に使用されます)。 SDPがこのRTPペイロード形式を使用することでRTPセッションを指定するのに使用されるとき、マッピングは以下の通りです:
- The media type ("audio") is used in SDP "m=" as the media name.
- メディアタイプ(「オーディオ」)はメディア名としてSDP「m=」で使用されます。
- The media type (payload format name) is used in SDP "a=rtpmap" as
the encoding name. The RTP clock rate in "a=rtpmap" SHALL be
72000 for AMR-WB+, and the encoding parameter number of channels
MUST either be explicitly set to 1 or 2, or be omitted, implying
the default value of 2.
- メディアタイプ(ペイロード形式名)はコード化名としてSDP"a=rtpmap"で使用されます。 RTPがAMR-WBのための72000が+であったなら"a=rtpmap"SHALLでレートの時間を計って、チャンネルのコード化しているパラメタ番号を明らかに1か2に設定されなければならないか、または省略しなければなりません、2のデフォルト値を含意して。
- The parameters "ptime" and "maxptime" are placed in the SDP
attributes "a=ptime" and "a=maxptime", respectively.
- パラメタの"ptime"と"maxptime"はそれぞれSDP属性"a=ptime"と"a=maxptime"に置かれます。
- Any remaining parameters are placed in the SDP "a=fmtp" attribute
by copying them directly from the MIME media type string as a
semicolon-separated list of parameter=value pairs.
- どんな残っているパラメタも、パラメタ=価値のセミコロンで切り離されたリストが対にされるので直接メディアタイプが結ぶMIMEからそれらをコピーすることによって、SDP"a=fmtp"属性に置かれます。
7.2.1. Offer-Answer Model Considerations
7.2.1. 申し出答えモデル問題
To achieve good interoperability in an Offer-Answer [8] negotiation usage, the following considerations should be taken into account:
Offer-答え[8]交渉用法で良い相互運用性を達成するために、以下の問題は考慮に入れられるべきです:
For negotiable offer/answer usage the following interpretation rules SHALL be applied:
交渉可能な申し出/答え用法のために、適用されていて、以下の解釈はSHALLを統治します:
- The "interleaving" parameter is symmetric, thus requiring that the
answerer must also include it for the answer to an offered payload
type that contains the parameter. However, the buffer space value
is declarative in usage in unicast. For multicast usage, the same
value in the response is required in order to accept the payload
type. For streams declared as sendrecv or recvonly: The receiver
will accept reception of streams using the interleaved mode of the
payload format. The value declares the amount of buffer space the
receiver has available for the sender to utilize. For sendonly
streams, the parameter indicates the desired configuration and
amount of buffer space. An answerer is RECOMMENDED to respond
using the offered value, if capable of using it.
- 「インターリービング」パラメタは左右対称です、その結果、また、answererがパラメタを含む提供されたペイロードタイプの答えのためにそれを含まなければならないのが必要です。 しかしながら、バッファ領域値はユニキャストにおける用法で叙述的です。 マルチキャスト用法において、応答における同じ値が、ペイロードタイプを受け入れるのに必要です。 sendrecvかrecvonlyとして申告された流れのために: 受信機は、ペイロード形式のはさみ込まれたモードを使用することで流れのレセプションを受け入れるでしょう。 値は受信機が送付者が利用するように利用可能にするバッファ領域の量を宣言します。 sendonlyの流れのために、パラメタは必要な構成と量のバッファ領域を示します。 それを使用できるなら、answererは提供された値を使用することで応じるRECOMMENDEDです。
Sjoberg, et al. Standards Track [Page 32] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[32ページ]RFC4352RTP有効搭載量形式
- The "int-delay" parameter is declarative. For streams declared as
sendrecv or recvonly, the value indicates the maximum initial
delay the receiver will accept in the deinterleaving buffer. For
sendonly streams, the value is the amount of media time the sender
desires to use. The value SHOULD be copied into any response.
- 「int-遅れ」パラメタは叙述的です。 sendrecvかrecvonlyとして申告された流れのために、値は受信機が「反-はさみ込」みバッファで受け入れる最大の初期の遅れを示します。 sendonlyの流れのために、値は送付者が費やすことを望んでいるメディア時間の量です。 SHOULDを評価してください。どんな応答にもコピーされます。
- The "channels" parameter is declarative. For "sendonly" streams,
it indicates the desired channel usage, stereo and mono, or mono
only. For "recvonly" and "sendrecv" streams, the parameter
indicates what the receiver accepts to use. As any receiver will
be capable of receiving stereo frame type and perform local mixing
within the AMR-WB+ decoder, there is normally only one reason to
restrict to mono only: to avoid spending bit-rate on data that are
not utilized if the front-end is only capable of mono.
- 「チャンネル」パラメタは叙述的です。 "sendonly"の流れのために、それは必要なチャンネル用法かステレオとモノタイプか、モノタイプだけを示します。 "recvonly"と"sendrecv"の流れのために、パラメタは受信機が使用に受け入れるものを示します。 どんな受信機もステレオフレームタイプを受けることができて、AMR-WB+デコーダの中の地方の混合を実行するとき、通常、モノタイプだけに制限する1つの理由しかありません: データにビット伝送速度を費やすのを避けるために、フロントエンドはモノタイプができるだけであるなら、それが利用されていません。
- The "ptime" parameter works as indicated by the offer/answer model
[8]; "maxptime" SHALL be used in the same way.
- 申し出/答えモデル[8]によって示されるように"ptime"パラメタは働いています。 SHALLは中古のコネが同じ道であったなら"maxptimeする"です。
- To maintain interoperability with AMR-WB in cases where
negotiation is possible, an AMR-WB+ capable end-point that also
implements the AMR-WB payload format [7] is RECOMMENDED to declare
itself capable of AMR-WB as it is a subset of the AMR-WB+ codec.
- 場合における交渉が可能であるAMR-WBと共に相互運用性を維持するなら、また、AMR-WBペイロード形式[7]を実行するAMR-WB+できるエンドポイントはそれがAMR-WB+コーデックの部分集合であるのでそれ自体はAMR-WBができると宣言するRECOMMENDEDです。
In declarative usage, like SDP in RTSP [16] or SAP [17], the following interpretation of the parameters SHALL be done:
叙述的な用法、RTSP[16]かSAP[17]における同様のSDP、パラメタSHALLの以下の解釈、してください:
- The "interleaving" parameter, if present, configures the payload
format in that mode, and the value indicates the number of frames
that the deinterleaving buffer is required to support to be able
to handle this session correctly.
- 存在しているなら、「インターリービング」パラメタはそのモードによるペイロード書式を構成します、そして、値は「反-はさみ込」みバッファが支持しなければならないフレームの数が正しくこのセッションを扱うことができるのを示します。
- The "int-delay" parameter indicates the initial buffering delay
required to receive this stream correctly.
- 「int-遅れ」パラメタは遅れが正しくこの流れを受けるのを必要とした初期のバッファリングを示します。
- The "channels" parameter indicates if the content being
transmitted can contain either both stereo and mono rates, or only
mono.
- 「チャンネル」パラメタは、伝えられる内容がステレオとモノタイプレートの両方かモノタイプのどちらかしか含むことができないかどうかを示します。
- All other parameters indicate values that are being used by the
sending entity.
- 他のすべてのパラメタが送付実体によって使用されている値を示します。
Sjoberg, et al. Standards Track [Page 33] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[33ページ]RFC4352RTP有効搭載量形式
7.2.2. Examples
7.2.2. 例
One example of an SDP session description utilizing AMR-WB+ mono and stereo encoding follows.
AMR-WB+モノタイプを利用するSDPセッション記述とステレオコード化に関する1つの例が従います。
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB+/72000/2
a=fmtp:99 interleaving=30; int-delay=86400
a=maxptime:100
オーディオの49120RTP/AVP99m=a=rtpmap: 99 AMR-WB+/72000/2a=fmtp: 99 インターリービング=30。 86400int-遅れ=a=maxptime: 100
Note that the payload format (encoding) names are commonly shown in uppercase. Media subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute.
ペイロード形式(コード化する)名が大文字で一般的に示されることに注意してください。 メディア血液型亜型では、一般的に小文字で目立ちます。 これらの名前は両方の場所で大文字と小文字を区別しないです。 同様に、パラメタ名はMIMEの種類とデフォルトマッピングでSDP a=fmtp属性に大文字と小文字を区別しないです。
8. IANA Considerations
8. IANA問題
The IANA has registered one new MIME subtype (audio/amr-wb+); see Section 7.
IANAは1つの新しいMIME「副-タイプ」(オーディオ/amr-wb+)を登録しました。 セクション7を見てください。
9. Contributors
9. 貢献者
Daniel Enstrom has contributed in writing the codec introduction section. Stefan Bruhn has contributed by writing the ISF recovery algorithm.
ダニエルEnstromはコーデック序論部に書く際に貢献しました。 ステファン・ブルーンは、ISF回復アルゴリズムを書くことによって、貢献しました。
10. Acknowledgements
10. 承認
The authors would like to thank Redwan Salami and Stefan Bruhn for their significant contributions made throughout the writing and reviewing of this document. Dave Singer contributed by reviewing and suggesting improved language. Anisse Taleb and Ingemar Johansson contributed by implementing the payload format and thus helped locate some flaws. We would also like to acknowledge Qiaobing Xie, coauthor of RFC 3267, on which this document is based.
作者はこのドキュメントの書くことと論評の間中された彼らの重要な貢献についてRedwan Salamiとステファン・ブルーンに感謝したがっています。 デーヴSingerは、改良された言語を見直して、示すことによって、貢献しました。 Anisseタレビとインゲマー・ヨハンソンは、ペイロード形式を実行することによって貢献して、その結果、いくつかの欠点の場所を見つけるのを助けました。 また、Qiaobingシェ、RFC3267の共著者を承認したいと思います。(このドキュメントはその共著者に基づいています)。
Sjoberg, et al. Standards Track [Page 34] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[34ページ]RFC4352RTP有効搭載量形式
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] 3GPP TS 26.290 "Audio codec processing functions; Extended
Adaptive Multi-Rate Wideband (AMR-WB+) codec; Transcoding
functions", version 6.3.0 (2005-06), 3rd Generation Partnership
Project (3GPP).
[1]3GPP TS26.290「オーディオコーデック処理機能」。 拡張Adaptive Multi-レートWideband(AMR-WB+)コーデック。 「コード変換機能」、バージョン6.3.0(2005-06)、第3Generation Partnership Project(3GPP)。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[4] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise
aspects", version 6.0.0 (2004-12), 3rd Generation Partnership
Project (3GPP).
[4] 3GPP TS26.192「AMR Widebandスピーチコーデック」。 「安らぎNoise局面」、バージョン6.0.0(2004-12)、第3Generation Partnership Project(3GPP)。
[5] 3GPP TS 26.193 "AMR Wideband speech codec; Source Controlled
Rate operation", version 6.0.0 (2004-12), 3rd Generation
Partnership Project (3GPP).
[5] 3GPP TS26.193「AMR Widebandスピーチコーデック」。 「ソースControlled Rate操作」、バージョン6.0.0(2004-12)、第3Generation Partnership Project(3GPP)。
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[7] 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.
[7] シェーベリ、J.、Westerlund、M.、Lakaniemi、A.、およびQ.シェ、「本当の時間トランスポート・プロトコル(RTP)有効搭載量形式とファイル記憶装置は適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)にオーディオコーデックをフォーマットします」、RFC3267、2002年6月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[9] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
11.2. Informative References
11.2. 有益な参照
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[10]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[11] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[11] ローゼンバーグとJ.とH.Schulzrinne、「一般的な前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
Sjoberg, et al. Standards Track [Page 35] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[35ページ]RFC4352RTP有効搭載量形式
[12] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[12] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。
[13] 3GPP TS 26.233 "Packet Switched Streaming service", version
5.7.0 (2005-03), 3rd Generation Partnership Project (3GPP).
[13] 3GPP TS26.233「パケットSwitched Streamingサービス」、バージョン5.7.0(2005-03)、第3Generation Partnership Project(3GPP)。
[14] 3GPP TS 26.244 "Transparent end-to-end packet switched streaming
service (PSS); 3GPP file format (3GP)", version 6.4.0 (2005-09),
3rd Generation Partnership Project (3GPP).
[14] 3GPP TS26.244「終わりから終わりに対するパケットわかりやすい切り換えられたストリーミングのサービス(PSS)」。 「3GPPファイル形式(3GP)」、バージョン6.4.0(2005-09)、第3Generation Partnership Project(3GPP)。
[15] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
Generation Partnership Project (3GPP) Multimedia files", RFC
3839, July 2004.
[15] カスターニョ、研究開発Singer、「第3Generation Partnership Project(3GPP)マルチメディアのためのMIMEの種類Registrationsはファイルします」、RFC3839、2004年7月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[16]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[17] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[17] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[18] 3GPP TS 26.140 "Multimedia Messaging Service (MMS); Media
formats and codes", version 6.2.0 (2005-03), 3rd Generation
Partnership Project (3GPP).
[18] 3GPP t26.140「マルチメディア・メッセージング・サービス(MMS)」。 「メディア形式とコード」、バージョン6.2 .0 (2005-03)、第3Generation Partnership Project(3GPP)。
[19] 3GPP TS 26.140 "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", version 6.3.0 (2005-12), 3rd Generation
Partnership Project (3GPP).
[19] 「マルチメディア放送/マルチキャストは修理(MBMS)」3GPP t26.140。 「プロトコルとコーデック」、バージョン6.3 .0 (2005-12)、第3Generation Partnership Project(3GPP)。
Any 3GPP document can be downloaded from the 3GPP webserver, "http://www.3gpp.org/", see specifications.
3GPP webserverからダウンロードできる3GPPが、ドキュメントであるいずれ" http://www.3gpp.org/ "も仕様を見ます。
Sjoberg, et al. Standards Track [Page 36] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[36ページ]RFC4352RTP有効搭載量形式
Authors' Addresses
作者のアドレス
Johan Sjoberg Ericsson Research Ericsson AB SE-164 80 Stockholm SWEDEN
ジョハンシェーベリエリクソン研究エリクソンAB SE-164 80ストックホルムスウェーデン
Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: Johan.Sjoberg@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm SWEDEN
マグヌスWesterlundエリクソン研究エリクソンAB SE-164 80ストックホルムスウェーデン
Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: Magnus.Westerlund@ericsson.com
Ari Lakaniemi Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group FINLAND
アリLakaniemiノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com
以下に電話をしてください。 +358-71-8008000はメールされます: ari.lakaniemi@nokia.com
Stephan Wenger Nokia Corporation P.O. Box 100 FIN-33721 Tampere FINLAND
シュテファンウェンガーノキア社の私書箱100フィン-33721タンペレフィンランド
Phone: +358-50-486-0637 EMail: Stephan.Wenger@nokia.com
以下に電話をしてください。 +358-50-486-0637 メールしてください: Stephan.Wenger@nokia.com
Sjoberg, et al. Standards Track [Page 37] RFC 4352 RTP Payload Format for AMR-WB+ January 2006
シェーベリ、他 2006年AMR-WB+1月のための標準化過程[37ページ]RFC4352RTP有効搭載量形式
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)によって提供されます。
Sjoberg, et al. Standards Track [Page 38]
シェーベリ、他 標準化過程[38ページ]
一覧
スポンサーリンク
