draft-ietf-avt-rtp-ipmr-14.txt   draft-ietf-avt-rtp-ipmr-15.txt 
Audio/Video Transport Working Group S. Ikonin Audio/Video Transport Working Group S. Ikonin
Internet Draft SPIRIT DSP Internet Draft SPIRIT DSP
Intended status: Proposed Standard October 13, 2010 Intended status: Proposed Standard January 11, 2011
RTP Payload Format for IP-MR Speech Codec RTP Payload Format for IP-MR Speech Codec
draft-ietf-avt-rtp-ipmr-14.txt draft-ietf-avt-rtp-ipmr-15.txt
Abstract Abstract
This document specifies the payload format for packetization of This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the real-time transport SPIRIT IP-MR encoded speech signals into the real-time transport
protocol (RTP). The payload format supports transmission of multiple protocol (RTP). The payload format supports transmission of multiple
frames per packet and introduced redundancy for robustness against frames per packet and introduced redundancy for robustness against
packet loss and bit errors. packet loss and bit errors.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 18, 2010. This Internet-Draft will expire on December 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 40 skipping to change at page 3, line 40
(base) layer is mandatory while the other (enhancement) can be safely (base) layer is mandatory while the other (enhancement) can be safely
discarded. Information about particular frame structure is available discarded. Information about particular frame structure is available
from the payload header. In order to adjust outgoing bandwidth the from the payload header. In order to adjust outgoing bandwidth the
gateway MUST read frame(s) structure from the payload header, define gateway MUST read frame(s) structure from the payload header, define
which enhancement layers to discard and compose new RTP packet which enhancement layers to discard and compose new RTP packet
according to this specification. according to this specification.
In fact, not all of bits within a frame are equally tolerant to In fact, not all of bits within a frame are equally tolerant to
distortion. IP-MR defines 6 classes ('A'-'F') of sensitivity to bit distortion. IP-MR defines 6 classes ('A'-'F') of sensitivity to bit
errors. Any damage of class 'A' bits cause significant reconstruction errors. Any damage of class 'A' bits cause significant reconstruction
artifacts while the lost in class 'F' may be even not perceived by artifacts while the loss in class 'F' may be even not perceived by
the listener. Note, only base layer in a bitstream is represented as the listener. Note, only base layer in a bitstream is represented as
a set of classes. a set of classes.
The IP-MR payload format allows frame duplicate through the packets The IP-MR payload format allows frame duplicate through the packets
to improve robustness against packet loss (Section 3.6). Base layer to improve robustness against packet loss (Section 3.6). Base layer
can be retransmitted completely or in several sensitive classes. can be retransmitted completely or in several sensitive classes.
Enchantment layers are not retransmittable. Enchantment layers are not retransmittable.
The fine-grained redundancy in conjunction with bitrate scalability The fine-grained redundancy in conjunction with bitrate scalability
allows application adjust the trade-off between overhead and allows application adjust the trade-off between overhead and
skipping to change at page 5, line 28 skipping to change at page 5, line 28
This header carries parameters which are common for all frames in the This header carries parameters which are common for all frames in the
packet: packet:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
|T| CR | BR |D|A|GR |R| |T| CR | BR |D|A|GR |R|
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
o T (1 bit): Reserved. MUST be always set to 0. Receiver SHOULD o T (1 bit): Reserved. MUST be always set to 0. Receiver MAY
discard packet if 'T' bit is not equal to 0. discard packet if 'T' bit is not equal to 0.
o CR (3 bits): Coding rate index - top enchantment layer o CR (3 bits): Coding rate index - top enchantment layer
available. The CR value 7 (NO_DATA) indicates that there is no available. The CR value 7 (NO_DATA) indicates that there is no
speech data (and speech TOC accordingly) in the payload. This MAY speech data (and speech TOC accordingly) in the payload. This MAY
be used to transmit redundancy data only. be used to transmit redundancy data only.
o BR (3 bits): Base rate index - base layer bitrate. Speech o BR (3 bits): Base rate index - base layer bitrate. Speech
payload can be scaled to any rate index between BR and CR. Packets 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 with BR = 6 or BR > CR MUST be discarded. Redundancy data is also
skipping to change at page 6, line 9 skipping to change at page 6, line 9
frames. Note, speech payload is always padded to byte boundary frames. Note, speech payload is always padded to byte boundary
independently on 'A' bit value. independently on 'A' bit value.
o GR (2 bits): Number of frames in packet (grouping size). Actual o GR (2 bits): Number of frames in packet (grouping size). Actual
grouping size is GR + 1, thus maximum grouping supported is 4. grouping size is GR + 1, thus maximum grouping supported is 4.
o R (1 bit): Redundancy presence. Value of 1 indicates redundancy o R (1 bit): Redundancy presence. Value of 1 indicates redundancy
payload presence. payload presence.
Note, the values of 'T' and 'D' bits are fixed, any other values are Note, the values of 'T' and 'D' bits are fixed, any other values are
not allowed by specification. Note, the values of padding bit is not not allowed by specification. padding Padding bits ('P' bits) MUST be
specified. always set to zero.
The following table defines mapping between rate index and rate The following table defines mapping between rate index and rate
value: value:
+------------+--------------+ +------------+--------------+
| rate index | avg. bitrate | | rate index | avg. bitrate |
+------------+--------------+ +------------+--------------+
| 0 | 7.7 kbps | | 0 | 7.7 kbps |
| 1 | 9.8 kbps | | 1 | 9.8 kbps |
| 2 | 14.3 kbps | | 2 | 14.3 kbps |
skipping to change at page 7, line 33 skipping to change at page 7, line 33
|<- BR rate ------------------->| | |<- BR rate ------------------->| |
|<- CR rate ------------------------------------------------------->| |<- CR rate ------------------------------------------------------->|
The Annex A of this document provides helper routine written in "C" The Annex A of this document provides helper routine written in "C"
which MUST be used to extract sensitivity classes and enchantment which MUST be used to extract sensitivity classes and enchantment
layers bounds from the compressed frame data. layers bounds from the compressed frame data.
3.6. Redundancy Payload Header 3.6. Redundancy Payload Header
The redundancy payload presence is signaled by R bit of speech The redundancy payload presence is signaled by R bit of speech
payload header. Redundancy header composed of two fields of 3 bits payload header. Redundancy header is composed of two fields of 3 bits
each: each:
0 1 2 3 4 5 0 1 2 3 4 5
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| CL1 | CL2 | | CL1 | CL2 |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Both of 'CL1' and 'CL2' fields specify the sensitivity classes Both of 'CL1' and 'CL2' fields specify the sensitivity classes
available for preceding and pre-preceding packets correspondingly. available for preceding and pre-preceding packets correspondingly.
skipping to change at page 8, line 47 skipping to change at page 8, line 47
| |<----->| pre-preceding payload #(GR+1) | |<----->| pre-preceding payload #(GR+1)
|<----->| preceding payload #(GR+1) |<----->| preceding payload #(GR+1)
o E (1 bit): Redundancy frame existence indicator. The value of 0 o E (1 bit): Redundancy frame existence indicator. The value of 0
indicates redundancy data does not present for corresponding frame. indicates redundancy data does not present for corresponding frame.
3.8. Redundancy Payload Data 3.8. Redundancy Payload Data
IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any
damage of class 'A' bits cause significant reconstruction artifacts damage of class 'A' bits cause significant reconstruction artifacts
while the lost in class 'F' may be even not perceived by the while the loss in class 'F' may be even not perceived by the
listener. Note, only base layer in a bitstream is represented as a listener. Note, only base layer in a bitstream is represented as a
set of classes. Together, the set of sensitivity classes approach and set of classes. Together, the set of sensitivity classes approach and
redundancy allows IP-MR duplicate frames through the packets to redundancy allows IP-MR duplicate frames through the packets to
improve robustness against packet loss. improve robustness against packet loss.
Redundancy data carries a number of sensitivity classes for preceding Redundancy data carries a number of sensitivity classes for preceding
and pre-preceding packets as indicated by 'CL1' and 'CL2' fields of and pre-preceding packets as indicated by 'CL1' and 'CL2' fields of
redundancy header. The sensitivity classes data is available redundancy header. The sensitivity classes data is available
individually for each frame only if corresponding 'E' bit of individually for each frame only if corresponding 'E' bit of
redundancy TOC is nonzero: redundancy TOC is nonzero:
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+ +---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|A-C|A-B|1000|1001|cl_A1|cl_B1|cl_C1|cl_A1|cl_B1|cl_A4|cl_B4| |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 ----->| |<- CL >|<- TOC ->|<- preceding --->|<- pre-preceding ----->|
Redundancy data only available if base (BR) and coding (CR) rates of Redundancy data only available if base (BR) and coding (CR) rates of
preceding and pre-preceding packets are the same as for the current preceding and pre-preceding packets are the same as for the current
packet. packet.
Receiver MAY use redundancy data to compensate packet loss, note this Receiver MAY use redundancy data to compensate packet loss, note in
case the 'CL' field MUST be also passed to decoder. Helper routine this case the 'CL' field MUST be also passed to decoder. Helper
provided in Annex A MUST be used to extract sensitivity classes routine provided in Annex A MUST be used to extract sensitivity
length for each frame. The following pseudo code describes the classes length for each frame. The following pseudo code describes
sequence of operations: the sequence of operations:
int sensitivityBits[numOfRedundancyFrames][6]; int sensitivityBits[numOfRedundancyFrames][6];
int redundancyBits [numOfRedundancyFrames]; int redundancyBits [numOfRedundancyFrames];
for(i = 0 ; i < numOfRedundancyFrames; i++) { for(i = 0 ; i < numOfRedundancyFrames; i++) {
GetFrameInfo(CR, BR, pRedundancyPayloadData, dummy, GetFrameInfo(CR, BR, pRedundancyPayloadData, dummy,
sensitivityBits[i], dummy); sensitivityBits[i], dummy);
redundancyBits[i] = 0; redundancyBits[i] = 0;
for(j = 0; j < CL[i]; j++ ) { for(j = 0; j < CL[i]; j++ ) {
redundancyBits[i] += sensitivityBits[i][j]; redundancyBits[i] += sensitivityBits[i][j];
} }
flushBits(pRedundancyPayloadData, redundancyBits[i]); flushBits(pRedundancyPayloadData, redundancyBits[i]);
} }
4. Payload Examples 4. Payload Examples
This section provides detailed examples of IP-MR payload format. This section provides detailed examples of IP-MR payload format.
4.1. Payload Carrying a Single Frame 4.1. Payload Carrying a Single Frame
The following diagram shows typical IP-MR payload carrying a one The following diagram shows typical IP-MR payload carrying one (GR=0)
(GR=0) non-aligned (A=0) speech frame without redundancy (R=0). The non-aligned (A=0) speech frame without redundancy (R=0). The base
base layer is coded at 7.8 kbps (BR=0) while the coding rate is 9.7 layer is coded at 7.8 kbps (BR=0) while the coding rate is 9.7 kbps
kbps (CR=1). The 'E' bit value of 1 signals that compressed frame (CR=1). The 'E' bit value of 1 signals that compressed frame bits
bits s(0) - s(193) are present. There is a padding bit 'P' to s(0) - s(193) are present. There is a padding bit 'P' to maintain
maintain speech payload size alignment. speech payload size alignment.
0 1 2 3 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 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) | |0|CR=1 |BR=0 |1|0|0 0|0|1|s(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 37 skipping to change at page 11, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(0) | |red1_2_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(38)|red1_3_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) | | red1_3_AB(34)|red2_2_A(0) red2_2_A(14)|red2_3_A(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red2_3_A(18)|P|P|P|P| | red2_3_A(18)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Congestion Control The general congestion control considerations for 5. Congestion Control
transporting RTP data applicable to IP-MR speech over RTP (see RTP
[RFC 3550] and any applicable RTP profile like AVP [RFC 3551]). The general congestion control considerations for transporting RTP
However, the multi-rate capability of IP-MR speech coding provides a data applicable to IP-MR speech over RTP (see RTP [RFC 3550] and any
mechanism that may help to control congestion, since the bandwidth applicable RTP profile like AVP [RFC 3551]). However, the multi-rate
demand can be adjusted by selecting a different encoding mode. 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.
The number of frames encapsulated in each RTP payload highly The number of frames encapsulated in each RTP payload highly
influences the overall bandwidth of the RTP stream due to header influences the overall bandwidth of the RTP stream due to header
overhead constraints. Packetizing more frames in each RTP payload can overhead constraints. Packetizing more frames in each RTP payload can
reduce the number of packets sent and hence the overhead from reduce the number of packets sent and hence the overhead from
IP/UDP/RTP headers, at the expense of increased delay. IP/UDP/RTP headers, at the expense of increased delay.
Due to scalability nature of IP_MR codec the transmission rate can be Due to scalability nature of IP_MR codec the transmission rate can be
reduced at any transport stage to fit channel bandwidth. The minimal reduced at any transport stage to fit channel bandwidth. The minimal
rate is specified by BR field of payload header and can be is low as rate is specified by BR field of payload header and can be is low as
skipping to change at page 13, line 25 skipping to change at page 13, line 27
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
These parameters apply to RTP transfer only. These parameters apply to RTP transfer only.
ptime: The media packet length in milliseconds. Allowed values ptime: The media packet length in milliseconds. Allowed values
are: 20, 40, 60 and 80. are: 20, 40, 60 and 80.
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8). This media type is framed and binary (see RFC 4288, Section 4.8).
Security considerations: Security considerations:
See section 6 of RFC XXXX (RFC editor please replace with this RFC See section 6 of RFC XXXX (RFC editor please replace with this RFC
number). number).
Interoperability considerations: Interoperability considerations:
none none
Published specification: Published specification:
RFC XXXX (RFC editor please replace with this RFC number) RFC XXXX (RFC editor please replace with this RFC number)
skipping to change at page 13, line 51 skipping to change at page 14, line 4
Additional information: Additional information:
none none
Person & email address to contact for further information: Person & email address to contact for further information:
Dmitry Yudin <yudin@spiritdsp.com> Dmitry Yudin <yudin@spiritdsp.com>
Intended usage: Intended usage:
COMMON COMMON
Restrictions on usage: Restrictions on usage:
This media type depends on RTP framing, and hence is only defined This media type depends on RTP framing, and hence is only defined
fortransfer via RTP [RFC 3550]. fortransfer via RTP [RFC 3550].
Authors: Authors:
Sergey Ikonin <info@spiritdsp.com> Dmitry Yudin Sergey Ikonin <info@spiritdsp.com>
<yudin@spiritdsp.com> Dmitry Yudin <yudin@spiritdsp.com>
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group delegated from the IESG.
7.2. Mapping Media Type Parameters into SDP 7.2. Mapping Media Type Parameters into SDP
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[RFC 4566], which is commonly used to describe RTP sessions. When SDP [RFC 4566], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the IP-MR codec, the mapping is is used to specify sessions employing the IP-MR codec, the mapping is
skipping to change at page 17, line 38 skipping to change at page 17, line 38
distribution. distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor - Neither the name of Internet Society, IETF or IETF Trust, nor
the names of specific contributors, may be used to endorse or the names of specific contributors, may be used to endorse or
promote products derived from this software without specific promote products derived from this software without specific
prior written permission. prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BELIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/ */
/****************************************************************** /******************************************************************
skipping to change at page 18, line 16 skipping to change at page 18, line 15
******************************************************************/ ******************************************************************/
#define RATES_NUM 6 // number of codec rates #define RATES_NUM 6 // number of codec rates
#define SENSE_CLASSES 6 // number of sensitivity classes (A..F) #define SENSE_CLASSES 6 // number of sensitivity classes (A..F)
// frame types // frame types
#define FT_SPEECH 0 // active speech #define FT_SPEECH 0 // active speech
#define FT_DTX_SID 1 // silence insertion descriptor #define FT_DTX_SID 1 // silence insertion descriptor
// get specified bit from coded data // get specified bit from coded data
int GetBit(unsigned char *buf, int curBit) int GetBit(const unsigned char *buf, int curBit)
{ {
return (buf[curBit>>3]>>(curBit%8))&1; return (buf[curBit>>3]>>(curBit%8))&1;
} }
// retrieve frame information // retrieve frame information
int GetFrameInfo( // o: frame size in bits int GetFrameInfo( // o: frame size in bits
short rate, // i: encoding rate (0..5) short rate, // i: encoding rate (0..5)
short base_rate, // i: base (core) layer rate, short base_rate, // i: base (core) layer rate,
unsigned char *buf, // i: coded bit frame const unsigned char buf[2], // i: coded bit frame
int size, // i: coded bit frame size in bytes int size, // i: coded bit frame size in bytes
short pLayerBits[RATES_NUM], // o: number of bits in layers short pLayerBits[RATES_NUM], // o: number of bits in layers
short pSenseBits[SENSE_CLASSES], // o: number of bits in short pSenseBits[SENSE_CLASSES], // o: number of bits in
// sensitivity classes // sensitivity classes
short *nLayers // o: number of layers short *nLayers // o: number of layers
) )
{ {
static const short Bits_1[4] = { 0, 9, 9,15}; static const short Bits_1[4] = { 0, 9, 9,15};
static const short Bits_2[16] = { 43,50,36,31,46,48,40,44, static const short Bits_2[16] = { 43,50,36,31,46,48,40,44,
47,43,44,45,43,44,47,36}; 47,43,44,45,43,44,47,36};
static const short Bits_3[2][6] = {{13,11,23,33,36,31}, static const short Bits_3[2][6] = {{13,11,23,33,36,31},
{25, 0,23,32,36,31},}; {25, 0,23,32,36,31},};
int FrType; int FrType;
int i,nBits = 0; int i, nBits = 0;
if (rate < 0 || rate > 5) { if (rate < 0 || rate > 5) {
return 0; // incorrect stream return 0; // incorrect stream
} }
// extract frame type bit if required // 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) { if((FrType != FT_DTX_SID && size < 2) || size < 1) {
return 0; // not enough input data return 0; // not enough input data
 End of changes. 18 change blocks. 
37 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/