ref: 154486bb830ae2905ca92135f027ff7911aa567f
dir: /doc/draft-ietf-codec-opus.xml/
<?xml version='1.0'?> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd'> <?rfc toc="yes" symrefs="yes" ?> <rfc ipr="trust200902" category="std" docName="draft-ietf-codec-opus-02"> <front> <title abbrev="Interactive Audio Codec">Definition of the Opus Audio Codec</title> <author initials="JM" surname="Valin" fullname="Jean-Marc Valin"> <organization>Octasic Inc.</organization> <address> <postal> <street>4101, Molson Street</street> <city>Montreal</city> <region>Quebec</region> <code></code> <country>Canada</country> </postal> <phone>+1 514 282-8858</phone> <email>[email protected]</email> </address> </author> <author initials="K." surname="Vos" fullname="Koen Vos"> <organization>Skype Technologies S.A.</organization> <address> <postal> <street>Stadsgarden 6</street> <city>Stockholm</city> <region></region> <code>11645</code> <country>SE</country> </postal> <phone>+46 855 921 989</phone> <email>[email protected]</email> </address> </author> <date day="14" month="November" year="2010" /> <area>General</area> <workgroup></workgroup> <abstract> <t> This document describes the Opus codec, designed for interactive speech and audio transmission over the Internet. </t> </abstract> </front> <middle> <section anchor="introduction" title="Introduction"> <t> We propose the Opus codec based on a linear prediction layer (LP) and an MDCT-based enhancement layer. The main idea behind the proposal is that the speech low frequencies are usually more efficiently coded using linear prediction codecs (such as CELP variants), while the higher frequencies are more efficiently coded in the transform domain (e.g. MDCT). For low sampling rates, the MDCT layer is not useful and only the LP-based layer is used. On the other hand, non-speech signals are not always adequately coded using linear prediction, so for music only the MDCT-based layer is used. </t> <t> In this proposed prototype, the LP layer is based on the <eref target='http://developer.skype.com/silk'>SILK</eref> codec <xref target="SILK"></xref> and the MDCT layer is based on the <eref target='http://www.celt-codec.org/'>CELT</eref> codec <xref target="CELT"></xref>. </t> <t>This is a work in progress.</t> </section> <section anchor="hybrid" title="Opus Codec"> <t> In hybrid mode, each frame is coded first by the LP layer and then by the MDCT layer. In the current prototype, the cutoff frequency is 8 kHz. In the MDCT layer, all bands below 8 kHz are discarded, such that there is no coding redundancy between the two layers. Also both layers use the same instance of the range coder to encode the signal, which ensures that no "padding bits" are wasted. The hybrid approach makes it easy to support both constant bit-rate (CBR) and varaible bit-rate (VBR) coding. Although the SILK layer used is VBR, it is easy to make the bit allocation of the CELT layer produce a final stream that is CBR by using all the bits left unused by the SILK layer. </t> <t>The implementation of SILK-based LP layer is similar to the description in the <xref target="SILK">SILK Internet-Draft</xref> with the main exception that SILK was modified to use the same range coder as CELT. The implementation of the CELT-based MDCT layer is available from the CELT website and is a more recent version (0.8.1) of the <xref target="CELT">CELT Internet-Draft</xref>. The main changes include better support for 20 ms frames as well as the ability to encode only the higher bands using a range coder partially filled by the SILK layer.</t> <t> In addition to their frame size, the SILK and CELT codecs require a look-ahead of 5.2 ms and 2.5 ms, respectively. SILK's look-ahead is due to noise shaping estimation (5 ms) and the internal resampling (0.2 ms), while CELT's look-ahead is due to the overlapping MDCT windows. To compensate for the difference, the CELT encoder input is delayed by 2.7 ms. This ensures that low frequencies and high frequencies arrive at the same time. </t> <section title="Source Code"> <t> The source code is currently available in a <eref target='git://git.xiph.org/users/jm/ietfcodec.git'>Git repository</eref> which references two other repositories (for SILK and CELT). Some snapshots are provided for convenience at <eref target='http://people.xiph.org/~jm/ietfcodec/'/> along with sample files. Although the build system is very primitive, some instructions are provided in the toplevel README file. This is very early development so both the quality and feature set should greatly improve over time. In the current version, only 48 kHz audio is supported, but support for all configurations listed in <xref target="modes"></xref> is planned. </t> </section> </section> <section anchor="modes" title="Codec Modes"> <t> There are three possible operating modes for the proposed prototype: <list style="numbers"> <t>A linear prediction (LP) mode for use in low bit-rate connections with up to 8 kHz audio bandwidth (16 kHz sampling rate)</t> <t>A hybrid (LP+MDCT) mode for full-bandwidth speech at medium bitrates</t> <t>An MDCT-only mode for very low delay speech transmission as well as music transmission.</t> </list> Each of these modes supports a number of difference frame sizes and sampling rates. In order to distinguish between the various modes and configurations, we need to define a simple header that can used in the transport layer (e.g RTP) to signal this information. The following describes the proposed header. </t> <t> The LP mode supports the following configurations (numbered from 00000...01011 in binary): <list style="symbols"> <t>8 kHz: 10, 20, 40, 60 ms (00000...00011)</t> <t>12 kHz: 10, 20, 40, 60 ms (00100...00111)</t> <t>16 kHz: 10, 20, 40, 60 ms (01000...01011)</t> </list> for a total of 12 configurations. </t> <t> The hybrid mode supports the following configurations (numbered from 01100...01111): <list style="symbols"> <t>32 kHz: 10, 20 ms (01100...01101)</t> <t>48 kHz: 10, 20 ms (01110...01111)</t> </list> for a total of 4 configurations. </t> <t> The MDCT-only mode supports the following configurations (numbered from 10000...11101): <list style="symbols"> <t>8 kHz: 2.5, 5, 10, 20 ms (10000...10011)</t> <t>16 kHz: 2.5, 5, 10, 20 ms (10100...10111)</t> <t>32 kHz: 2.5, 5, 10, 20 ms (11000...11011)</t> <t>48 kHz: 2.5, 5, 10, 20 ms (11100...11111)</t> </list> for a total of 16 configurations. </t> <t> There is thus a total of 32 configurations, so 5 bits are necessary to indicate the mode, frame size and sampling rate (MFS). This leaves 3 bits for the number of frames per packets (codes 0 to 7): <list style="symbols"> <t>0-2: 1-3 frames in the packet, each with equal compressed size</t> <t>3: arbitrary number of frames in the packet, each with equal compressed size (one size needs to be encoded)</t> <t>4-5: 2-3 frames in the packet, with different compressed sizes, which need to be encoded (except the last one)</t> <t>6: arbitrary number of frames in the packet, with different compressed sizes, each of which needs to be encoded</t> <t>7: The first frame has this MFS, but others have different MFS. Each compressed size needs to be encoded.</t> </list> When code 7 is used and the last frames of a packet have the same MFS, it is allowed to switch to another code for them. </t> <t> The compressed size of the frames (if needed) is indicated -- usually -- with one byte, with the following meaning: <list style="symbols"> <t>0: No frame (DTX or lost packet)</t> <t>1-251: Size of the frame in bytes</t> <t>252-255: A second byte is needed. The total size is (size[1]*4)+(size[0]%4)+252</t> </list> </t> <t> The maximum size representable is 255*4+3+252=1275 bytes. For 20 ms frames, that represents a bit-rate of 510 kb/s, which is really the highest rate anyone would want to use in stereo mode (beyond that point, lossless codecs would be more appropriate). </t> <section anchor="examples" title="Examples"> <t> Simplest case: one packet </t> <t> <figure> <artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MFS |0|0|0| compressed data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </t> <t> Four frames of the same compressed size: </t> <t> <figure> <artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MFS |0|1|1| compressed data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </t> <t> Two frames of different compressed size: </t> <t> <figure> <artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MFS |1|0|1| frame size | compressed data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </t> <t> Three frames of different <spanx style="emph">durations</spanx>: </t> <t> <figure> <artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1st MFS |1|1|1| frame size | 2nd MFS |1|1|1| frame size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3rd MFS |1|1|1| frame size | compressed data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </t> </section> </section> <section title="Codec Encoder"> <t> Opus encoder block diagram. </t> <section anchor="range-encoder" title="Range Coder"> <t> Opus uses an entropy coder based upon <xref target="range-coding"></xref>, which is itself a rediscovery of the FIFO arithmetic code introduced by <xref target="coding-thesis"></xref>. It is very similar to arithmetic encoding, except that encoding is done with digits in any base instead of with bits, so it is faster when using larger bases (i.e.: an octet). All of the calculations in the range coder must use bit-exact integer arithmetic. </t> <t> The range coder also acts as the bit-packer for Opus. It is used in three different ways, to encode: <list style="symbols"> <t>entropy-coded symbols with a fixed probability model using ec_encode(), (rangeenc.c)</t> <t>integers from 0 to 2^M-1 using ec_enc_uint() or ec_enc_bits(), (entenc.c)</t> <t>integers from 0 to N-1 (where N is not a power of two) using ec_enc_uint(). (entenc.c)</t> </list> </t> <t> The range encoder maintains an internal state vector composed of the four-tuple (low,rng,rem,ext), representing the low end of the current range, the size of the current range, a single buffered output octet, and a count of additional carry-propagating output octets. Both rng and low are 32-bit unsigned integer values, rem is an octet value or the special value -1, and ext is an integer with at least 16 bits. This state vector is initialized at the start of each each frame to the value (0,2^31,-1,0). </t> <t> Each symbol is drawn from a finite alphabet and coded in a separate context which describes the size of the alphabet and the relative frequency of each symbol in that alphabet. Opus only uses static contexts; they are not adapted to the statistics of the data that is coded. </t> <section anchor="encoding-symbols" title="Encoding Symbols"> <t> The main encoding function is ec_encode() (rangeenc.c), which takes as an argument a three-tuple (fl,fh,ft) describing the range of the symbol to be encoded in the current context, with 0 <= fl < fh <= ft <= 65535. The values of this tuple are derived from the probability model for the symbol. Let f(i) be the frequency of the ith symbol in the current context. Then the three-tuple corresponding to the kth symbol is given by <![CDATA[ fl=sum(f(i),i<k), fh=fl+f(i), and ft=sum(f(i)). ]]> </t> <t> ec_encode() updates the state of the encoder as follows. If fl is greater than zero, then low = low + rng - (rng/ft)*(ft-fl) and rng = (rng/ft)*(fh-fl). Otherwise, low is unchanged and rng = rng - (rng/ft)*(fh-fl). The divisions here are exact integer division. After this update, the range is normalized. </t> <t> To normalize the range, the following process is repeated until rng > 2^23. First, the top 9 bits of low, (low>>23), are placed into a carry buffer. Then, low is set to <![CDATA[(low << 8 & 0x7FFFFFFF) and rng is set to (rng<<8)]]>. This process is carried out by ec_enc_normalize() (rangeenc.c). </t> <t> The 9 bits produced in each iteration of the normalization loop consist of 8 data bits and a carry flag. The final value of the output bits is not determined until carry propagation is accounted for. Therefore the reference implementation buffers a single (non-propagating) output octet and keeps a count of additional propagating (0xFF) output octets. An implementation MAY choose to use any mathematically equivalent scheme to perform carry propagation. </t> <t> The function ec_enc_carry_out() (rangeenc.c) performs this buffering. It takes a 9-bit input value, c, from the normalization 8-bit output and a carry bit. If c is 0xFF, then ext is incremented and no octets are output. Otherwise, if rem is not the special value -1, then the octet (rem+(c>>8)) is output. Then ext octets are output with the value 0 if the carry bit is set, or 0xFF if it is not, and rem is set to the lower 8 bits of c. After this, ext is set to zero. </t> <t> In the reference implementation, a special version of ec_encode() called ec_encode_bin() (rangeenc.c) is defined to take a two-tuple (fl,ftb), where <![CDATA[0 <= fl < 2^ftb and ftb < 16. It is mathematically equivalent to calling ec_encode() with the three-tuple (fl,fl+1,1<<ftb)]]>, but avoids using division. </t> </section> <section anchor="encoding-ints" title="Encoding Uniformly Distributed Integers"> <t> Functions ec_enc_uint() or ec_enc_bits() are based on ec_encode() and encode one of N equiprobable symbols, each with a frequency of 1, where N may be as large as 2^32-1. Because ec_encode() is limited to a total frequency of 2^16-1, this is done by encoding a series of symbols in smaller contexts. </t> <t> ec_enc_bits() (entenc.c) is defined, like ec_encode_bin(), to take a two-tuple (fl,ftb), with <![CDATA[0 <= fl < 2^ftb and ftb < 32. While ftb is greater than 8, it encodes bits (ftb-8) to (ftb-1) of fl, e.g., (fl>>ftb-8&0xFF) using ec_encode_bin() and subtracts 8 from ftb. Then, it encodes the remaining bits of fl, e.g., (fl&(1<<ftb)-1)]]>, again using ec_encode_bin(). </t> <t> ec_enc_uint() (entenc.c) takes a two-tuple (fl,ft), where ft is not necessarily a power of two. Let ftb be the location of the highest 1 bit in the two's-complement representation of (ft-1), or -1 if no bits are set. If ftb>8, then the top 8 bits of fl are encoded using ec_encode() with the three-tuple (fl>>ftb-8,(fl>>ftb-8)+1,(ft-1>>ftb-8)+1), and the remaining bits are encoded with ec_enc_bits using the two-tuple <![CDATA[(fl&(1<<ftb-8)-1,ftb-8). Otherwise, fl is encoded with ec_encode() directly using the three-tuple (fl,fl+1,ft)]]>. </t> </section> <section anchor="encoder-finalizing" title="Finalizing the Stream"> <t> After all symbols are encoded, the stream must be finalized by outputting a value inside the current range. Let end be the integer in the interval [low,low+rng) with the largest number of trailing zero bits. Then while end is not zero, the top 9 bits of end, e.g., <![CDATA[(end>>23), are sent to the carry buffer, and end is replaced by (end<<8&0x7FFFFFFF). Finally, if the value in carry buffer, rem, is]]> neither zero nor the special value -1, or the carry count, ext, is greater than zero, then 9 zero bits are sent to the carry buffer. After the carry buffer is finished outputting octets, the rest of the output buffer is padded with zero octets. Finally, rem is set to the special value -1. This process is implemented by ec_enc_done() (rangeenc.c). </t> </section> <section anchor="encoder-tell" title="Current Bit Usage"> <t> The bit allocation routines in Opus need to be able to determine a conservative upper bound on the number of bits that have been used to encode the current frame thus far. This drives allocation decisions and ensures that the range code will not overflow the output buffer. This is computed in the reference implementation to fractional bit precision by the function ec_enc_tell() (rangeenc.c). Like all operations in the range encoder, it must be implemented in a bit-exact manner. </t> </section> </section> <section title="SILK Encoder"> <t> Copy from SILK draft. </t> </section> <section title="CELT Encoder"> <t> Copy from CELT draft. </t> </section> </section> <section title="Codec Decoder"> <t> Opus decoder block diagram. </t> <section anchor="range-decoder" title="Range Decoder"> <t> The range decoder extracts the symbols and integers encoded using the range encoder in <xref target="range-encoder"></xref>. The range decoder maintains an internal state vector composed of the two-tuple (dif,rng), representing the difference between the high end of the current range and the actual coded value, and the size of the current range, respectively. Both dif and rng are 32-bit unsigned integer values. rng is initialized to 2^7. dif is initialized to rng minus the top 7 bits of the first input octet. Then the range is immediately normalized, using the procedure described in the following section. </t> <section anchor="decoding-symbols" title="Decoding Symbols"> <t> Decoding symbols is a two-step process. The first step determines a value fs that lies within the range of some symbol in the current context. The second step updates the range decoder state with the three-tuple (fl,fh,ft) corresponding to that symbol, as defined in <xref target="encoding-symbols"></xref>. </t> <t> The first step is implemented by ec_decode() (rangedec.c), and computes fs = ft-min((dif-1)/(rng/ft)+1,ft), where ft is the sum of the frequency counts in the current context, as described in <xref target="encoding-symbols"></xref>. The divisions here are exact integer division. </t> <t> In the reference implementation, a special version of ec_decode() called ec_decode_bin() (rangeenc.c) is defined using the parameter ftb instead of ft. It is mathematically equivalent to calling ec_decode() with ft = (1<<ftb), but avoids one of the divisions. </t> <t> The decoder then identifies the symbol in the current context corresponding to fs; i.e., the one whose three-tuple (fl,fh,ft) satisfies fl <= fs < fh. This tuple is used to update the decoder state according to dif = dif - (rng/ft)*(ft-fh), and if fl is greater than zero, rng = (rng/ft)*(fh-fl), or otherwise rng = rng - (rng/ft)*(ft-fh). After this update, the range is normalized. </t> <t> To normalize the range, the following process is repeated until rng > 2^23. First, rng is set to (rng<8)&0xFFFFFFFF. Then the next 8 bits of input are read into sym, using the remaining bit from the previous input octet as the high bit of sym, and the top 7 bits of the next octet for the remaining bits of sym. If no more input octets remain, zero bits are used instead. Then, dif is set to (dif<<8)-sym&0xFFFFFFFF (i.e., using wrap-around if the subtraction overflows a 32-bit register). Finally, if dif is larger than 2^31, dif is then set to dif - 2^31. This process is carried out by ec_dec_normalize() (rangedec.c). </t> </section> <section anchor="decoding-ints" title="Decoding Uniformly Distributed Integers"> <t> Functions ec_dec_uint() or ec_dec_bits() are based on ec_decode() and decode one of N equiprobable symbols, each with a frequency of 1, where N may be as large as 2^32-1. Because ec_decode() is limited to a total frequency of 2^16-1, this is done by decoding a series of symbols in smaller contexts. </t> <t> ec_dec_bits() (entdec.c) is defined, like ec_decode_bin(), to take a single parameter ftb, with ftb < 32. and ftb < 32, and produces an ftb-bit decoded integer value, t, initialized to zero. While ftb is greater than 8, it decodes the next 8 most significant bits of the integer, s = ec_decode_bin(8), updates the decoder state with the 3-tuple (s,s+1,256), adds those bits to the current value of t, t = t<<8 | s, and subtracts 8 from ftb. Then it decodes the remaining bits of the integer, s = ec_decode_bin(ftb), updates the decoder state with the 3 tuple (s,s+1,1<<ftb), and adds those bits to the final values of t, t = t<<ftb | s. </t> <t> ec_dec_uint() (entdec.c) takes a single parameter, ft, which is not necessarily a power of two, and returns an integer, t, with a value between 0 and ft-1, inclusive, which is initialized to zero. Let ftb be the location of the highest 1 bit in the two's-complement representation of (ft-1), or -1 if no bits are set. If ftb>8, then the top 8 bits of t are decoded using t = ec_decode((ft-1>>ftb-8)+1), the decoder state is updated with the three-tuple (s,s+1,(ft-1>>ftb-8)+1), and the remaining bits are decoded with t = t<<ftb-8|ec_dec_bits(ftb-8). If, at this point, t >= ft, then the current frame is corrupt, and decoding should stop. If the original value of ftb was not greater than 8, then t is decoded with t = ec_decode(ft), and the decoder state is updated with the three-tuple (t,t+1,ft). </t> </section> <section anchor="decoder-tell" title="Current Bit Usage"> <t> The bit allocation routines in CELT need to be able to determine a conservative upper bound on the number of bits that have been used to decode from the current frame thus far. This drives allocation decisions which must match those made in the encoder. This is computed in the reference implementation to fractional bit precision by the function ec_dec_tell() (rangedec.c). Like all operations in the range decoder, it must be implemented in a bit-exact manner, and must produce exactly the same value returned by ec_enc_tell() after encoding the same symbols. </t> </section> </section> <section title="SILK Decoder"> <t> Copy from SILK draft. </t> </section> <section title="CELT Decoder"> <t> Insert decoder figure. </t> <t> The decoder extracts information from the range-coded bit-stream in the same order as it was encoded by the encoder. In some circumstances, it is possible for a decoded value to be out of range due to a very small amount of redundancy in the encoding of large integers by the range coder. In that case, the decoder should assume there has been an error in the coding, decoding, or transmission and SHOULD take measures to conceal the error and/or report to the application that a problem has occurred. </t> <section anchor="energy-decoding" title="Energy Envelope Decoding"> <t> The energy of each band is extracted from the bit-stream in two steps according to the same coarse-fine strategy used in the encoder. First, the coarse energy is decoded in unquant_coarse_energy() (quant_bands.c) based on the probability of the Laplace model used by the encoder. </t> <t> After the coarse energy is decoded, the same allocation function as used in the encoder is called. This determines the number of bits to decode for the fine energy quantization. The decoding of the fine energy bits is performed by unquant_fine_energy() (quant_bands.c). Finally, like the encoder, the remaining bits in the stream (that would otherwise go unused) are decoded using unquant_energy_finalise() (quant_bands.c). </t> </section> <section anchor="pitch-decoding" title="Pitch prediction decoding"> <t> If the pitch bit is set, then the pitch period is extracted from the bit-stream. The pitch gain bits are extracted within the PVQ decoding as encoded by the encoder. When the folding bit is set, the folding prediction is computed in exactly the same way as the encoder, with the same gain, by the function intra_fold() (vq.c). </t> </section> <section anchor="PVQ-decoder" title="Spherical VQ Decoder"> <t> In order to correctly decode the PVQ codewords, the decoder must perform exactly the same bits to pulses conversion as the encoder. </t> <section anchor="cwrs-decoder" title="Index Decoding"> <t> The decoding of the codeword from the index is performed as specified in <xref target="PVQ"></xref>, as implemented in function decode_pulses() (cwrs.c). </t> </section> <section anchor="normalised-decoding" title="Normalised Vector Decoding"> <t> The spherical codebook is decoded by alg_unquant() (vq.c). The index of the PVQ entry is obtained from the range coder and converted to a pulse vector by decode_pulses() (cwrs.c). </t> <t>The decoded normalized vector for each band is equal to</t> <t>X' = y/||y||,</t> <t> This operation is implemented in mix_pitch_and_residual() (vq.c), which is the same function as used in the encoder. </t> </section> </section> <section anchor="denormalization" title="Denormalization"> <t> Just like each band was normalized in the encoder, the last step of the decoder before the inverse MDCT is to denormalize the bands. Each decoded normalized band is multiplied by the square root of the decoded energy. This is done by denormalise_bands() (bands.c). </t> </section> <section anchor="inverse-mdct" title="Inverse MDCT"> <t>The inverse MDCT implementation has no special characteristics. The input is N frequency-domain samples and the output is 2*N time-domain samples, while scaling by 1/2. The output is windowed using the same window as the encoder. The IMDCT and windowing are performed by mdct_backward (mdct.c). If a time-domain pre-emphasis window was applied in the encoder, the (inverse) time-domain de-emphasis window is applied on the IMDCT result. After the overlap-add process, the signal is de-emphasized using the inverse of the pre-emphasis filter used in the encoder: 1/A(z)=1/(1-alpha_p*z^-1). </t> </section> <section anchor="Packet Loss Concealment" title="Packet Loss Concealment (PLC)"> <t> Packet loss concealment (PLC) is an optional decoder-side feature which SHOULD be included when transmitting over an unreliable channel. Because PLC is not part of the bit-stream, there are several possible ways to implement PLC with different complexity/quality trade-offs. The PLC in the reference implementation finds a periodicity in the decoded signal and repeats the windowed waveform using the pitch offset. The windowed waveform is overlapped in such a way as to preserve the time-domain aliasing cancellation with the previous frame and the next frame. This is implemented in celt_decode_lost() (mdct.c). </t> </section> </section> </section> <section anchor="security" title="Security Considerations"> <t> The codec needs to take appropriate security considerations into account, as outlined in <xref target="DOS"/> and <xref target="SECGUIDE"/>. It is extremely important for the decoder to be robust against malicious payloads. Malicious payloads must not cause the decoder to overrun its allocated memory or to take much more resources to decode. Although problems in encoders are typically rarer, the same applies to the encoder. Malicious audio stream must not cause the encoder to misbehave because this would allow an attacker to attack transcoding gateways. </t> <t> In its current version, the Opus codec likely does NOT meet these security considerations, so it should be used with caution. </t> </section> <section title="IANA Considerations "> <t> This document has no actions for IANA. </t> </section> <section anchor="Acknowledgments" title="Acknowledgments"> <t> Thanks to all other developers, including Raymond Chen, Soeren Skak Jensen, Gregory Maxwell, Christopher Montgomery, Karsten Vandborg Soerensen, and Timothy Terriberry. </t> </section> </middle> <back> <references title="Informative References"> <reference anchor='SILK'> <front> <title>SILK Speech Codec</title> <author initials='K.' surname='Vos' fullname='K. Vos'> <organization /></author> <author initials='S.' surname='Jensen' fullname='S. Jensen'> <organization /></author> <author initials='K.' surname='Soerensen' fullname='K. Soerensen'> <organization /></author> <date year='2010' month='March' /> <abstract> <t></t> </abstract></front> <seriesInfo name='Internet-Draft' value='draft-vos-silk-01' /> <format type='TXT' target='http://tools.ietf.org/html/draft-vos-silk-01' /> </reference> <reference anchor='CELT'> <front> <title>Constrained-Energy Lapped Transform (CELT) Codec</title> <author initials='J-M.' surname='Valin' fullname='J-M. Valin'> <organization /></author> <author initials='T.' surname='Terriberry' fullname='T. Terriberry'> <organization /></author> <author initials='G.' surname='Maxwell' fullname='G. Maxwell'> <organization /></author> <author initials='C.' surname='Montgomery' fullname='C. Montgomery'> <organization /></author> <date year='2010' month='July' /> <abstract> <t></t> </abstract></front> <seriesInfo name='Internet-Draft' value='draft-valin-celt-codec-02' /> <format type='TXT' target='http://tools.ietf.org/html/draft-valin-celt-codec-02' /> </reference> <reference anchor='DOS'> <front> <title>Internet Denial-of-Service Considerations</title> <author initials='M.' surname='Handley' fullname='M. Handley'> <organization /></author> <author initials='E.' surname='Rescorla' fullname='E. Rescorla'> <organization /></author> <author> <organization>IAB</organization></author> <date year='2006' month='December' /> <abstract> <t>This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.</t></abstract></front> <seriesInfo name='RFC' value='4732' /> <format type='TXT' octets='91844' target='ftp://ftp.isi.edu/in-notes/rfc4732.txt' /> </reference> <reference anchor='SECGUIDE'> <front> <title>Guidelines for Writing RFC Text on Security Considerations</title> <author initials='E.' surname='Rescorla' fullname='E. Rescorla'> <organization /></author> <author initials='B.' surname='Korver' fullname='B. Korver'> <organization /></author> <date year='2003' month='July' /> <abstract> <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front> <seriesInfo name='BCP' value='72' /> <seriesInfo name='RFC' value='3552' /> <format type='TXT' octets='110393' target='ftp://ftp.isi.edu/in-notes/rfc3552.txt' /> </reference> <reference anchor="range-coding"> <front> <title>Range encoding: An algorithm for removing redundancy from a digitised message</title> <author initials="G." surname="Nigel" fullname=""><organization/></author> <author initials="N." surname="Martin" fullname=""><organization/></author> <date year="1979" /> </front> <seriesInfo name="Proc. Institution of Electronic and Radio Engineers International Conference on Video and Data Recording" value="" /> </reference> <reference anchor="coding-thesis"> <front> <title>Source coding algorithms for fast data compression</title> <author initials="R." surname="Pasco" fullname=""><organization/></author> <date month="May" year="1976" /> </front> <seriesInfo name="Ph.D. thesis" value="Dept. of Electrical Engineering, Stanford University" /> </reference> <reference anchor="PVQ"> <front> <title>A Pyramid Vector Quantizer</title> <author initials="T." surname="Fischer" fullname=""><organization/></author> <date month="July" year="1986" /> </front> <seriesInfo name="IEEE Trans. on Information Theory, Vol. 32" value="pp. 568-583" /> </reference> </references> <section anchor="ref-implementation" title="Reference Implementation"> <t>This appendix contains the complete source code for the reference implementation of the Opus codec written in C. This implementation can be compiled for either floating-point or fixed-point architectures. </t> <t>The implementation can be compiled with either a C89 or a C99 compiler. It is reasonably optimized for most platforms such that only architecture-specific optimizations are likely to be useful. The FFT used is a slightly modified version of the KISS-FFT package, but it is easy to substitute any other FFT library. </t> <section title="Extracting the source"> <t> The complete source code can be extracted from this draft, by running the following command line: <list style="symbols"> <t><![CDATA[ cat draft-ietf-codec-opus.txt | grep '^ ###' | sed 's/ ###//' | base64 -d > opus_source.tar.gz ]]></t> <t> tar xzvf opus_source.tar.gz </t> </list> </t> </section> <section title="Base64-encoded source code"> <t> <?rfc include="opus_source.base64"?> </t> </section> </section> </back> </rfc>