ref: 8cb54e11ca0663206fec0f9e36c07260f83fdf95
parent: 5b6791bf754509def9e1a90ce2d660b2d4bd5e78
author: Jean-Marc Valin <[email protected]>
date: Fri Jul 29 09:19:17 EDT 2011
Addressing editorial comments by Christian Hoene
--- a/doc/draft-ietf-codec-opus.xml
+++ b/doc/draft-ietf-codec-opus.xml
@@ -366,7 +366,11 @@
<t>
One additional bit, labeled "s", is used to signal mono vs. stereo, with 0
indicating mono and 1 indicating stereo.
-The remaining two bits, labeled "c", code the number of frames per packet
+</t>
+
+<section title="Frame packing">
+<t>
+The remaining two bits of the TOC byte, labeled "c", code the number of frames per packet
(codes 0 to 3) as follows:
<list style="symbols">
<t>0: 1 frame in the packet</t>
@@ -379,12 +383,6 @@
<t>
A well-formed Opus packet MUST contain at least one byte with the TOC
information, though the frame(s) within a packet MAY be zero bytes long.
-It must also obey various additional rules indicated by "MUST", "MUST NOT",
- etc., in this section.
-A receiver MUST NOT process packets which violate these rules as normal Opus
- packets.
-They are reserved for future applications, such as in-band headers (containing
- metadata, etc.) or multichannel support.
</t>
<t>
@@ -403,7 +401,8 @@
</t>
<t>
-The maximum representable size is 255*4+255=1275 bytes.
+The maximum representable size is 255*4+255=1275 bytes. This limit MUST NOT
+be exceeded, even when no length field is used.
For 20 ms frames, this represents a bitrate of 510 kb/s, which is
approximately the highest useful rate for lossily compressed fullband stereo
music.
@@ -413,15 +412,8 @@
on the codebook sizes.
</t>
+<section title="One frame in the packet (code 0)">
<t>
-No length is transmitted for the last frame in a VBR packet, or any of the
- frames in a CBR packet, as it can be inferred from the total size of the
- packet and the size of all other data in the packet.
-However, it MUST NOT exceed 1275 bytes, to allow for repacketization by
- gateways, conference bridges, or other software.
-</t>
-
-<t>
For code 0 packets, the TOC byte is immediately followed by N-1 bytes of
compressed data for a single frame (where N is the size of the packet),
as illustrated in <xref target="code0_packet"/>.
@@ -439,7 +431,9 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
+</section>
+<section title="Two frames in the packet, each with equal compressed size (code 1)">
<t>
For code 1 packets, the TOC byte is immediately followed by the
(N-1)/2 bytes of compressed data for the first frame, followed by
@@ -465,7 +459,9 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
+</section>
+<section title="Two frames in the packet, with different compressed sizes (code 2)">
<t>
For code 2 packets, the TOC byte is followed by a one or two byte sequence
indicating the the length of the first frame (marked N1 in the figure below),
@@ -493,7 +489,9 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
+</section>
+<section title="Arbitrary number of frames in the packet (code 3)">
<t>
For code 3 packets, the TOC byte is followed by a byte encoding the number of
frames in the packet in bits 0 to 5 (marked "M" in the figure below), with bit
@@ -613,6 +611,8 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
+</section>
+</section>
<section anchor="examples" title="Examples">
<t>
@@ -674,6 +674,13 @@
</figure>
</section>
+<section title="Extending Opus">
+<t>
+A receiver MUST NOT process packets which violate the rules above as normal Opus
+ packets. They are reserved for future applications, such as in-band headers (containing
+ metadata, etc.) or multichannel support.
+</t>
+</section>
</section>