draft-ietf-avt-rtp-ipmr-13.txt   draft-ietf-avt-rtp-ipmr-14.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 September 20, 2010 Intended status: Proposed Standard October 13, 2010
RTP Payload Format for IP-MR Speech Codec RTP Payload Format for IP-MR Speech Codec
draft-ietf-avt-rtp-ipmr-13.txt draft-ietf-avt-rtp-ipmr-14.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 2, line 30 skipping to change at page 2, line 30
3.5. Speech Payload Data . . . . . . . . . . . . . . . . . . . . 6 3.5. Speech Payload Data . . . . . . . . . . . . . . . . . . . . 6
3.6. Redundancy Payload Header . . . . . . . . . . . . . . . . . 7 3.6. Redundancy Payload Header . . . . . . . . . . . . . . . . . 7
3.7. Redundancy Payload Table of Contents . . . . . . . . . . . 8 3.7. Redundancy Payload Table of Contents . . . . . . . . . . . 8
3.8. Redundancy Payload Data . . . . . . . . . . . . . . . . . . 8 3.8. Redundancy Payload Data . . . . . . . . . . . . . . . . . . 8
4. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Payload Carrying a Single Frame . . . . . . . . . . . . . . 9 4.1. Payload Carrying a Single Frame . . . . . . . . . . . . . . 9
4.2. Payload Carrying Multiple Frames with Redundancy . . . . 10 4.2. Payload Carrying Multiple Frames with Redundancy . . . . 10
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 11 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 12 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 13
7.2. Mapping Media Type Parameters into SDP . . . . . . . . . 13 7.2. Mapping Media Type Parameters into SDP . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14
10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Legal Terms . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Legal Terms . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
APPENDIX A. RETRIEVING FRAME INFORMATION . . . . . . . . . . . . 17 APPENDIX A. RETRIEVING FRAME INFORMATION . . . . . . . . . . . . 17
A.1. get_frame_info.c . . . . . . . . . . . . . . . . . . . . 17 A.1. get_frame_info.c . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
The RTP timestamp corresponds to the sampling instant of the first The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame-block in the packet. The timestamp 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, clock frequency SHALL be 16 kHz. The duration of one frame is 20 ms,
this corresponding to 320 samples per frame. Thus the timestamp is this corresponding to 320 samples per frame. Thus the timestamp is
increased by 320 for each consecutive frame. The timestamp is also increased by 320 for each consecutive frame. The timestamp is also
used to recover the correct decoding order of the frame-blocks. used to recover the correct decoding order of the frame-blocks.
The RTP header marker bit (M) SHALL be set to 1 whenever the first 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 frame-block carried in the packet is the first frame-block in a
talkspurt (see definition of the talkspurt in Section 4.1 [RFC talkspurt (see definition of the talkspurt in Section 4.1
3551]). For all other packets, the marker bit SHALL be set to zero [RFC 3551]). For all other packets, the marker bit SHALL be set to
(M=0). zero (M=0).
The assignment of an RTP payload type for the format defined in this 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 memo is outside the scope of this document. The RTP profiles in use
currently mandate binding the payload type dynamically for this currently mandate binding the payload type dynamically for this
payload format. This is basically necessary because the payload type payload format. This is basically necessary because the payload type
expresses the configuration of the payload itself, i.e. basic or expresses the configuration of the payload itself, i.e. basic or
interleaved mode, and the number of channels carried. interleaved mode, and the number of channels carried.
The remaining RTP header fields are used as specified in [RFC 3550]. The remaining RTP header fields are used as specified in [RFC 3550].
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. Note, the values of padding bit is not
specified. specified.
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 |
skipping to change at page 7, line 14 skipping to change at page 7, line 14
The beginning of each compressed frame is aligned if 'A' bit is The beginning of each compressed frame is aligned if 'A' bit is
nonzero, while the end of speech payload is always aligned to a byte nonzero, while the end of speech payload is always aligned to a byte
(8 bit) boundary: (8 bit) boundary:
+- - -+------------+------------+------------+------------+ +- - -+------------+------------+------------+------------+
| TOC | Frame1 | Frame2 | Frame3 | Frame4 | | TOC | Frame1 | Frame2 | Frame3 | Frame4 |
+- - -+------------+------------+------------+------------+ ALWAYS +- - -+------------+------------+------------+------------+ ALWAYS
|<- aligned |<- aligned |<- aligned |<- aligned |<- ALIGNED |<- aligned |<- aligned |<- aligned |<- aligned |<- ALIGNED
Marked regions MUST be aligned (padded) only if 'A' bit is set to '1'. Marked regions MUST be padded only if 'A' bit is set to '1'.
The compressed frame structure is the following: The compressed frame structure is the following:
|<---- sensitive classes ------>|<----- enchantment layers --------->| |<---- sensitive classes ------>|<----- enchantment layers -------->|
+-------------------------------+----+-----+------+- - - - - +-------+ +-------------------------------+----+-----+------+- - - - - +------+
| L1 (Base Layer) | L2 | L3 | L4 | | LN | | L1 (Base Layer) | L2 | L3 | L4 | | LN |
+-------------------------------+----+-----+------+- - - - - +-------+ +-------------------------------+----+-----+------+- - - - - +------+
|<- A --->|<- B ->| ... |<- F ->| | |<- A --->|<- B ->| ... |<- F ->| |
|<- 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 composed of two fields of 3 bits
each: each:
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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
7.7 kbps. It is up to application to keep balance between coding 7.7 kbps. It is up to application to keep balance between coding
quality (high BR) and bitstream scalability (small BR). Because of quality (high BR) and bitstream scalability (small BR). Because of
coding quality depends rather on coding rate(CR) than base rate (BR), coding quality depends rather on coding rate(CR) than base rate (BR),
it is not recommended to use high BR values for real-time it is NOT RECOMMENDED to use high BR values for real-time
communications. communications.
Application MAY utilize bitstream redundancy to combat packet loss. Application MAY utilize bitstream redundancy to combat packet loss.
But the gateway is free to chose any option to reduce transmission But the gateway is free to chose any option to reduce transmission
rate - coding layer or redundancy bits can be dropped. Due to this rate - coding layer or redundancy bits can be dropped. Due to this
fact it is not RECOMMENDED application to increase total bitrate when fact it is NOT RECOMMENDED application to increase total bitrate when
adding redundancy in a response to packet loss. adding redundancy in a response to packet loss.
6. Security Considerations 6. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] and in any applicable RTP profile. As this specification [RFC 3550] and in any applicable RTP profile. The main
format transports encoded audio, the main security issues include security considerations for the RTP packet carrying the RTP payload
confidentiality, integrity protection, and data origin authentication format defined within this memo are confidentiality, integrity, and
of the audio itself. 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 at
least source authentication capable of determining if an RTP packet
is from a member of the RTP session.
The payload format itself does not have any built-in security Note that the appropriate mechanism to provide security to RTP and
mechanisms. Any suitable external mechanisms, such as SRTP [RFC- payloads following this memo may vary. It is dependent on the
3711], MAY be used. 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)
[RFC 3711] is recommended. Other mechanisms that may be used are
IPsec [RFC 4301] and Transport Layer Security (TLS) [RFC 5246] (RTP
over TCP); other alternatives may exist.
This payload format does not exhibit any significant non-uniformity This payload format does not exhibit any significant non-uniformity
in the receiver side computational complexity for packet processing in the receiver side computational complexity for packet processing
and thus is unlikely to pose a denial-of-service threat due to the and thus is unlikely to pose a denial-of-service threat due to the
receipt of pathological data. receipt of pathological data.
7. Payload Format Parameters 7. Payload Format Parameters
This section describes the media types and names associated with this This section describes the media types and names associated with this
payload format. Note, the IP-MR bitstream was frozen starting from payload format.
internal release version of 2.5. Currently 'IP-MR' and 'IP-MR v2.5'
terms are synonyms. The IP-MR media subtype is defined as 'ip-mr_v2.5'. This subtype was
registered to specify internal codec version. Later, this version was
accepted as the final, the bitstream was frozen and IP-MR v2.5 was
published under the name of IP-MR. Currently 'IP-MR' and 'IP-MR v2.5'
terms are synonyms. The subtype name ip-mr_v2.5 is being uses in
implementations.
7.1. Media Type Registration 7.1. Media Type Registration
Media Type name: audio Media Type name: audio
Media Subtype name: ip-mr_v2.5 Media Subtype name: ip-mr_v2.5
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 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 RFC4288, Section 4.8). This media type is framed binary data (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 16, line 25 skipping to change at page 16, line 42
Contributor, or included with or in such Contribution. Contributor, or included with or in such Contribution.
12. Authors' Addresses 12. Authors' Addresses
SPIRIT DSP SPIRIT DSP
Building 27, A. Solzhenitsyna street Building 27, A. Solzhenitsyna street
109004, Moscow, RUSSIA 109004, Moscow, RUSSIA
Tel: +7 495 661-2178 Tel: +7 495 661-2178
Fax: +7 495 912-6786 Fax: +7 495 912-6786
EMail: info@spiritdsp.com EMail: yudin@spiritdsp.com
APPENDIX A. RETRIEVING FRAME INFORMATION APPENDIX A. RETRIEVING FRAME INFORMATION
This appendix contains the c-code for implementation of frame parsing This appendix contains the c-code for implementation of frame parsing
function. This function extracts information about coded frame function. This function extracts information about coded frame
including frame size, number of layers, size of each layer and size including frame size, number of layers, size of each layer and size
of perceptual sensitive classes. of perceptual sensitive classes.
A.1. get_frame_info.c A.1. get_frame_info.c
skipping to change at page 17, line 15 skipping to change at page 17, line 15
APPENDIX A. RETRIEVING FRAME INFORMATION APPENDIX A. RETRIEVING FRAME INFORMATION
This appendix contains the c-code for implementation of frame parsing This appendix contains the c-code for implementation of frame parsing
function. This function extracts information about coded frame function. This function extracts information about coded frame
including frame size, number of layers, size of each layer and size including frame size, number of layers, size of each layer and size
of perceptual sensitive classes. of perceptual sensitive classes.
A.1. get_frame_info.c A.1. get_frame_info.c
/* /*
Copyright (c) 2010 Copyright (c) 2010
IETF Trust and the persons identified as authors of the code. IETF Trust and the persons identified as authors of the code.
All rights reserved. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions modification, are permitted provided that the following conditions
are met: are met:
- Redistributions of source code must retain the above copyright notice, - Redistributions of source code must retain the above copyright
this list of conditions and the following disclaimer. notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright - Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the notice, this list of conditions and the following disclaimer in
documentation and/or other materials provided with the distribution. the documentation and/or other materials provided with the
- Neither the name of Internet Society, IETF or IETF Trust, nor the names distribution.
of specific contributors, may be used to endorse or promote products - Neither the name of Internet Society, IETF or IETF Trust, nor
derived from this software without specific prior written permission. the names of specific contributors, may be used to endorse or
promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR OWNER OR CONTRIBUTORS BELIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
POSSIBILITY OF SUCH DAMAGE. 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 Retrieving frame information for IP-MR Speech Codec
******************************************************************/ ******************************************************************/
#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 *data, int curBit) int GetBit(unsigned char *buf, int curBit)
{ {
return ((data[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,
// if base_rate > rate, then assumed unsigned char *buf, // i: coded bit frame
// that base_rate = rate. int size, // i: coded bit frame size in bytes
unsigned char *pCoded, // i: coded bit frame short pLayerBits[RATES_NUM], // o: number of bits in layers
short pLayerBits // o: number of bits in layers short pSenseBits[SENSE_CLASSES], // o: number of bits in
[RATES_NUM], // sensitivity classes
short pSenseBits // o: number of bits in sensitivity classes short *nLayers // o: number of layers
[SENSE_CLASSES],
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,47,43,44, static const short Bits_2[16] = { 43,50,36,31,46,48,40,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 i,nBits = 0;
int FrType; if (rate < 0 || rate > 5) {
int i,nBits; return 0; // incorrect stream
}
if (rate < 0 || rate > 5) { // extract frame type bit if required
return 0; // incorrect stream FrType = GetBit(buf, nBits++) ? FT_SPEECH : FT_DTX_SID;
}
for(i = 0; i < SENSE_CLASSES; i++) { if((FrType != FT_DTX_SID && size < 2) || size < 1) {
pSenseBits[i] = 0; return 0; // not enough input data
} }
for(i = 0; i < SENSE_CLASSES; i++) {
pSenseBits[i] = 0;
}
nBits = 0; {
// extract frame type bit if required int cw_0;
FrType = GetBit(pCoded, nBits++) ? FT_SPEECH : FT_DTX_SID; int b[14];
{
int cw_0;
int b[14];
// extract meaning bits // extract meaning bits
for(i = 0 ; i < 14; i++) { for(i = 0 ; i < 14; i++) {
b[i] = GetBit(pCoded, nBits++); b[i] = GetBit(buf, nBits++);
} }
// parse // parse
if(FrType == FT_DTX_SID) { if(FrType == FT_DTX_SID) {
cw_0 = (b[0]<<0)|(b[1]<<1)|(b[2]<<2)|(b[3]<<3); cw_0 = (b[0]<<0)|(b[1]<<1)|(b[2]<<2)|(b[3]<<3);
rate = 0; rate = 0;
pSenseBits[0] = 10 + Bits_2[cw_0]; pSenseBits[0] = 10 + Bits_2[cw_0];
} else { } else {
int i, idx; int i, idx;
int nFlag_1, nFlag_2, cw_1, cw_2; int nFlag_1, nFlag_2, cw_1, cw_2;
nFlag_1 = b[0] + b[2] + b[4] + b[6]; nFlag_1 = b[0] + b[2] + b[4] + b[6];
cw_1 = (cw_1 << 1) | b[0]; cw_1 = (cw_1 << 1) | b[0];
cw_1 = (cw_1 << 1) | b[2]; cw_1 = (cw_1 << 1) | b[2];
cw_1 = (cw_1 << 1) | b[4]; cw_1 = (cw_1 << 1) | b[4];
cw_1 = (cw_1 << 1) | b[6]; cw_1 = (cw_1 << 1) | b[6];
nFlag_2 = b[1] + b[3] + b[5] + b[7]; nFlag_2 = b[1] + b[3] + b[5] + b[7];
cw_2 = (cw_2 << 1) | b[1]; cw_2 = (cw_2 << 1) | b[1];
cw_2 = (cw_2 << 1) | b[3]; cw_2 = (cw_2 << 1) | b[3];
cw_2 = (cw_2 << 1) | b[5]; cw_2 = (cw_2 << 1) | b[5];
cw_2 = (cw_2 << 1) | b[7]; cw_2 = (cw_2 << 1) | b[7];
cw_0 = (b[10]<<0)|(b[11]<<1)|(b[12]<<2)|(b[13]<<3); cw_0 = (b[10]<<0)|(b[11]<<1)|(b[12]<<2)|(b[13]<<3);
if (base_rate < 0) base_rate = 0; if (base_rate < 0) base_rate = 0;
if (base_rate > rate) base_rate = rate; if (base_rate > rate) base_rate = rate;
idx = base_rate == 0 ? 0 : 1; idx = base_rate == 0 ? 0 : 1;
pSenseBits[0] = 15+Bits_2[cw_0]; pSenseBits[0] = 15+Bits_2[cw_0];
pSenseBits[1] = Bits_1[(cw_1 >> 0)&0x3] + Bits_1[(cw_1>>2)&0x3]; pSenseBits[1] = Bits_1[(cw_1>>0)&0x3] +
pSenseBits[2] = nFlag_1*5; Bits_1[(cw_1>>2)&0x3];
pSenseBits[3] = nFlag_2*30; pSenseBits[2] = nFlag_1*5;
pSenseBits[5] = (4 - nFlag_2)*(Bits_3[idx][0]); pSenseBits[3] = nFlag_2*30;
pSenseBits[5] = (4 - nFlag_2)*(Bits_3[idx][0]);
for (i = 1; i < rate+1; i++) { for (i = 1; i < rate+1; i++) {
pLayerBits[i] = 4*(Bits_3[idx][i]); pLayerBits[i] = 4*Bits_3[idx][i];
} }
} }
pLayerBits[0] = 0; pLayerBits[0] = 0;
for (i = 0; i < SENSE_CLASSES; i++) { for (i = 0; i < SENSE_CLASSES; i++) {
pLayerBits[0] += pSenseBits[i]; pLayerBits[0] += pSenseBits[i];
} }
*nLayers = rate+1; *nLayers = rate+1;
} }
{ {
// count total frame size // count total frame size
int payloadBitCount = 0; int payloadBitCount = 0;
for (i = 0; i < *nLayers; i++) { for (i = 0; i < *nLayers; i++) {
payloadBitCount += pLayerBits[i]; payloadBitCount += pLayerBits[i];
}
return payloadBitCount;
} }
return payloadBitCount;
}
} }
 End of changes. 42 change blocks. 
131 lines changed or deleted 152 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/