[要約] RFC 6262は、IP-MR音声コーデックのRTPペイロード形式に関する仕様です。このRFCの目的は、IP-MR音声コーデックを使用するためのRTPペイロード形式を定義し、音声通信の品質と効率を向上させることです。
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
IP-MR音声コーデックのRTPペイロード形式
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.
このドキュメントは、スピリットIP-MRエンコードされた音声信号をリアルタイムトランスポートプロトコル（RTP）にパケット化するためのペイロード形式を指定します。ペイロード形式は、パケットごとの複数のフレームの送信をサポートし、パケットの損失とビットエラーに対する堅牢性のために冗長性を導入します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
このドキュメントは、スピリットIP-MRエンコードされた音声信号をリアルタイムトランスポートプロトコル（RTP）にパケット化するためのペイロード形式を指定します。ペイロード形式は、パケットごとの複数のフレームの送信をサポートし、パケットの損失とビットエラーに対する堅牢性のために冗長性を導入します。
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.
コーデックは、16 kHzのサンプリングレートで20ミリ秒のフレームサイズでフレームごとに動作し、総エンドツーエンド遅延は25ミリ秒です。各圧縮フレームは、一連のレイヤーとして表されます。最初の（ベース）レイヤーは必須であり、他の（エンハンスメント）レイヤーは安全に破棄できます。特定のフレーム構造に関する情報は、ペイロードヘッダーから入手できます。発信帯域幅を調整するために、ゲートウェイはペイロードヘッダーのフレーム構造を読み取り、廃棄する強化層を定義し、この仕様に従って新しい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つのクラス（ 'A' - 'f'）を定義します。クラス「A」ビットの損害は、クラス「F」の損失はリスナーによって認識されない場合もありますが、クラスの「A」ビットの損傷は重要な再構成アーティファクトを引き起こします。ビットストリーム内のベースレイヤーのみがクラスのセットとして表されることに注意してください。
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.
o 7.7から34.2 kbpsの6つの平均レートでスケーラブル。
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タイムスタンプは、パケット内の最初のフレームブロックにエンコードされた最初のサンプルのサンプリングインスタントに対応します。タイムスタンプクロック周波数は16 kHzでなければなりません。1つのフレームの持続時間は20 msで、フレームあたり320サンプルに対応します。したがって、タイムスタンプは、連続したフレームごとに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).
RTPヘッダーマーカービット（M）は、パケットで最初のフレームブロックがTalkSpurtの最初のフレームブロックである場合は1に設定されます（[RFC3551]のセクション4.1のTalkspurtの定義を参照）。他のすべてのパケットについては、マーカービットをゼロ（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ペイロードは、2つのペイロードで構成されています。1つは現在のスピーチ用、もう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ビット）：予約。常に0に設定する必要があります。「T」ビットが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ビット）：予約。常に1に設定する必要があります。「D」ビットがゼロの場合、受信機はパケットを破棄できます。
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 A（1ビット）：バイトアライメント。1の値は、パディングビットが追加されて、各圧縮フレーム（3.5）がバイト（8ビット）境界から開始できるようにすることを指定します。0の値は、整理されていないフレームを指定します。音声ペイロードは、常に「a」ビット値でバイト境界に個別にパッドにされていることに注意してください。
o GR (2 bits): Number of frames in packet (grouping size). Actual grouping size is GR + 1; thus, the maximum grouping supported is 4.
o GR（2ビット）：パケットのフレーム数（グループ化サイズ）。実際のグループ化サイズは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は、パケット内の各フレームの存在を示すビットマスクです。TOCは、「CR」値が7（NO_DATA）に等しくない場合にのみ使用できます。
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モードでの沈黙の期間に対して「E」フラグを0に設定します。フレームが損傷していることが知られている場合、アプリケーションはこのビットを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:
「A」ビットがゼロではない場合、各圧縮フレームの始まりは整列され、音声ペイロードの終わりは常にバイト（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'.
マークされた領域は、「a」ビットが「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は、冗長性ペイロード内の各フレームが存在することを示すビットマスクです。冗長性TOCは、「CL」値が0または7に等しくない場合にのみ使用できます。
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つのクラス（ 'A' - 'f'）を定義します。クラス「A」ビットの損害は、クラス「F」の損失はリスナーによって認識されない場合もありますが、クラスの「A」ビットの損傷は重要な再構成アーティファクトを引き起こします。ビットストリーム内のベースレイヤーのみがクラスのセットとして表されることに注意してください。合わせて、感度クラスのアプローチと冗長性により、パケットを介して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.
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）。基本層は7.8 kbps（br = 0）でコード化され、コーディングレートは9.7 kbps（cr = 1）です。圧縮フレームビットs（0）-S（193）が存在するという1つの信号の「e」ビット値。音声ペイロードサイズのアライメントを維持するためのパディングビット「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.
次の図は、冗長性（r = 1）を備えた3（gr = 2）アラインド（a = 1）の音声フレームを運ぶペイロードを示しています。「101」のTOC値は、最初の（BITS 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'）5（toc = '111011'）でのみ利用可能です。前のパケットの3つのフレームのそれぞれに20、39、および35ビットの冗長データと、事前サイドパケットの2つのフレームに15および19ビットがあります。
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）のバランスを維持するのはアプリケーション次第です。コーディング品質は基本レート（BR）ではなくコーディングレート（CR）に依存するため、リアルタイム通信に高い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]および輸送層セキュリティ（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.
このメディアタイプを使用するアプリケーション：Voice Over IP、Teleconference、Multimediaストリーミングなどのリアルタイムオーディオアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information:
V. Sviridenko <vladimirs@spiritdsp.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550].
使用に関する制限：このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送のみが定義されます。
Authors:
Sergey Ikonin <info@spiritdsp.com>
Dmitry Yudin <info@spiritdsp.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：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:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPを使用してIP-MRコーデックを使用するセッションを指定する場合、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名として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"になります。「a = rtpmap」のRTPクロックレートは16000でなければなりません。
o The parameter "ptime" goes in the SDP "a=ptime" attribute.
o パラメーター「PTIME」は、SDP「A = 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.
残りのパラメーターは、Media型パラメーター文字列から直接コピーすることにより、SDP "a = 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.
1つのメディアタイプ（IP-MR_V2.5）が定義され、メディアタイプレジストリに登録されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
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コードが含まれています。この関数は、フレームサイズ、レイヤー数、各レイヤーのサイズ、知覚に敏感なクラスのサイズなど、コード化されたフレームに関する情報を抽出します。
/*
Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2011 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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.
このソフトウェアは、「現状のまま」の著作権所有者と貢献者によって提供され、特定の目的に対する商品性と適合性の暗黙の保証を含むがこれらに限定されない明示的または黙示的な保証が否認されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
*/
*/
/******************************************************************
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)
// frame types #define FT_SPEECH 0 // active speech #define FT_DTX_SID 1 // silence insertion descriptor
//フレームタイプ#define ft_speech 0 //アクティブなスピーチ#define ft_dtx_sid 1 //沈黙挿入記述子
// get specified bit from coded data
int GetBit(const unsigned char *buf, int curBit)
{
return (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;
if((FrType != FT_DTX_SID && size < 2) || size < 1) {
return 0; // not enough input data
}
}
for(i = 0; i < SENSE_CLASSES; i++) {
pSenseBits[i] = 0;
}
}
{ int cw_0; int b[14];
{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;
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]);
for (i = 1; i < rate+1; i++) {
pLayerBits[i] = 4*Bits_3[idx][i];
}
}
}
pLayerBits[0] = 0;
for (i = 0; i < SENSE_CLASSES; i++) {
pLayerBits[0] += pSenseBits[i];
}
*nLayers = rate+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
セルゲイイコニンスピリットDSPビルディング27、A。ソルツヘニツィナストリート109004、モスクワロシア
Tel: +7 495 661-2178
Fax: +7 495 912-6786
EMail: s.ikonin@gmail.com