Internet Engineering Task Force (IETF) S. Ikonin
Request for Comments: 6262 SPIRIT DSP
Category: Standards Track August 2011
ISSN: 2070-1721
RTP Payload Format for IP-MR Speech Codec
Abstract
抽象
This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors.
この文書では、リアルタイムトランスポートプロトコル（RTP）へのSPIRIT IP-MR符号化された音声信号のパケットのペイロード形式を指定します。ペイロード・フォーマットは、パケットごとに複数のフレームの送信をサポートし、パケット損失、ビット誤りに対するロバスト性のための冗長性を導入します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6262.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6262で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................2
2. IP-MR Codec Description .........................................3
3. Payload Format ..................................................4
3.1. RTP Header Usage ...........................................4
3.2. RTP Payload Structure ......................................4
3.3. Speech Payload Header ......................................5
3.4. Speech Payload Table of Contents ...........................6
3.5. Speech Payload Data ........................................6
3.6. Redundancy Payload Header ..................................7
3.7. Redundancy Payload Table of Contents .......................8
3.8. Redundancy Payload Data ....................................8
4. Payload Examples ................................................9
4.1. Payload Carrying a Single Frame ............................9
4.2. Payload Carrying Multiple Frames with Redundancy ..........10
5. Congestion Control .............................................11
6. Security Considerations ........................................12
7. Payload Format Parameters ......................................13
7.1. Media Type Registration ...................................13
7.2. Mapping Media Type Parameters into SDP ....................14
8. IANA Considerations ............................................14
9. Normative References ...........................................15
Appendix A. Retrieving Frame Information ..........................16
A.1. get_frame_info.c ..........................................16
This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors.
この文書では、リアルタイムトランスポートプロトコル（RTP）へのSPIRIT IP-MR符号化された音声信号のパケットのペイロード形式を指定します。ペイロード・フォーマットは、パケットごとに複数のフレームの送信をサポートし、パケット損失、ビット誤りに対するロバスト性のための冗長性を導入します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
IP-MR is a wideband speech codec designed by SPIRIT for conferencing services over packet-switched networks such as the Internet.
IP-MRは、インターネットなどのパケット交換ネットワーク上で会議サービス用SPIRITによって設計された広帯域音声コーデックです。
IP-MR is a scalable codec. This means that the source not only has the ability to change transmission rate on the fly, but the gateway is also able to decrease bandwidth at any time without performance overhead. There are 6 coding rates from 7.7 to 34.2 kbps available.
IP-MRは、スケーラブルコーデックです。これは、ソースは、オンザフライで、伝送レートを変更する能力を有するだけでなく、ゲートウェイは、パフォーマンス・オーバーヘッドなしに、随時、帯域幅を減少させることができることを意味します。利用できる7.7 34.2へkbpsのから6つの符号化レートがあります。
The codec operates on a frame-by-frame basis with a frame size of 20 ms at a 16 kHz sampling rate with a total end-to-end delay of 25 ms. Each compressed frame is represented as a sequence of layers. The first (base) layer is mandatory while the other (enhancement) layers can be safely discarded. Information about the particular frame structure is available from the payload header. In order to adjust outgoing bandwidth, the gateway MUST read the frame(s) structure from the payload header, define which enhancement layers to discard, and compose a new RTP packet according to this specification.
コーデックは、25ミリ秒の合計のエンドツーエンド遅延で16 kHzのサンプリングレートで20ミリ秒のフレームサイズのフレーム毎に動作します。各圧縮フレームは、一連の層として表されます。他の（拡張）レイヤを安全に廃棄することができるが、最初の（ベース）層が必須です。特定のフレーム構造に関する情報は、ペイロードヘッダから入手可能です。送信帯域幅を調整するために、ゲートウェイは、ペイロードヘッダからフレーム（S）構造を読み出す層は廃棄し、そして本明細書によれば、新たなRTPパケットを構成するためにどの拡張を定義しなければなりません。
In fact, not all bits within a frame are equally tolerant to distortion. IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any damage of class 'A' bits causes significant reconstruction artifacts while the loss in class 'F' may not even be perceived by the listener. Note that only the base layer in a bitstream is represented as a set of classes.
実際には、フレーム内の全てのビットが歪みに等しく許容されます。ビットエラーに対する感度の - IP-MRは、6クラス（ 'F' 'A'）を画定します。クラス「F」の損失をも聴取者によって知覚されないかもしれないが 'ビットクラスの任意の損傷が著しい再構成アーチファクトを引き起こします。ビットストリームにのみ下地層クラスのセットとして表されることに留意されたいです。
The IP-MR payload format allows frame duplication through the packets to improve robustness against packet loss (Section 3.6). The base layer can be retransmitted completely or in several sensitive classes. Enchantment layers are not retransmittable.
IP-MRペイロードフォーマットは、パケットロス（3.6節）に対するロバスト性を向上させるためにパケットを介してフレームの複製を可能にします。ベース層は、完全に、またはいくつかの敏感なクラスで再送信することができます。エンチャント層は再送ではありません。
The fine-grained redundancy in conjunction with bitrate scalability allows applications to adjust the trade-off between overhead and robustness against packet loss. Note that this approach is supported natively within a packet and requires no out-of-band signals or session-initialization procedures.
ビットレートスケーラビリティと併せてきめ細かい冗長性は、アプリケーションがオーバーヘッドとパケット損失に対するロバスト性の間のトレードオフを調整することを可能にします。このアプローチは、パケット内でネイティブにサポートされない帯域外信号またはセッション初期化手順を必要としないことに注意してください。
The main IP-MR features are as follows:
次のようにメインIP-MRの機能は次のとおりです。
o High-quality wideband speech codec.
O高品質の広帯域音声コーデック。
o Bitrate scalable with 6 average rates from 7.7 to 34.2 kbps.
7.7 34.2へkbpsのから6つの平均レートとOビットレートスケーラブルな。
o Built-in discontinuous transmission (DTX) and comfort noise generation (CNG) support.
O内蔵不連続送信（DTX）と快適ノイズ発生（CNG）のサポート。
o Flexible in-band redundancy control scheme for packet-loss protection.
パケット損失保護のためのO柔軟な帯域内の冗長制御方式。
The payload format consists of the RTP header and the IP-MR payload.
ペイロード・フォーマットは、RTPヘッダとIP-MRペイロードから成ります。
The format of the RTP header is specified in [RFC3550]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダのフォーマットは、[RFC3550]で指定されています。このペイロードフォーマットは、その仕様と一致する方法で、ヘッダのフィールドを使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency SHALL be 16 kHz. The duration of one frame is 20 ms, which corresponds to 320 samples per frame. Thus, the timestamp is increased by 320 for each consecutive frame. The timestamp is also used to recover the correct decoding order of the frame-blocks.
RTPタイムスタンプは、パケットの最初のフレームのブロックについて符号化された第1のサンプルのサンプリング時点に対応します。タイムスタンプクロック周波数は16 kHzでなければなりません。 1つのフレームの持続時間は、フレーム当たり320個のサンプルに対応する20ミリ秒です。従って、タイムスタンプは、各連続フレーム320だけ増加されます。タイムスタンプは、フレームブロックの正しい復号化順序を回復するために使用されます。
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame-block carried in the packet is the first frame-block in a talkspurt (see definition of talkspurt in Section 4.1 of [RFC3551]). For all other packets, the marker bit SHALL be set to zero (M=0).
パケットで運ばれた最初のフレームブロックは、（[RFC3551]のセクション4.1でトークスパートの定義を参照）有音部の先頭フレームのブロックであるときはいつでも。RTPヘッダのマーカービット（M）が1に設定されます他のすべてのパケットのために、マーカービットがゼロ（M = 0）に設定されなければなりません。
The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format. This is basically necessary because the payload type expresses the configuration of the payload itself, i.e., basic or interleaved mode, and the number of channels carried.
このメモで定義されたフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外です。使用中のRTPプロファイルは、現在、このペイロード形式のための動的ペイロードタイプを結合義務付けます。ペイロードタイプは、ペイロード自体、すなわち、塩基性またはインターリーブモード、及び実施チャネルの数の構成を表すので、これは基本的に必要です。
The remaining RTP header fields are used as specified in [RFC3550].
残りのRTPヘッダフィールドは、[RFC3550]で指定されるように使用されています。
The IP-MR payload is composed of two payloads, one for current speech and one for redundancy. Both payloads are represented in this form: Header, Table of Contents (TOC), and Data. Redundancy payload carries data for preceding and pre-preceding packets.
IP-MRペイロードは、二つのペイロード、現在の音声用と冗長性のための1つから構成されています。両方のペイロードは、この形式で表現されている：ヘッダ、目次（TOC）、およびデータ。冗長ペイロードは、前とプレ先行パケットのデータを搬送します。
+--------+-----+----------------------+- - - - +- - +- - - - - +
| Header | TOC | Data | Header | TOC | Data |
+--------+-----+----------------------+- - - - +- - +- - - - - +
|<- Speech -------------------------->|<- Redundancy (opt) ---->|
This header carries parameters that are common for all frames in the packet:
このヘッダは、パケット内のすべてのフレームに共通のパラメータを運びます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+
|T| CR | BR |D|A|GR |R|
+-+-+-+-+-+-+-+-+-+-+-+-+
o T (1 bit): Reserved. MUST always be set to 0. Receiver MAY discard packet if the 'T' bit is not equal to 0.
O T（1ビット）：予約。常に「T」ビットが0に等しくない場合にパケットを捨てるかもしれ0レシーバに設定しなければなりません。
o CR (3 bits): Coding rate index - top enchantment layer available. The CR value 7 (NO_DATA) indicates that there is no speech data (and thus no speech TOC) in the payload. This MAY be used to transmit redundancy data only.
O CR（3ビット）：符号化率インデックス - 利用可能なトップエンチャント層。 CR値7（NO_DATA）はペイロードには音声データ（したがって無音声TOC）が存在しないことを示しています。これは、冗長データのみを送信するために使用されるかもしれません。
o BR (3 bits): Base rate index - base layer bitrate. Speech payload can be scaled to any rate index between BR and CR. Packets with BR = 6 or BR > CR MUST be discarded. Redundancy data is also considered to have a base rate of BR.
O BR（3ビット）：ベースレートインデックス - ベースレイヤビットレート。音声ペイロードは、BRとCRとの間の任意の速度指数にスケーリングすることができます。 BR = 6またはBR> CRを持つパケットは廃棄されなければなりません。冗長データは、BRの基準金利を持っていると考えられています。
o D (1 bit): Reserved. MUST always be set to 1. Receiver MAY discard packet if the 'D' bit is zero.
O D（1ビット）：予約。常に「D」ビットがゼロの場合、パケットを捨てるかもしれ1. Receiverに設定しなければなりません。
o A (1 bit): Byte alignment. The value of 1 specifies that padding bits were added to enable each compressed frame (3.5) to start with the byte (8-bit) boundary. The value of 0 specifies unaligned frames. Note that the speech payload is always padded to the byte boundary independently on an 'A' bit value.
O（1ビット）：バイトアライメント。 1の値は、パディングビットがバイト（8ビット）境界で開始するように各圧縮フレーム（3.5）を可能にするために追加されたことを指定します。 0の値は、非整列フレームを指定します。音声ペイロードは常に独立「」ビットの値にバイト境界に水増しされていることに注意してください。
o GR (2 bits): Number of frames in packet (grouping size). Actual grouping size is GR + 1; thus, the maximum grouping supported is 4.
パケット内のフレーム数（グループサイズ）：（2ビット）GR O。実際のグループサイズはGR + 1です。したがって、サポートされる最大のグループは4です。
o R (1 bit): Redundancy presence. Value of 1 indicates redundancy payload presence.
O R（1ビット）：冗長プレゼンス。 1の値は、冗長ペイロードの存在を示しています。
Note that the values of 'T' and 'D' bits are fixed; any other values are not allowed by specification. Padding bits ('P' bits) MUST always be set to zero.
「T」の値及び「D」ビットが固定されていることに留意されたいです。他の値は仕様によって許可されていません。パディングビット（「P」ビット）は常にゼロに設定しなければなりません。
The following table defines the mapping between rate index and rate value:
次の表は、レートインデックスおよびレート値との間のマッピングを定義します。
+------------+--------------+
| rate index | avg. bitrate |
+------------+--------------+
| 0 | 7.7 kbps |
| 1 | 9.8 kbps |
| 2 | 14.3 kbps |
| 3 | 20.8 kbps |
| 4 | 27.9 kbps |
| 5 | 34.2 kbps |
| 6 | (reserved) |
| 7 | NO_DATA |
+------------+--------------+
The value of 6 is reserved. If receiving this value, the packet MUST be discarded.
6の値が予約されています。この値を受信した場合、パケットは捨てなければなりません。
The speech TOC is a bitmask indicating the presence of each frame in the packet. TOC is only available if the 'CR' value is not equal to 7 (NO_DATA).
音声TOCは、パケット内の各フレームの存在を示すビットマスクです。 「CR」値が7（NO_DATA）に等しくない場合TOCにのみ使用可能です。
0 1 2 3
+-+-+-+-+
|E|E|E|E|
+-+-+-+-+
|<----->| <-- #(GR+1)
o E (1 bit): Frame existence indicator. The value of 0 indicates speech data is not present for the corresponding frame. The IP-MR encoder sets the 'E' flag to 0 for the periods of silence in DTX mode. Applications MUST set this bit to 0 if the frame is known to be damaged.
O E（1ビット）：フレーム存在インジケータ。 0の値は、音声データは、対応するフレームのために存在しないことを示します。 IP-MRエンコーダがDTXモードで沈黙の期間を0に「E」フラグを設定します。フレームが損傷することが知られている場合アプリケーションはこのビットを0に設定しなければなりません。
Speech data contains (GR+1) compressed IP-MR frames (20 ms of data). A compressed frame has a length of zero if the corresponding TOC flag is zero.
音声データは、（GR + 1）圧縮されたIP-MRフレーム（データの20ミリ秒）を含みます。対応するTOCフラグがゼロであれば、圧縮フレームは、ゼロの長さを有します。
The beginning of each compressed frame is aligned if the 'A' bit is nonzero, while the end of the speech payload is always aligned to a byte (8-bit) boundary:
各圧縮フレームの開始は、音声ペイロードの端部は常にバイト（8ビット）境界に整列されながら「」ビットがゼロでない場合に整列されます。
+- - -+------------+------------+------------+------------+
| TOC | Frame1 | Frame2 | Frame3 | Frame4 |
+- - -+------------+------------+------------+------------+ ALWAYS
|<- aligned |<- aligned |<- aligned |<- aligned |<- ALIGNED
Marked regions MUST be padded only if the 'A' bit is set to '1'.
マークされた領域は、「」ビットが「1」に設定されている場合にのみパディングされなければなりません。
The compressed frame structure is as follows:
次のように圧縮されたフレーム構造です。
|<---- sensitive classes ------>|<----- enchantment layers -------->|
+-------------------------------+----+-----+------+- - - - - +------+
| L1 (Base Layer) | L2 | L3 | L4 | | LN |
+-------------------------------+----+-----+------+- - - - - +------+
|<- A --->|<- B ->| ... |<- F ->| |
|<- BR rate ------------------->| |
|<- CR rate ------------------------------------------------------->|
Appendix A of this document provides a helper routine written in "C" that MUST be used to extract sensitivity classes and bounds for the enchantment layers from the compressed frame data.
この文書の付録Aは、圧縮フレームデータからエンチャント層に対して感度クラスと境界を抽出するために使用されなければならない「C」で記述されたヘルパールーチンを提供します。
The redundancy payload presence is signaled by the 'R' bit of the speech payload header. The redundancy header is composed of two fields of 3 bits each:
冗長ペイロード存在が音声ペイロードヘッダの「R」ビットによってシグナリングされます。冗長ヘッダは3ビットずつの2つのフィールドから構成されています。
0 1 2 3 4 5
+-+-+-+-+-+-+
| CL1 | CL2 |
+-+-+-+-+-+-+
The 'CL1' and 'CL2' fields both specify the sensitivity classes available for preceding and pre-preceding packets respectively.
「CL1」および「CL2」フィールドの両方をそれぞれのパケットに先行し、プレ先行のために利用可能な感度クラスを指定します。
+-------+--------------------+
| CL | Redundancy classes |
| | available |
+-------+--------------------+
| 0 | NONE |
| 1 | A |
| 2 | A-B |
| 3 | A-C |
| 4 | A-D |
| 5 | A-E |
| 6 | A-F |
| 7 | (reserved) |
+-------+--------------------+
A receiver can reconstruct the base layer of preceding packets completely (CL=6) or partially (0<CL< 6) based on the sensitivity classes delivered. A decoder MUST discard the redundancy payload if 'CL' is equal to 0 or 7.
受信機は、完全に（CL = 6）に先行するパケットのベース層を再構成する、または部分的に（0 <CL <6）送達感度クラスに基づくことができます。 「CL」は0または7に等しい場合、デコーダは、冗長ペイロードを廃棄しなければなりません。
Note that the index of the base rate and grouping parameter is not transmitted for the redundancy payload. Applications MUST assume that 'BR' and 'GR' are the same as for the current packet.
基本レートのインデックスとグループ化パラメータは冗長ペイロードに送信されないことに留意されたいです。アプリケーションは、「BR」と「GR」は、現在のパケットの場合と同じであると仮定しなければなりません。
The redundancy TOC is a bitmask indicating the presence of each frame in the redundancy payload. The redundancy TOC is only available if the 'CL' value is not equal to 0 or 7.
冗長TOCは、冗長ペイロード内の各フレームの存在を示すビットマスクです。 「CL」の値が0または7に等しくない場合冗長TOCにのみ使用可能です。
0 1 ...
+-+-+-+-+-+-+-+-+
|E|E|E|E|E|E|E|E|
+-+-+-+-+-+-+-+-+
| |<----->| pre-preceding payload #(GR+1)
|<----->| preceding payload #(GR+1)
o E (1 bit): Redundancy frame existence indicator. The value of 0 indicates redundancy data is not present for corresponding frame.
O E（1ビット）：冗長フレームの存在インジケータ。 0の値は、冗長データがフレームに対応するために存在していないことを示します。
IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any damage of class 'A' bits causes significant reconstruction artifacts while the loss in class 'F' may not even be perceived by the listener. Note that only the base layer in a bitstream is represented as a set of classes. Together, the sensitivity classes' approach and redundancy allow IP-MR duplicate frames through the packets to improve robustness against packet loss.
ビットエラーに対する感度の - IP-MRは、6クラス（ 'F' 'A'）を画定します。クラス「F」の損失をも聴取者によって知覚されないかもしれないが 'ビットクラスの任意の損傷が著しい再構成アーチファクトを引き起こします。ビットストリームにのみ下地層クラスのセットとして表されることに留意されたいです。一緒に、感度クラスアプローチと冗長性がIP-MRは、パケット損失に対するロバスト性を向上させるために、パケットを通じてフレームを複製できます。
Redundancy data carries a number of sensitivity classes for preceding and pre-preceding packets as indicated by the 'CL1' and 'CL2' fields of the redundancy header. The sensitivity classes' data is available individually for each frame only if the corresponding 'E' bit of the redundancy TOC is nonzero:
冗長データは、「CL1」と冗長ヘッダの「CL2」フィールドによって示されるように、パケットを前後プレ先行の感度クラスの数を運びます。感度クラス冗長TOCのE 『ビットゼロでのデータは、対応する場合にのみフレーム毎に個別に利用可能です』：
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|A-C|A-B|1000|1001|cl_A1|cl_B1|cl_C1|cl_A1|cl_B1|cl_A4|cl_B4|
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|<- CL >|<- TOC ->|<- preceding --->|<- pre-preceding ----->|
Redundancy data is only available if the base rates (BRs) and coding rates (CRs) of preceding and pre-preceding packets are the same as for the current packet.
基本料金（のBR）及び前後プレ先行するパケットの符号化率（CRS）は、現在のパケットと同じである場合に冗長データのみが利用可能です。
A receiver MAY use redundancy data to compensate for packet loss (note that in this case, the 'CL' field MUST also be passed to the decoder). The helper routine provided in Appendix A MUST be used to extract sensitivity classes' length for each frame. The following pseudocode describes the sequence of operations:
受信機は、（この場合、「CL」フィールドもデコーダに渡さなければならないことに留意されたい）、パケット損失を補償するための冗長データを使用することができます。付録Aに設けられたヘルパールーチンは、フレームごとに感度クラスの長さを抽出するために使用されなければなりません。次の擬似コードは、一連の操作を説明します。
int sensitivityBits[numOfRedundancyFrames][6];
int redundancyBits [numOfRedundancyFrames];
for(i = 0 ; i < numOfRedundancyFrames; i++) {
GetFrameInfo(CR, BR, pRedundancyPayloadData, dummy,
sensitivityBits[i], dummy);
redundancyBits[i] = 0;
for(j = 0; j < CL[i]; j++ ) {
redundancyBits[i] += sensitivityBits[i][j];
}
flushBits(pRedundancyPayloadData, redundancyBits[i]);
}
This section provides detailed examples of the IP-MR payload format.
このセクションでは、IP-MRペイロードフォーマットの詳細な例を提供します。
The following diagram shows a typical IP-MR payload carrying one (GR=0) non-aligned (A=0) speech frame without redundancy (R=0). The base layer is coded at 7.8 kbps (BR=0) while the coding rate is 9.7 kbps (CR=1). The 'E' bit value of 1 signals that compressed frame bits s(0) - s(193) are present. There is a padding bit 'P' to maintain speech payload size alignment.
以下の図は、冗長性のないもの（GR = 0）の非整列（A = 0）音声フレームを運ぶ一般的なIP-MRペイロードを示す（R = 0）。符号化率が9.7 kbpsの（CR = 1）である下地層が7.8 kbpsの（BR = 0）で符号化されます。 S（0）フレームビット圧縮1つの信号の 'E' ビット値 - S（193）が存在しています。音声ペイロードサイズのアライメントを維持するために、パディングビット「P」はあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|CR=1 |BR=0 |1|0|0 0|0|1|s(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| s(193)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram shows a payload carrying 3 (GR=2) aligned (A=1) speech frames with redundancy (R=1). The TOC value of '101' indicates speech data present for the first (bits sp1(0)-sp1(92)) and third frames (bits sp3(0)-sp3(171)). There are no enchantment layers because the base and coding rates are equal (BR=CR=0). The padding bit 'P' is inserted to maintain necessary alignment.
次の図は、3を搬送するペイロード（GR = 2）冗長性（R = 1）と（A = 1）音声フレームを整列を示します。 '101' のTOC値は、第1（ビットSP1（0）-sp1（92））と第3フレーム（ビットSP3（0） - SP3（171））のための本音声データを示しています。ベース及び符号化率が等しいので、全く魅力層が存在しない（BR = CR = 0）。パディングビット「P」は、必要に応じて位置合わせを維持するために挿入されています。
The redundancy payload present for both preceding and pre-preceding payloads (CL1 = A-B, CL2=A), but redundancy data is only available for 5 (TOC='111011') of 6 (2*(GR+1)) frames. There is redundancy data of 20, 39, and 35 bits for each of the three frames of the preceding packet and 15 and 19 bits for the two frames of the pre-preceding packet.
両方の前後のプレ先行ペイロード（CL1 = A-B、CL2 = A）のための本冗長ペイロードが、冗長データは、6（2 *（GR + 1））フレームの5（TOC = '111011'）でのみ使用可能です。冗長20、39のデータ、および前前のパケットの2フレーム分前のパケットの3つのフレーム15と19ビットの各35ビットがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|CR=0 |BR=0 |1|1|1 0|1|1 0 1|P|sp1(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp1(92)|P|P|P|sp3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp3(171)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CL1=2|CL2=1|1 1 1|0 1 1|red1_1_AB(0) red1_1_AB(19)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(38)|red1_3_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_3_AB(34)|red2_2_A(0) red2_2_A(14)|red2_3_A(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red2_3_A(18)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The general congestion control considerations for transporting RTP data applicable to IP-MR speech over RTP (see RTP [RFC3550] and any applicable RTP profile like the Audio-Visual Profile (AVP) [RFC3551]). However, the multi-rate capability of IP-MR speech coding provides a mechanism that may help to control congestion, since the bandwidth demand can be adjusted by selecting a different encoding mode.
RTPオーバーIP-MRのスピーチに適用RTPデータを転送するための一般的な輻輳制御の考慮事項（RTP [RFC3550]とオーディオビジュアルプロファイル（AVP）[RFC3551]のような任意の適用可能なRTPプロファイルを参照してください）。帯域幅の需要が異なる符号化モードを選択することにより調整することができるので、IP-MRの音声符号化のマルチレート能力は、輻輳を制御するために役立つことができる機構を提供します。
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 thus reduce the overhead from IP/UDP/RTP headers, at the expense of increased delay.
各RTPペイロードにカプセル化されたフレームの数は非常にオーバーヘッド制約ヘッダによるRTPストリームの全体的な帯域幅に影響を与えます。各RTPペイロードに複数のフレームをパケット化して送信されたパケットの数を減少させ、従って増加遅延を犠牲にして、IP / UDP / RTPヘッダのオーバーヘッドを低減することができます。
Due to the scalability nature of the IP_MR codec, the transmission rate can be reduced at any transport stage to fit channel bandwidth. The minimal rate is specified by the BR field of the payload header and can be as low as 7.7 kbps. It is up to the application to keep the balance between coding quality (high BR) and bitstream scalability (low BR). Because coding quality depends on coding rate (CR) rather than base rate (BR), it is NOT RECOMMENDED to use high BR values for real-time communications.
IP_MRコーデックのスケーラビリティの性質のために、伝送速度は、チャネル帯域幅に合わせて任意の輸送段階で減少させることができます。最小速度は、ペイロードヘッダのBRフィールドによって指定され、7.7 kbpsの限り低くすることができます。これは、品質（高BR）とビットストリームのスケーラビリティ（低BR）をコードとの間のバランスを保つために、アプリケーション次第です。符号化品質はレート（CR）ではなく、ベースレート（BR）のコーディングに依存するので、リアルタイム通信のための高いBR値を使用することが推奨されていません。
Applications MAY utilize bitstream redundancy to combat packet loss. However, the gateway is free to chose any option to reduce the transmission rate; the coding layer or redundancy bits can be dropped. Due to this fact, it is NOT RECOMMENDED for applications to increase the total bitrate when adding redundancy in response to packet loss.
アプリケーションは、パケット損失に対処するためのビットストリームの冗長性を利用することができます。ただし、ゲートウェイは、伝送速度を低減するためのいずれかのオプションを選択して自由です。コード化層又は冗長ビットをドロップすることができます。この事実により、それがパケット損失に対応して冗長性を追加するときの総ビットレートを向上させる用途にはお勧めできません。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity-protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and source authentication at least capable of determining if an RTP packet is from a member of the RTP session.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[RFC3550]及び該当RTPプロファイルで議論したセキュリティ問題を受けることです。このメモ内で定義されたRTPペイロードフォーマットを運ぶRTPパケットのための主要なセキュリティ上の考慮事項は、機密性、完全性、およびソース信憑です。機密性は、RTPペイロードの暗号化によって達成されます。 RTPパケットの整合性は、適切な暗号の完全性保護機構を介して達成されます。そのような暗号化システムはまた、ペイロードのソースの認証を可能にすることができます。このRTPペイロードフォーマットに適したセキュリティ・メカニズムは、RTPパケットがRTPセッションのメンバーからのものであるかどうかを決定するのは、少なくとも可能な機密性、完全性保護、及びソース認証を提供すべきです。
Note that the appropriate mechanisms to provide security to RTP and payloads following this memo may vary. The security mechanisms are dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient; although if suitable, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist.
このメモ以下RTPとペイロードにセキュリティを提供するための適切な機構が変化してもよいことに留意されたいです。セキュリティメカニズムは、アプリケーション、輸送、および使用されるシグナリングプロトコルに依存しています。したがって、単一のメカニズムは十分ではありません。適している場合も、セキュアリアルタイム転送プロトコル（SRTP）[RFC3711]の使用が推奨されます。使用できる他のメカニズムは、IPsec [RFC4301]およびTransport Layer Security（TLS）[RFC5246]（TCP上のRTP）をしています。他の選択肢が存在してもよいです。
This payload format does not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data.
このペイロード・フォーマットは、パケット処理のために受信側計算の複雑さの有意な不均一性を示し、したがって、病理学的データの受信によるサービス拒否脅威を与えにくいありません。
This section describes the media types and names associated with this payload format.
このセクションでは、このペイロード形式に関連付けられているメディアの種類と名前を示します。
The IP-MR media subtype is defined as 'ip-mr_v2.5'. This subtype was registered to specify an internal codec version. Later, this version was accepted as final, the bitstream was frozen, and IP-MR v2.5 was published under the name of IP-MR. Currently, the terms 'IP-MR' and 'IP-MR v2.5' are synonyms. The subtype name 'ip-mr_v2.5' is being used in implementations.
IP-MRのメディアサブタイプは、 'IP-mr_v2.5' と定義されます。このサブタイプは、内部コーデックのバージョンを指定するために登録されました。その後、このバージョンは、ビットストリームが凍結した、最終的として受け入れた、とIP-MRのV2.5は、IP-MRの名前で公開されていました。現在、用語 'IP-MR' と 'IP-MRのV2.5は、' 同義語です。サブタイプ名「IP-mr_v2.5」を実装で使用されています。
Media Type name: audio
メディアタイプ名：オーディオ
Media Subtype name: ip-mr_v2.5
メディアサブタイプ名：IP-mr_v2.5
Required parameters: none
必須パラメータ：なし
Optional parameters: These parameters apply to RTP transfer only.
オプションのパラメータ：これらのパラメータは、唯一のRTP転送に適用されます。
ptime: The media packet length in milliseconds. Allowed values are: 20, 40, 60, and 80.
PTIME：ミリ秒単位のメディアパケット長。使用できる値は以下のとおりです。20、40、60、および80。
Encoding considerations: This media type is framed and binary (see RFC 4288, Section 4.8).
エンコードの考慮事項：このメディアタイプは、（RFC 4288、セクション4.8を参照）フレームとバイナリされます。
Security considerations: See Section 6 of RFC 6262.
セキュリティの考慮事項：RFC 6262のセクション6を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 6262
公開された仕様：RFC 6262
Applications that use this media type: Real-time audio applications like voice over IP, teleconference, and multimedia streaming.
ボイスオーバーIP、会議、およびマルチメディアストリーミングのようなリアルタイムのオーディオアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: V. Sviridenko <vladimirs@spiritdsp.com>
人とEメールアドレスは、詳細のために連絡する：V. Sviridenko <vladimirs@spiritdsp.com>
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550].
使用上の制限：このメディアタイプは、RTP [RFC3550]を介してRTPフレーミングに依存し、従ってのみ転送のために定義されています。
Authors: Sergey Ikonin <info@spiritdsp.com> Dmitry Yudin <info@spiritdsp.com>
著者：セルゲイ・アイコン<info@spiritdsp.com>ドミットリー・ユージン<info@spiritdsp.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the IP-MR codec, the mapping is as follows:
メディアタイプ仕様で搬送される情報は、一般的にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）[RFC4566]のフィールドに特定のマッピングを有します。 SDPは、IP-MRコーデックを採用セッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000.
O（ペイロードフォーマット名）メディアサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。 「= rtpmap」のRTPクロックレートは16000でなければなりません。
o The parameter "ptime" goes in the SDP "a=ptime" attribute.
Oパラメータ「PTIMEは、」SDP「= PTIME」属性になります。
Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs.
残りのパラメータは、パラメータ=値のペアをセミコロンで区切ったリストで、メディアタイプパラメータ文字列から直接コピーすることにより、SDPに「=のfmtp」属性を行きます。
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.
ペイロード形式（符号化）の名前は、一般的に大文字で示されていることに留意されたいです。メディアサブタイプは、一般的に小文字で示されています。これらの名前は、両方の場所で大文字と小文字を区別しません。
One media type (ip-mr_v2.5) has been defined and registered in the media types registry.
一つのメディアタイプ（IP-mr_v2.5）が定義されており、メディアタイプレジストリに登録されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
Appendix A. Retrieving Frame Information
付録A.の取得フレーム情報
This appendix contains the C code for implementation of the frame-parsing function. This function extracts information about a coded frame, including frame size, number of layers, size of each layer, and size of perceptual sensitive classes.
この付録では、フレーム解析関数の実装のためのCコードが含まれています。この関数は、フレームサイズ、層の数、各層のサイズ、及び知覚敏感なクラスのサイズを含む符号化されたフレームに関する情報を抽出します。
A.1. get_frame_info.c
A.1。 get_frame_info.c
/*
Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2011 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
「現状のまま」、いかなる明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証は放棄さ本ソフトウェアは著作権所有者によって提供されます。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
*/
＊／
/******************************************************************
get_frame_info.c
get_frame_info.c
Retrieving frame information for IP-MR Speech Codec
IP-MR音声コーデックのためのフレーム情報を取得
******************************************************************/
#define RATES_NUM 6 // number of codec rates #define SENSE_CLASSES 6 // number of sensitivity classes (A..F)
#define RATES_NUM 6 //感度クラス（A〜F）の6 //数をSENSE_CLASSESの#defineのコーデックレートの数
// frame types #define FT_SPEECH 0 // active speech #define FT_DTX_SID 1 // silence insertion descriptor
//フレームタイプはFT_SPEECH 0 //アクティブスピーチの#define FT_DTX_SID 1 //無音挿入記述子を#defineします
// get specified bit from coded data int GetBit(const unsigned char *buf, int curBit) { return (buf[curBit>>3]>>(curBit%8))&1; }
//指定され得る符号化データINT GetBitからビット（CONSTはunsigned char * bufは、INT curBit）{リターン（BUF [curBit >> 3] >>（curBitの8％）） - 1; }
// retrieve frame information
int GetFrameInfo( // o: frame size in bits
short rate, // i: encoding rate (0..5)
short base_rate, // i: base (core) layer rate,
const unsigned char buf[2], // i: coded bit frame
int size, // i: coded bit frame size in bytes
short pLayerBits[RATES_NUM], // o: number of bits in layers
short pSenseBits[SENSE_CLASSES], // o: number of bits in
// sensitivity classes
short *nLayers // o: number of layers
)
{
static const short Bits_1[4] = { 0, 9, 9,15};
static const short Bits_2[16] = { 43,50,36,31,46,48,40,44,
47,43,44,45,43,44,47,36};
static const short Bits_3[2][6] = {{13,11,23,33,36,31},
{25, 0,23,32,36,31},};
int FrType;
int i, nBits = 0;
if (rate < 0 || rate > 5) {
return 0; // incorrect stream
}
// extract frame type bit if required FrType = GetBit(buf, nBits++) ? FT_SPEECH : FT_DTX_SID;
//抽出フレームタイプビットFrType = GetBit（BUF、nBitsの++）必要であれば？ FT_SPEECH：FT_DTX_SID。
if((FrType != FT_DTX_SID && size < 2) || size < 1) { return 0; // not enough input data
（！（FrType = FT_DTX_SID &&サイズ<2）||サイズが<1）{0を返す場合入力されたデータ//十分ではありません
}
｝
for(i = 0; i < SENSE_CLASSES; i++) { pSenseBits[i] = 0;
用（i = 0; iは<SENSE_CLASSES; iは++）{pSenseBits [I] = 0;
}
｝
{
int cw_0;
int b[14];
// extract meaning bits
for(i = 0 ; i < 14; i++) {
b[i] = GetBit(buf, nBits++);
}
// parse
if(FrType == FT_DTX_SID) {
cw_0 = (b[0]<<0)|(b[1]<<1)|(b[2]<<2)|(b[3]<<3);
rate = 0;
pSenseBits[0] = 10 + Bits_2[cw_0];
} else {
int i, idx;
int nFlag_1, nFlag_2, cw_1, cw_2;
nFlag_1 = b[0] + b[2] + b[4] + b[6];
cw_1 = (cw_1 << 1) | b[0];
cw_1 = (cw_1 << 1) | b[2];
cw_1 = (cw_1 << 1) | b[4];
cw_1 = (cw_1 << 1) | b[6];
nFlag_2 = b[1] + b[3] + b[5] + b[7];
cw_2 = (cw_2 << 1) | b[1];
cw_2 = (cw_2 << 1) | b[3];
cw_2 = (cw_2 << 1) | b[5];
cw_2 = (cw_2 << 1) | b[7];
cw_0 = (b[10]<<0)|(b[11]<<1)|(b[12]<<2)|(b[13]<<3);
if (base_rate < 0) base_rate = 0;
if (base_rate > rate) base_rate = rate;
idx = base_rate == 0 ? 0 : 1;
pSenseBits[0] = 15+Bits_2[cw_0];
pSenseBits[1] = Bits_1[(cw_1>>0)&0x3] +
Bits_1[(cw_1>>2)&0x3];
pSenseBits[2] = nFlag_1*5;
pSenseBits[3] = nFlag_2*30;
pSenseBits[5] = (4 - nFlag_2)*(Bits_3[idx][0]);
pSenseBits [5] =（4 - nFlag_2）*（Bits_3 [IDX] [0]）。
for (i = 1; i < rate+1; i++) { pLayerBits[i] = 4*Bits_3[idx][i]; }
{pLayerBits [I] = 4×Bits_3 [IDX] [i]は、式（I ++; iは速度+ 1 <I = 1）のために}
}
｝
pLayerBits[0] = 0;
for (i = 0; i < SENSE_CLASSES; i++) {
pLayerBits[0] += pSenseBits[i];
}
*nLayers = rate+1; }
* nLayers =レート+ 1。 }
{
// count total frame size
int payloadBitCount = 0;
for (i = 0; i < *nLayers; i++) {
payloadBitCount += pLayerBits[i];
}
return payloadBitCount;
}
}
Author's Address
著者のアドレス
Sergey Ikonin SPIRIT DSP Building 27, A. Solzhenitsyna Street 109004, Moscow Russia
セルゲイ・アイコンSPIRIT DSPビル27、A.ソルジェニーツィンストリート109004、モスクワロシア
Tel: +7 495 661-2178 Fax: +7 495 912-6786 EMail: s.ikonin@gmail.com
電話：+7 495 661-2178ファックス：+7 495 912-6786 Eメール：s.ikonin@gmail.com