draft-ietf-avt-rtp-ipmr-04.txt   draft-ietf-avt-rtp-ipmr-05.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: Informational May 20, 2009 Intended status: Informational August 18, 2009
RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-04.txt RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Copyright (c) 2009 IETF Trust and the persons identified as the document Copyright (c) 2009 IETF Trust and the persons identified as the document
authors. All rights reserved. authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions This document is subject to BCP 78 and the IETF Trust's Legal Provisions
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
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 November 20, 2009. This Internet-Draft will expire on February 18, 2010.
Abstract Abstract
This document specifies the payload format for packetization of SPIRIT This document specifies the payload format for packetization of SPIRIT
IP-MR encoded speech signals into the Real-time Transport Protocol IP-MR encoded speech signals into the Real-time Transport Protocol
(RTP). The payload format supports transmission of multiple frames per (RTP). The payload format supports transmission of multiple frames per
payload and introduced redundancy for robustness against packet loss. payload and introduced redundancy for robustness against packet loss.
Table of Contents Table of Contents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.8. Redundancy Data..............................................9 3.8. Redundancy Data..............................................9
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. Media Type Registration..........................................11 5. Media Type Registration..........................................11
5.1. Registration of media subtype audio/ip-mr_v2.5..............11 5.1. Registration of media subtype audio/ip-mr_v2.5..............11
5.2. Mapping Media Type Parameters into SDP......................12 5.2. Mapping Media Type Parameters into SDP......................12
6. Security Considerations..........................................13 6. Security Considerations..........................................13
7. Congestion Control...............................................13 7. Congestion Control...............................................13
8. IANA Considerations..............................................14 8. IANA Considerations..............................................14
9. Normative References.............................................15 9. Normative References.............................................14
10. Author(s) Information ..........................................15 10. Author(s) Information...........................................15
11. Disclaimer......................................................15 11. Disclaimer......................................................15
12. Legal Terms.....................................................16 12. Legal Terms.....................................................15
APPENDIX A. RETRIEVING FRAME INFORMATION............................17
A.1. get_frame_info.c...............................................17
Authors' Addresses..................................................19
1. Introduction 1. Introduction
This document specifies the payload format for packetization of SPIRIT This document specifies the payload format for packetization of SPIRIT
IP-MR encoded speech signals into the Real-time Transport Protocol IP-MR encoded speech signals into the Real-time Transport Protocol
(RTP). The payload format supports transmission of multiple frames per (RTP). The payload format supports transmission of multiple frames per
payload and introduced redundancy for robustness against packet loss. payload and introduced redundancy for robustness against packet loss.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 3, line 36 skipping to change at page 3, line 36
rates ranging from about 7.7 to about 34.2 kbps. The coding mode can be rates ranging from about 7.7 to about 34.2 kbps. The coding mode can be
changed at any 20 ms frame boundary making possible to dynamically changed at any 20 ms frame boundary making possible to dynamically
adjust the speech encoding rate during a session to adapt to the varying adjust the speech encoding rate during a session to adapt to the varying
transmission conditions. transmission conditions.
The coded frame consists of multiple coding layers - base (or core) The coded frame consists of multiple coding layers - base (or core)
layer and several enhancement layers which are coded independently. layer and several enhancement layers which are coded independently.
Onlythe core layer is mandatory to decode understandable speech and Onlythe core layer is mandatory to decode understandable speech and
upper layers provide quality enhancement. These enhancement layers upper layers provide quality enhancement. These enhancement layers
may be omitted and remaining base layer can be meaningfully decoded may be omitted and remaining base layer can be meaningfully decoded
without artifacts. This making the bit stream scalable and allows without artifacts. This makes the bit stream scalable and allows
reduce bit rate during transmission without re-encoding. to reduce bit rate during transmission without re-encoding.
This memo specifies an optional form of redundancy coding within RTP This memo specifies an optional form of redundancy coding within RTP
for protection against packet loss. It is based on commonly known for protection against packet loss. It is based on commonly known
scheme when previously transmitted frames are aggregated together scheme when previously transmitted frames are aggregated together
with new ones. Each frame is retransmitted once in the following with new ones. Each frame is retransmitted once in the following
RTP payload packet. f(n-2)...f(n+4) denote a sequence of speech RTP payload packet. f(n-2)...f(n+4) denotes a sequence of speech
frames, and p(n-1)...p(n+4) a sequence of payload packets: frames, and p(n-1)...p(n+4) is a sequence of payload packets:
--+--------+--------+--------+--------+--------+--------+--------+-- --+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+-- --+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ----> <---- p(n-1) ---->
<----- p(n) -----> <----- p(n) ----->
<---- p(n+1) ----> <---- p(n+1) ---->
<---- p(n+2) ----> <---- p(n+2) ---->
<---- p(n+3) ----> <---- p(n+3) ---->
skipping to change at page 4, line 21 skipping to change at page 4, line 21
between overhead and robustness against packet loss. between overhead and robustness against packet loss.
The mechanism described does not really require signaling at the session The mechanism described does not really require signaling at the session
setup. The sender is responsible for selecting an appropriate amount of setup. The sender is responsible for selecting an appropriate amount of
redundancy based on feedback about the channel conditions. redundancy based on feedback about the channel conditions.
The main codec characteristics can be summarized as follows: The main codec characteristics can be summarized as follows:
o Wideband, 16 kHz, speech codec o Wideband, 16 kHz, speech codec
o Adaptive multi rate with six modes from about 7.7 to about o Adaptive multi rate with six modes from about 7.7 to 34.2 kbps
34.2 kbps
o Bit rate scalable o Bit rate scalable
o Variable bit rate changing in accordance with actual speech o Variable bit rate changing in accordance with actual speech
content content
o Discontinuous Transmission (DTX), silence suppression and o Discontinuous Transmission (DTX), silence suppression and
comfort noise generation comfort noise generation
o In-band redundancy scheme for protection against packet loss o In-band redundancy scheme for protection against packet loss
3. Payload Format 3. Payload Format
The main purpose of the payload design for IP-MR is to maximize the The main purpose of the payload design for IP-MR is to maximize the
potential of the codec with as minimal overhead as possible. The payload potential of the codec with as minimal overhead as possible. The payload
format allows changing parameters of the codecs (such as bit rate, format allows changing parameters of the codec (such as bit rate,
level of scalability, DTX and redundancy mode) without re-negotiation level of scalability, DTX and redundancy mode) without re-negotiation
at any packet boundary. This make possible dynamically adjust streaming at any packet boundary. This make possible dynamically adjust streaming
parametersin accordance to changing network conditions. The payload parametersin accordance to changing network conditions. The payload
format also supports aggregation of multiple consecutive frames format also supports aggregation of multiple consecutive frames
(up to 4) in a payload. That allows controlling trade-off between (up to 4) in a payload. That allows controlling trade-off between
delay and header overhead. delay and header overhead.
3.1. RTP Header Usage 3.1. RTP Header Usage
The RTP timestamp corresponds to the sampling instant of the first The RTP timestamp corresponds to the sampling instant of the first
skipping to change at page 7, line 21 skipping to change at page 7, line 21
is empty. is empty.
3.5. Speech Data 3.5. Speech Data
Speech data of a payload contains one or more speech frames or comfort Speech data of a payload contains one or more speech frames or comfort
noise frames, as specified in the speech TOC of the payload. noise frames, as specified in the speech TOC of the payload.
Each speech frame represents 20 ms of speech encoded with the rate Each speech frame represents 20 ms of speech encoded with the rate
indicated in the CR and base rate indicated in BR field of the payload indicated in the CR and base rate indicated in BR field of the payload
header. header.
The size of coded speech frame is variable due to the nature of codec. The size of coded speech frame is variable due to the nature of codec.
The Encoder's algorithm decides what size of each frame is and returns The Encoder's algorithm decides what size of each frame is and returns
it after encoding. In order to save bandwidth the size is not placed it after encoding. In order to save bandwidth the size is not placed
into payload obviously. Decoder can calculate frame size by its content into payload obviously. The frame size can be determined by frame's
and returns it to the top level application. This way a size of each content using a special service function specified in Appendix A.
frame can be obtained. Moreover, there is a special service function This function provides complete information about coded frame including
that returns frame size without total decoding which may be used for size, number of layers, size of each layer and size of perceptual
this purpose. sensitive classes.
3.6. Redundancy Header 3.6. Redundancy Header
If a packet contains redundancy (R field of payload header is 1) the If a packet contains redundancy (R field of payload header is 1) the
speech data is followed by redundancy header: speech data is followed by redundancy header:
0 1 2 3 4 5 0 1 2 3 4 5
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| CL1 | CL2 | | CL1 | CL2 |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
skipping to change at page 8, line 21 skipping to change at page 8, line 21
| 3 | CLASS C | | 3 | CLASS C |
| 4 | CLASS D | | 4 | CLASS D |
| 5 | CLASS E | | 5 | CLASS E |
| 6 | CLASS F | | 6 | CLASS F |
| 7 | (reserved) | | 7 | (reserved) |
+-------+-------------------+ +-------+-------------------+
Each specifier takes 3 bits, thus the total redundancy header size is 6 Each specifier takes 3 bits, thus the total redundancy header size is 6
bits. bits.
These classes indicate subjective importance of bits from core layer.
Class A contains the bits most sensitive to errors and lost of these
bits results in a corrupted speech frame which should not be decoded
without applying packet loss concealment (PLC) procedure. Class B is
less sensitive than class A and so on to F. Sum of all bit classes
from A to F composes core layer.
Putting some part (classes of bits) from previous frame into current
packet makes possible to partially decode previous frame in case of
it's lost. Than more information is delivered than less speech quality
degradation will be. Flags CL1 and CL2 specify how many classes from
previous frames current packet contain. E.g. CL1=3 (class C), it means
that packet contains bits from classes A, B and C of previous frame.
If CL1=6 (class F) then whole core layer is included.
3.7. Redundancy Table of Contents 3.7. Redundancy Table of Contents
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkt1 Entries| Pkt2 Entries| | Pkt1 Entries| Pkt2 Entries|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The redundancy TOC contains entries for redundancy frames from preceding The redundancy TOC contains entries for redundancy frames from preceding
and pre-preceding packets. Each entry takes 1 bit like speech TOC entry and pre-preceding packets. Each entry takes 1 bit like speech TOC entry
(3.3): (3.3):
skipping to change at page 9, line 14 skipping to change at page 9, line 21
3.8. Redundancy Data 3.8. Redundancy Data
Redundancy data of a payload contains redundancy information for one or Redundancy data of a payload contains redundancy information for one or
more speech frames or comfort noise frames that may be lost during more speech frames or comfort noise frames that may be lost during
transition, as specified in the redundancy TOC of the payload. Actually transition, as specified in the redundancy TOC of the payload. Actually
redundancy is the most important part of preceding frames representing redundancy is the most important part of preceding frames representing
20 ms of speech. This data MAY be used for partial reconstruction of 20 ms of speech. This data MAY be used for partial reconstruction of
lost frames. The amount of available redundancy is specified by CL flag lost frames. The amount of available redundancy is specified by CL flag
in redundancy header section (3.5). This flag SHOULD be passed to in redundancy header section (3.5). This flag SHOULD be passed to
decoder. The length of redundancy frame is variable and can be 281 decoder. The size of redundancy frame is variable and can be obtained
calculated after decoding. using service function specified in Appendix A.
4. Payload Examples 4. Payload Examples
A few examples to highlight the payload format follow. A few examples to highlight the payload format follow.
4.1. Payload Carrying a Single Frame 4.1. Payload Carrying a Single Frame
The following diagram shows a standard IP-MR payload carrying a single The following diagram shows a standard IP-MR payload carrying a single
speech frame without redundancy: speech frame without redundancy:
skipping to change at page 12, line 23 skipping to change at page 12, line 20
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications that use this media type: Real-time audio applications like Applications that use this media type: Real-time audio applications like
voice over IP and teleconference, and multi-media streaming. voice over IP and teleconference, and multi-media streaming.
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
Elena Berlizova Yuri Morzeev
berlizova@spiritdsp.com morzeev@spiritdsp.com
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and hence Restrictions on usage: This media type depends on RTP framing, and hence
is only defined for transfer via RTP [RFC 3550]. is only defined for transfer via RTP [RFC 3550].
Author: Authors:
Sergey Ikonin <ikonin@spiritdsp.com> Sergey Ikonin <ikonin@spiritdsp.com>
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG. from the IESG.
5.2. Mapping Media Type Parameters into SDP 5.2. Mapping Media Type Parameters into SDP
The information carried in the media type specification has a specific The information carried in the media type specification has a specific
mapping to fields in the Session Description Protocol (SDP) [RFC 4566], mapping to fields in the Session Description Protocol (SDP) [RFC 4566],
which is commonly used to describe RTP sessions. When SDP is used to which is commonly used to describe RTP sessions. When SDP is used to
skipping to change at page 14, line 5 skipping to change at page 14, line 5
of pathological data. of pathological data.
7. Congestion Control 7. Congestion Control
The general congestion control considerations for transporting RTP data The general congestion control considerations for transporting RTP data
apply; see RTP [RFC 3550] and any applicable RTP profile like AVP apply; see RTP [RFC 3550] and any applicable RTP profile like AVP
[RFC 3551]. However, the multi-rate capability of IP-MR speech coding [RFC 3551]. However, the multi-rate capability of IP-MR speech coding
provides a mechanism that may help to control congestion, since the provides a mechanism that may help to control congestion, since the
bandwidth demand can be adjusted by selecting a different encoding mode. bandwidth demand can be adjusted by selecting a different encoding mode.
The bit rate scalability of IP-MR codec allows reducing voice traffic
by omitting enhancement layers without re-encoding. This provides
additional means for congestion control. Some intermediate network
node MAY modify the IP-MR RTP payload by dropping some of the layers
during transmission to meet the available bandwidth requirements. In
case the payload is forwarded with modified content at least the base
layer MUST be preserved in the payload which is being delivered to
receiving side guarantees meaningful speech decoding without packet
loss concealment procedure.
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 overhead constraints. Packetizing more frames in each RTP payload
can reduce the number of packets sent and hence the overhead from can 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.
If in-band redundancy scheme is used to protect against packet loss, If in-band redundancy scheme is used to protect against packet loss,
the amount of introduced redundancy will need to be regulated so that the amount of introduced redundancy will need to be regulated so that
the use of redundancy itself does not cause a congestion problem. In the use of redundancy itself does not cause a congestion problem. In
other words, a sender SHALL NOT increase the total bitrate when adding other words, a sender SHALL NOT increase the total bitrate when adding
skipping to change at page 15, line 32 skipping to change at page 15, line 5
K., "The Secure Real-Time Transport Protocol (SRTP)", RFC K., "The Secure Real-Time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[RFC 5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC 5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[RFC 4301] Kent, S. and K. Seo, "Security Architecture for the [RFC 4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
10. Author(s) Information 10. Author(s) Information:
Sergey Ikonin Sergey Ikonin
email: ikonin@spiritdsp.com email: ikonin@spiritdsp.com
Russia 109004 Russia 109004
Building 27, A. Solgenizyn street Building 27, A. Solgenizyn street
Tel: +7 495 661-2178 Tel: +7 495 661-2178
Fax: +7 495 912-6786 Fax: +7 495 912-6786
11. Disclaimer 11. Disclaimer
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
skipping to change at line 690 skipping to change at page 17, line 4
definitive versions of these Legal Provisions. definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of the Process licenses each Contribution that he or she makes as part of the
IETF Standards Process to the IETF Trust pursuant to the provisions of IETF Standards Process to the IETF Trust pursuant to the provisions of
RFC 5378. No language to the contrary, or terms, conditions or rights RFC 5378. No language to the contrary, or terms, conditions or rights
that differ from or are inconsistent with the rights and licenses that differ from or are inconsistent with the rights and licenses
granted under RFC 5378, shall have any effect and shall be null and granted under RFC 5378, shall have any effect and shall be null and
void, whether published or posted by such Contributor, or included with void, whether published or posted by such Contributor, or included with
or in such Contribution. or in such Contribution.
APPENDIX A. RETRIEVING FRAME INFORMATION
This appendix contains the c-code for implementation of frame parsing
function. This function extracts information about coded frame including
frame size, number of layers, size of each layer and size of perceptual
sensitive classes.
A.1. get_frame_info.c
/******************************************************************
get_frame_info.c
Retrieving frame information for IP-MR Speech Codec
******************************************************************/
#define RATES_NUM 6 // number of codec rates
#define SENSE_CLASSES 6 // number of sensitivity classes (A..F)
// frame types
#define FT_DTX_SPEECH 0 // active speech in DTX mode
#define FT_DTX_SID 1 // silence insertion descriptor
#define FT_NO_DTX 2 // no DTX frame
// get specified bit from coded data
int GetBit(unsigned char *data, int curBit)
{
return ((data[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,
// if base_rate > rate, then assumed
// that base_rate = rate.
short allow_DTX, // i: flag of DTX mode
unsigned char *pCoded, // i: coded bit frame
short pLayerBits // o: number of bits in layers
[RATES_NUM],
short pSenseBits // o: number of bits in sensitivity classes
[SENSE_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;
if (rate < 0 || rate > 5) {
return 0; // incorrect stream
}
for(i = 0; i < SENSE_CLASSES; i++) {
pSenseBits[i] = 0;
}
nBits = 0;
// extract frame type bit if required
if (allow_DTX) {
FrType = GetBit(pCoded, nBits++) ? FT_DTX_SPEECH : FT_DTX_SID;
} else {
FrType = FT_NO_DTX;
}
{
int cw_0;
int b[14];
// extract meaning bits
for(i = 0 ; i < 14; i++) {
b[i] = GetBit(pCoded, nBits++);
}
// parse
if(FrType == FT_DTX_SID) {
cw_0 = (b[0]<<0)|(b[1]<<1)|(b[2]<<2)|(b[3]<<3);
rate = 0;
pSenseBits[0] = 10 + Bits_2[cw_0];
} else {
int i, idx;
int nFlag_1, nFlag_2, cw_1, cw_2;
nFlag_1 = b[0] + b[2] + b[4] + b[6];
cw_1 = (cw_1 << 1) | b[0];
cw_1 = (cw_1 << 1) | b[2];
cw_1 = (cw_1 << 1) | b[4];
cw_1 = (cw_1 << 1) | b[6];
nFlag_2 = b[1] + b[3] + b[5] + b[7];
cw_2 = (cw_2 << 1) | b[1];
cw_2 = (cw_2 << 1) | b[3];
cw_2 = (cw_2 << 1) | b[5];
cw_2 = (cw_2 << 1) | b[7];
cw_0 = (b[10]<<0)|(b[11]<<1)|(b[12]<<2)|(b[13]<<3);
if (base_rate < 0) base_rate = 0;
if (base_rate > rate) base_rate = rate;
idx = base_rate == 0 ? 0 : 1;
pSenseBits[0] = (FrType == FT_DTX_SPEECH ? 1:0)+14+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;
}
}
Authors' Addresses
SPIRIT DSP
Building 27, A. Solgenizyn street
109004, Moscow, RUSSIA
Tel: +7 495 661-2178
Fax: +7 495 912-6786
EMail: ikonin@spiritdsp.com
 End of changes. 19 change blocks. 
35 lines changed or deleted 42 lines changed or added

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