From e26ed59ad0bdac36c1b9138a2e9dee1bf2644780 Mon Sep 17 00:00:00 2001 From: Ralph Giles <giles@mozilla.com> Date: Fri, 17 Jan 2014 14:33:54 -0800 Subject: [PATCH] Use SILK/CELT everywhere describing modes. There was some attempt to use LP/MDCT instead, to avoid confusion of the Opus modes with the earlier codecs of the same name, but Jean-Marc says they gave up on doing that in the Opus RFC, and in particular the tables a reader would need to reference from RFC 6716 Section 3.2 mentions SILK and CELT, so I think it's important to use the same terms here. --- doc/draft-ietf-codec-oggopus.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index a1e5d0651..898cbecbf 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -319,17 +319,17 @@ At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality </t> <t> -Since medium-band audio is only supported in the LP mode, wideband frames SHOULD - be generated if switching from it to the MDCT mode, to ensure that any PLC - implementation that does try to migrate state between the modes will be able to - preserve all of the available audio bandwidth. +Since medium-band audio is only supported in the SILK modes, wideband frames + SHOULD be generated if switching from it to CELT modes, to ensure that + any PLC implementation that does try to migrate state between the modes + will be able to preserve all of the available audio bandwidth. </t> <t> Matching synthetic TOC byte(s) MAY be packed into packets using any of codes 0, 1, 2, or 3. If the TOC configuration matches, the muxer MAY further combine the empty -frames with previous or subsequent non-zero-length frames (using code 2 + frames with previous or subsequent non-zero-length frames (using code 2 or VBR code 3). </t> </section> @@ -337,7 +337,7 @@ frames with previous or subsequent non-zero-length frames (using code 2 <section anchor="preskip" title="Pre-skip"> <t> There is some amount of latency introduced during the decoding process, to - allow for overlap in the MDCT modes, stereo mixing in the LP modes, and + allow for overlap in the CELT modes, stereo mixing in the SILK modes, and resampling, and the encoder will introduce even more latency (though the exact amount is not specified). Therefore, the first few samples produced by the decoder do not correspond to @@ -1204,11 +1204,11 @@ Even in such a packet, most of the data will be zeros as 2.5 ms frames The largest packet consisting of entirely useful data is (15,326*N - 2) octets, or about 15 kB per stream. This corresponds to 120 ms of audio encoded as 10 ms frames in either - LP or Hybrid mode, but at a data rate of over 1 Mbps, which makes little + SILK or Hybrid mode, but at a data rate of over 1 Mbps, which makes little sense for the quality achieved. A more reasonable limit is (7,664*N - 2) octets, or about 7.5 kB per stream. -This corresponds to 120 ms of audio encoded as 20 ms stereo MDCT mode +This corresponds to 120 ms of audio encoded as 20 ms stereo CELT mode frames, with a total bitrate just under 511 kbps (not counting the Ogg encapsulation overhead). With N=8, the maximum number of channels currently defined by mapping -- GitLab