Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.xiph.org/xiph/opus.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJean-Marc Valin <jmvalin@jmvalin.ca>2012-05-15 22:46:21 +0400
committerJean-Marc Valin <jmvalin@jmvalin.ca>2012-05-15 22:46:21 +0400
commit2599dc593114d5ef2d89aa3758ad134f04810d82 (patch)
tree879edb0048b412ffb5cc5a4d72e0fb7bb183cf6b
parent2b0806d47431b04677da7186ca343a7419134d2e (diff)
Gen-art part2
-rw-r--r--doc/draft-ietf-codec-opus.xml36
1 files changed, 15 insertions, 21 deletions
diff --git a/doc/draft-ietf-codec-opus.xml b/doc/draft-ietf-codec-opus.xml
index 5247d9a8..7b043c59 100644
--- a/doc/draft-ietf-codec-opus.xml
+++ b/doc/draft-ietf-codec-opus.xml
@@ -660,7 +660,7 @@ When a packet contains multiple VBR frames (i.e., code 2 or 3), the compressed
<list style="symbols">
<t>0: No frame (discontinuous transmission (DTX) or lost packet)</t>
<t>1...251: Length of the frame in bytes</t>
-<t>252...255: A second byte is needed. The total length is (len[1]*4)+len[0]</t>
+<t>252...255: A second byte is needed. The total length is (second_byte*4)+first_byte</t>
</list>
</t>
@@ -4850,6 +4850,15 @@ of the noise.
</t>
<t>
+When coding a stereo signal, three coding methods are available:
+<list style="symbols">
+<t>mid-side stereo: encodes the mean and the different of the left and right channels,</t>
+<t>intensity stereo: only encodes the mean of the left and right channels (discards the difference),</t>
+<t>dual stereo: encodes the left and right channels separately.</t>
+</list>
+</t>
+
+<t>
An overview of the decoder is given in <xref target="celt-decoder-overview"/>.
</t>
@@ -5079,8 +5088,8 @@ will be allocated no shape bits at all.</t>
<t>In stereo mode there are two additional parameters
potentially coded as part of the allocation procedure: a parameter to allow the
-selective elimination of allocation for the 'side' in jointly coded bands,
-and a flag to deactivate joint coding. These values are not signaled if
+selective elimination of allocation for the 'side' (i.e. intensity stereo) in jointly coded bands,
+and a flag to deactivate joint coding (i.e. dual stereo). These values are not signaled if
they would be meaningless in the overall context of the allocation.</t>
<t>Because every signaled adjustment increases overhead and implementation
@@ -5373,7 +5382,8 @@ If the decoded vector represents more
than one time block, then this spreading process is applied separately on each time block.
Also, if each block represents 8 samples or more, then another N-D rotation, by
(pi/2-theta), is applied <spanx style="emph">before</spanx> the rotation described above. This
-extra rotation is applied in an interleaved manner with a stride equal to round(sqrt(N/nb_blocks))
+extra rotation is applied in an interleaved manner with a stride equal to round(sqrt(N/nb_blocks)),
+i.e. it is applied independently for each set of sample S_k = {stride*n + k}, n=0..N/stride-1.
</t>
</section>
@@ -7473,7 +7483,7 @@ calls in opus_custom.h.
<t>
Implementations of the Opus codec need to take appropriate security considerations
-into account, as outlined in <xref target="DOS"/> and <xref target="SECGUIDE"/>.
+into account, as outlined in <xref target="DOS"/>.
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
@@ -7677,22 +7687,6 @@ Robust and Efficient Quantization of Speech LSP Parameters Using Structured Vect
<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="Martin79">
<front>
<title>Range encoding: An algorithm for removing redundancy from a digitised message</title>