| <?xml version="1.0" encoding="utf-8"?> |
| <!-- |
| Copyright (c) 2012-2016 Xiph.Org Foundation and contributors |
| |
| Redistribution and use in source and binary forms, with or without |
| modification, are permitted provided that the following conditions |
| are met: |
| |
| - Redistributions of source code must retain the above copyright |
| notice, this list of conditions and the following disclaimer. |
| |
| - Redistributions in binary form must reproduce the above copyright |
| notice, this list of conditions and the following disclaimer in the |
| documentation and/or other materials provided with the distribution. |
| |
| THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS |
| ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT |
| LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR |
| A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER |
| OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, |
| EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, |
| PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR |
| PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF |
| LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING |
| NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS |
| SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
| |
| Special permission is granted to remove the above copyright notice, list of |
| conditions, and disclaimer when submitting this document, with or without |
| modification, to the IETF. |
| --> |
| <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ |
| <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> |
| <!ENTITY rfc3533 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3533.xml'> |
| <!ENTITY rfc3629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'> |
| <!ENTITY rfc4732 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4732.xml'> |
| <!ENTITY rfc5226 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'> |
| <!ENTITY rfc5334 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5334.xml'> |
| <!ENTITY rfc6381 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6381.xml'> |
| <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> |
| <!ENTITY rfc6982 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml'> |
| <!ENTITY rfc7587 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7587.xml'> |
| ]> |
| <?rfc toc="yes" symrefs="yes" ?> |
| |
| <rfc ipr="trust200902" category="std" docName="draft-ietf-codec-oggopus-14" |
| updates="5334"> |
| |
| <front> |
| <title abbrev="Ogg Opus">Ogg Encapsulation for the Opus Audio Codec</title> |
| <author initials="T.B." surname="Terriberry" fullname="Timothy B. Terriberry"> |
| <organization>Mozilla Corporation</organization> |
| <address> |
| <postal> |
| <street>650 Castro Street</street> |
| <city>Mountain View</city> |
| <region>CA</region> |
| <code>94041</code> |
| <country>USA</country> |
| </postal> |
| <phone>+1 650 903-0800</phone> |
| <email>tterribe@xiph.org</email> |
| </address> |
| </author> |
| |
| <author initials="R." surname="Lee" fullname="Ron Lee"> |
| <organization>Voicetronix</organization> |
| <address> |
| <postal> |
| <street>246 Pulteney Street, Level 1</street> |
| <city>Adelaide</city> |
| <region>SA</region> |
| <code>5000</code> |
| <country>Australia</country> |
| </postal> |
| <phone>+61 8 8232 9112</phone> |
| <email>ron@debian.org</email> |
| </address> |
| </author> |
| |
| <author initials="R." surname="Giles" fullname="Ralph Giles"> |
| <organization>Mozilla Corporation</organization> |
| <address> |
| <postal> |
| <street>163 West Hastings Street</street> |
| <city>Vancouver</city> |
| <region>BC</region> |
| <code>V6B 1H5</code> |
| <country>Canada</country> |
| </postal> |
| <phone>+1 778 785 1540</phone> |
| <email>giles@xiph.org</email> |
| </address> |
| </author> |
| |
| <date day="22" month="February" year="2016"/> |
| <area>RAI</area> |
| <workgroup>codec</workgroup> |
| |
| <abstract> |
| <t> |
| This document defines the Ogg encapsulation for the Opus interactive speech and |
| audio codec. |
| This allows data encoded in the Opus format to be stored in an Ogg logical |
| bitstream. |
| </t> |
| </abstract> |
| </front> |
| |
| <middle> |
| <section anchor="intro" title="Introduction"> |
| <t> |
| The IETF Opus codec is a low-latency audio codec optimized for both voice and |
| general-purpose audio. |
| See <xref target="RFC6716"/> for technical details. |
| This document defines the encapsulation of Opus in a continuous, logical Ogg |
| bitstream <xref target="RFC3533"/>. |
| Ogg encapsulation provides Opus with a long-term storage format supporting |
| all of the essential features, including metadata, fast and accurate seeking, |
| corruption detection, recapture after errors, low overhead, and the ability to |
| multiplex Opus with other codecs (including video) with minimal buffering. |
| It also provides a live streamable format, capable of delivery over a reliable |
| stream-oriented transport, without requiring all the data, or even the total |
| length of the data, up-front, in a form that is identical to the on-disk |
| storage format. |
| </t> |
| <t> |
| Ogg bitstreams are made up of a series of 'pages', each of which contains data |
| from one or more 'packets'. |
| Pages are the fundamental unit of multiplexing in an Ogg stream. |
| Each page is associated with a particular logical stream and contains a capture |
| pattern and checksum, flags to mark the beginning and end of the logical |
| stream, and a 'granule position' that represents an absolute position in the |
| stream, to aid seeking. |
| A single page can contain up to 65,025 octets of packet data from up to 255 |
| different packets. |
| Packets can be split arbitrarily across pages, and continued from one page to |
| the next (allowing packets much larger than would fit on a single page). |
| Each page contains 'lacing values' that indicate how the data is partitioned |
| into packets, allowing a demultiplexer (demuxer) to recover the packet |
| boundaries without examining the encoded data. |
| A packet is said to 'complete' on a page when the page contains the final |
| lacing value corresponding to that packet. |
| </t> |
| <t> |
| This encapsulation defines the contents of the packet data, including |
| the necessary headers, the organization of those packets into a logical |
| stream, and the interpretation of the codec-specific granule position field. |
| It does not attempt to describe or specify the existing Ogg container format. |
| Readers unfamiliar with the basic concepts mentioned above are encouraged to |
| review the details in <xref target="RFC3533"/>. |
| </t> |
| |
| </section> |
| |
| <section anchor="terminology" title="Terminology"> |
| <t> |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", |
| "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in <xref target="RFC2119"/>. |
| </t> |
| |
| </section> |
| |
| <section anchor="packet_organization" title="Packet Organization"> |
| <t> |
| An Ogg Opus stream is organized as follows (see |
| <xref target="packet-org-example"/> for an example). |
| </t> |
| |
| <figure anchor="packet-org-example" |
| title="Example packet organization for a logical Ogg Opus stream" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| Page 0 Pages 1 ... n Pages (n+1) ... |
| +------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +-- |
| | | | | | | | | | | | | | |
| |+----------+| |+-----------------+| |+-------------------+ +----- |
| |||ID Header|| || Comment Header || ||Audio Data Packet 1| | ... |
| |+----------+| |+-----------------+| |+-------------------+ +----- |
| | | | | | | | | | | | | | |
| +------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +-- |
| ^ ^ ^ |
| | | | |
| | | Mandatory Page Break |
| | | |
| | ID header is contained on a single page |
| | |
| 'Beginning Of Stream' |
| ]]></artwork> |
| </figure> |
| |
| <t> |
| There are two mandatory header packets. |
| The first packet in the logical Ogg bitstream MUST contain the identification |
| (ID) header, which uniquely identifies a stream as Opus audio. |
| The format of this header is defined in <xref target="id_header"/>. |
| It is placed alone (without any other packet data) on the first page of |
| the logical Ogg bitstream, and completes on that page. |
| This page has its 'beginning of stream' flag set. |
| </t> |
| <t> |
| The second packet in the logical Ogg bitstream MUST contain the comment header, |
| which contains user-supplied metadata. |
| The format of this header is defined in <xref target="comment_header"/>. |
| It MAY span multiple pages, beginning on the second page of the logical |
| stream. |
| However many pages it spans, the comment header packet MUST finish the page on |
| which it completes. |
| </t> |
| <t> |
| All subsequent pages are audio data pages, and the Ogg packets they contain are |
| audio data packets. |
| Each audio data packet contains one Opus packet for each of N different |
| streams, where N is typically one for mono or stereo, but MAY be greater than |
| one for multichannel audio. |
| The value N is specified in the ID header (see |
| <xref target="channel_mapping"/>), and is fixed over the entire length of the |
| logical Ogg bitstream. |
| </t> |
| <t> |
| The first (N - 1) Opus packets, if any, are packed one after another |
| into the Ogg packet, using the self-delimiting framing from Appendix B of |
| <xref target="RFC6716"/>. |
| The remaining Opus packet is packed at the end of the Ogg packet using the |
| regular, undelimited framing from Section 3 of <xref target="RFC6716"/>. |
| All of the Opus packets in a single Ogg packet MUST be constrained to have the |
| same duration. |
| An implementation of this specification SHOULD treat any Opus packet whose |
| duration is different from that of the first Opus packet in an Ogg packet as |
| if it were a malformed Opus packet with an invalid Table Of Contents (TOC) |
| sequence. |
| </t> |
| <t> |
| The TOC sequence at the beginning of each Opus packet indicates the coding |
| mode, audio bandwidth, channel count, duration (frame size), and number of |
| frames per packet, as described in Section 3.1 |
| of <xref target="RFC6716"/>. |
| The coding mode is one of SILK, Hybrid, or Constrained Energy Lapped Transform |
| (CELT). |
| The combination of coding mode, audio bandwidth, and frame size is referred to |
| as the configuration of an Opus packet. |
| </t> |
| <t> |
| Packets are placed into Ogg pages in order until the end of stream. |
| Audio data packets might span page boundaries. |
| The first audio data page could have the 'continued packet' flag set |
| (indicating the first audio data packet is continued from a previous page) if, |
| for example, it was a live stream joined mid-broadcast, with the headers |
| pasted on the front. |
| If a page has the 'continued packet' flag set and one of the following |
| conditions is also true: |
| <list style="symbols"> |
| <t>the previous page with packet data does not end in a continued packet (does |
| not end with a lacing value of 255) OR</t> |
| <t>the page sequence numbers are not consecutive,</t> |
| </list> |
| then a demuxer MUST NOT attempt to decode the data for the first packet on the |
| page unless the demuxer has some special knowledge that would allow it to |
| interpret this data despite the missing pieces. |
| An implementation MUST treat a zero-octet audio data packet as if it were a |
| malformed Opus packet as described in |
| Section 3.4 of <xref target="RFC6716"/>. |
| </t> |
| <t> |
| A logical stream ends with a page with the 'end of stream' flag set, but |
| implementations need to be prepared to deal with truncated streams that do not |
| have a page marked 'end of stream'. |
| There is no reason for the final packet on the last page to be a continued |
| packet, i.e., for the final lacing value to be 255. |
| However, demuxers might encounter such streams, possibly as the result of a |
| transfer that did not complete or of corruption. |
| If a packet continues onto a subsequent page (i.e., when the page ends with a |
| lacing value of 255) and one of the following conditions is also true: |
| <list style="symbols"> |
| <t>the next page with packet data does not have the 'continued packet' flag |
| set OR</t> |
| <t>there is no next page with packet data OR</t> |
| <t>the page sequence numbers are not consecutive,</t> |
| </list> |
| then a demuxer MUST NOT attempt to decode the data from that packet unless the |
| demuxer has some special knowledge that would allow it to interpret this data |
| despite the missing pieces. |
| There MUST NOT be any more pages in an Opus logical bitstream after a page |
| marked 'end of stream'. |
| </t> |
| </section> |
| |
| <section anchor="granpos" title="Granule Position"> |
| <t> |
| The granule position MUST be zero for the ID header page and the |
| page where the comment header completes. |
| That is, the first page in the logical stream, and the last header |
| page before the first audio data page both have a granule position of zero. |
| </t> |
| <t> |
| The granule position of an audio data page encodes the total number of PCM |
| samples in the stream up to and including the last fully-decodable sample from |
| the last packet completed on that page. |
| The granule position of the first audio data page will usually be larger than |
| zero, as described in <xref target="start_granpos_restrictions"/>. |
| </t> |
| |
| <t> |
| A page that is entirely spanned by a single packet (that completes on a |
| subsequent page) has no granule position, and the granule position field is |
| set to the special value '-1' in two's complement. |
| </t> |
| |
| <t> |
| The granule position of an audio data page is in units of PCM audio samples at |
| a fixed rate of 48 kHz (per channel; a stereo stream's granule position |
| does not increment at twice the speed of a mono stream). |
| It is possible to run an Opus decoder at other sampling rates, |
| but all Opus packets encode samples at a sampling rate that evenly divides |
| 48 kHz. |
| Therefore, the value in the granule position field always counts samples |
| assuming a 48 kHz decoding rate, and the rest of this specification makes |
| the same assumption. |
| </t> |
| |
| <t> |
| The duration of an Opus packet as defined in <xref target="RFC6716"/> can be |
| any multiple of 2.5 ms, up to a maximum of 120 ms. |
| This duration is encoded in the TOC sequence at the beginning of each packet. |
| The number of samples returned by a decoder corresponds to this duration |
| exactly, even for the first few packets. |
| For example, a 20 ms packet fed to a decoder running at 48 kHz will |
| always return 960 samples. |
| A demuxer can parse the TOC sequence at the beginning of each Ogg packet to |
| work backwards or forwards from a packet with a known granule position (i.e., |
| the last packet completed on some page) in order to assign granule positions |
| to every packet, or even every individual sample. |
| The one exception is the last page in the stream, as described below. |
| </t> |
| |
| <t> |
| All other pages with completed packets after the first MUST have a granule |
| position equal to the number of samples contained in packets that complete on |
| that page plus the granule position of the most recent page with completed |
| packets. |
| This guarantees that a demuxer can assign individual packets the same granule |
| position when working forwards as when working backwards. |
| For this to work, there cannot be any gaps. |
| </t> |
| |
| <section anchor="gap-repair" title="Repairing Gaps in Real-time Streams"> |
| <t> |
| In order to support capturing a real-time stream that has lost or not |
| transmitted packets, a multiplexer (muxer) SHOULD emit packets that explicitly |
| request the use of Packet Loss Concealment (PLC) in place of the missing |
| packets. |
| Implementations that fail to do so still MUST NOT increment the granule |
| position for a page by anything other than the number of samples contained in |
| packets that actually complete on that page. |
| </t> |
| <t> |
| Only gaps that are a multiple of 2.5 ms are repairable, as these are the |
| only durations that can be created by packet loss or discontinuous |
| transmission. |
| Muxers need not handle other gap sizes. |
| Creating the necessary packets involves synthesizing a TOC byte (defined in |
| Section 3.1 of <xref target="RFC6716"/>)—and whatever |
| additional internal framing is needed—to indicate the packet duration |
| for each stream. |
| The actual length of each missing Opus frame inside the packet is zero bytes, |
| as defined in Section 3.2.1 of <xref target="RFC6716"/>. |
| </t> |
| |
| <t> |
| Zero-byte frames MAY be packed into packets using any of codes 0, 1, |
| 2, or 3. |
| When successive frames have the same configuration, the higher code packings |
| reduce overhead. |
| Likewise, if the TOC configuration matches, the muxer MAY further combine the |
| empty frames with previous or subsequent non-zero-length frames (using |
| code 2 or VBR code 3). |
| </t> |
| |
| <t> |
| <xref target="RFC6716"/> does not impose any requirements on the PLC, but this |
| section outlines choices that are expected to have a positive influence on |
| most PLC implementations, including the reference implementation. |
| Synthesized TOC sequences SHOULD maintain the same mode, audio bandwidth, |
| channel count, and frame size as the previous packet (if any). |
| This is the simplest and usually the most well-tested case for the PLC to |
| handle and it covers all losses that do not include a configuration switch, |
| as defined in Section 4.5 of <xref target="RFC6716"/>. |
| </t> |
| |
| <t> |
| When a previous packet is available, keeping the audio bandwidth and channel |
| count the same allows the PLC to provide maximum continuity in the concealment |
| data it generates. |
| However, if the size of the gap is not a multiple of the most recent frame |
| size, then the frame size will have to change for at least some frames. |
| Such changes SHOULD be delayed as long as possible to simplify |
| things for PLC implementations. |
| </t> |
| |
| <t> |
| As an example, a 95 ms gap could be encoded as nineteen 5 ms frames |
| in two bytes with a single CBR code 3 packet. |
| If the previous frame size was 20 ms, using four 20 ms frames |
| followed by three 5 ms frames requires 4 bytes (plus an extra byte |
| of Ogg lacing overhead), but allows the PLC to use its well-tested steady |
| state behavior for as long as possible. |
| The total bitrate of the latter approach, including Ogg overhead, is about |
| 0.4 kbps, so the impact on file size is minimal. |
| </t> |
| |
| <t> |
| Changing modes is discouraged, since this causes some decoder implementations |
| to reset their PLC state. |
| However, SILK and Hybrid mode frames cannot fill gaps that are not a multiple |
| of 10 ms. |
| If switching to CELT mode is needed to match the gap size, a muxer SHOULD do |
| so at the end of the gap to allow the PLC to function for as long as possible. |
| </t> |
| |
| <t> |
| In the example above, if the previous frame was a 20 ms SILK mode frame, |
| the better solution is to synthesize a packet describing four 20 ms SILK |
| frames, followed by a packet with a single 10 ms SILK |
| frame, and finally a packet with a 5 ms CELT frame, to fill the 95 ms |
| gap. |
| This also requires four bytes to describe the synthesized packet data (two |
| bytes for a CBR code 3 and one byte each for two code 0 packets) but three |
| bytes of Ogg lacing overhead are needed to mark the packet boundaries. |
| At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality |
| solution. |
| </t> |
| |
| <t> |
| Since medium-band audio is an option only in the SILK mode, wideband frames |
| SHOULD be generated if switching from that configuration to CELT mode, to |
| ensure that any PLC implementation which does try to migrate state between |
| the modes will be able to preserve all of the available audio bandwidth. |
| </t> |
| |
| </section> |
| |
| <section anchor="preskip" title="Pre-skip"> |
| <t> |
| There is some amount of latency introduced during the decoding process, to |
| allow for overlap in the CELT mode, stereo mixing in the SILK mode, and |
| resampling. |
| The encoder might have introduced additional latency through its own resampling |
| and analysis (though the exact amount is not specified). |
| Therefore, the first few samples produced by the decoder do not correspond to |
| real input audio, but are instead composed of padding inserted by the encoder |
| to compensate for this latency. |
| These samples need to be stored and decoded, as Opus is an asymptotically |
| convergent predictive codec, meaning the decoded contents of each frame depend |
| on the recent history of decoder inputs. |
| However, a player will want to skip these samples after decoding them. |
| </t> |
| |
| <t> |
| A 'pre-skip' field in the ID header (see <xref target="id_header"/>) signals |
| the number of samples that SHOULD be skipped (decoded but discarded) at the |
| beginning of the stream, though some specific applications might have a reason |
| for looking at that data. |
| This amount need not be a multiple of 2.5 ms, MAY be smaller than a single |
| packet, or MAY span the contents of several packets. |
| These samples are not valid audio. |
| </t> |
| |
| <t> |
| For example, if the first Opus frame uses the CELT mode, it will always |
| produce 120 samples of windowed overlap-add data. |
| However, the overlap data is initially all zeros (since there is no prior |
| frame), meaning this cannot, in general, accurately represent the original |
| audio. |
| The SILK mode requires additional delay to account for its analysis and |
| resampling latency. |
| The encoder delays the original audio to avoid this problem. |
| </t> |
| |
| <t> |
| The pre-skip field MAY also be used to perform sample-accurate cropping of |
| already encoded streams. |
| In this case, a value of at least 3840 samples (80 ms) provides |
| sufficient history to the decoder that it will have converged |
| before the stream's output begins. |
| </t> |
| |
| </section> |
| |
| <section anchor="pcm_sample_position" title="PCM Sample Position"> |
| <t> |
| The PCM sample position is determined from the granule position using the |
| formula |
| </t> |
| <figure align="center"> |
| <artwork align="center"><![CDATA[ |
| 'PCM sample position' = 'granule position' - 'pre-skip' . |
| ]]></artwork> |
| </figure> |
| |
| <t> |
| For example, if the granule position of the first audio data page is 59,971, |
| and the pre-skip is 11,971, then the PCM sample position of the last decoded |
| sample from that page is 48,000. |
| </t> |
| <t> |
| This can be converted into a playback time using the formula |
| </t> |
| <figure align="center"> |
| <artwork align="center"><![CDATA[ |
| 'PCM sample position' |
| 'playback time' = --------------------- . |
| 48000.0 |
| ]]></artwork> |
| </figure> |
| |
| <t> |
| The initial PCM sample position before any samples are played is normally '0'. |
| In this case, the PCM sample position of the first audio sample to be played |
| starts at '1', because it marks the time on the clock |
| <spanx style="emph">after</spanx> that sample has been played, and a stream |
| that is exactly one second long has a final PCM sample position of '48000', |
| as in the example here. |
| </t> |
| |
| <t> |
| Vorbis streams use a granule position smaller than the number of audio samples |
| contained in the first audio data page to indicate that some of those samples |
| are trimmed from the output (see <xref target="vorbis-trim"/>). |
| However, to do so, Vorbis requires that the first audio data page contains |
| exactly two packets, in order to allow the decoder to perform PCM position |
| adjustments before needing to return any PCM data. |
| Opus uses the pre-skip mechanism for this purpose instead, since the encoder |
| might introduce more than a single packet's worth of latency, and since very |
| large packets in streams with a very large number of channels might not fit |
| on a single page. |
| </t> |
| </section> |
| |
| <section anchor="end_trimming" title="End Trimming"> |
| <t> |
| The page with the 'end of stream' flag set MAY have a granule position that |
| indicates the page contains less audio data than would normally be returned by |
| decoding up through the final packet. |
| This is used to end the stream somewhere other than an even frame boundary. |
| The granule position of the most recent audio data page with completed packets |
| is used to make this determination, or '0' is used if there were no previous |
| audio data pages with a completed packet. |
| The difference between these granule positions indicates how many samples to |
| keep after decoding the packets that completed on the final page. |
| The remaining samples are discarded. |
| The number of discarded samples SHOULD be no larger than the number decoded |
| from the last packet. |
| </t> |
| </section> |
| |
| <section anchor="start_granpos_restrictions" |
| title="Restrictions on the Initial Granule Position"> |
| <t> |
| The granule position of the first audio data page with a completed packet MAY |
| be larger than the number of samples contained in packets that complete on |
| that page, however it MUST NOT be smaller, unless that page has the 'end of |
| stream' flag set. |
| Allowing a granule position larger than the number of samples allows the |
| beginning of a stream to be cropped or a live stream to be joined without |
| rewriting the granule position of all the remaining pages. |
| This means that the PCM sample position just before the first sample to be |
| played MAY be larger than '0'. |
| Synchronization when multiplexing with other logical streams still uses the PCM |
| sample position relative to '0' to compute sample times. |
| This does not affect the behavior of pre-skip: exactly 'pre-skip' samples |
| SHOULD be skipped from the beginning of the decoded output, even if the |
| initial PCM sample position is greater than zero. |
| </t> |
| |
| <t> |
| On the other hand, a granule position that is smaller than the number of |
| decoded samples prevents a demuxer from working backwards to assign each |
| packet or each individual sample a valid granule position, since granule |
| positions are non-negative. |
| An implementation MUST treat any stream as invalid if the granule position |
| is smaller than the number of samples contained in packets that complete on |
| the first audio data page with a completed packet, unless that page has the |
| 'end of stream' flag set. |
| It MAY defer this action until it decodes the last packet completed on that |
| page. |
| </t> |
| |
| <t> |
| If that page has the 'end of stream' flag set, a demuxer MUST treat any stream |
| as invalid if its granule position is smaller than the 'pre-skip' amount. |
| This would indicate that there are more samples to be skipped from the initial |
| decoded output than exist in the stream. |
| If the granule position is smaller than the number of decoded samples produced |
| by the packets that complete on that page, then a demuxer MUST use an initial |
| granule position of '0', and can work forwards from '0' to timestamp |
| individual packets. |
| If the granule position is larger than the number of decoded samples available, |
| then the demuxer MUST still work backwards as described above, even if the |
| 'end of stream' flag is set, to determine the initial granule position, and |
| thus the initial PCM sample position. |
| Both of these will be greater than '0' in this case. |
| </t> |
| </section> |
| |
| <section anchor="seeking_and_preroll" title="Seeking and Pre-roll"> |
| <t> |
| Seeking in Ogg files is best performed using a bisection search for a page |
| whose granule position corresponds to a PCM position at or before the seek |
| target. |
| With appropriately weighted bisection, accurate seeking can be performed in |
| just one or two bisections on average, even in multi-gigabyte files. |
| See <xref target="seeking"/> for an example of general implementation guidance. |
| </t> |
| |
| <t> |
| When seeking within an Ogg Opus stream, an implementation SHOULD start decoding |
| (and discarding the output) at least 3840 samples (80 ms) prior to |
| the seek target in order to ensure that the output audio is correct by the |
| time it reaches the seek target. |
| This 'pre-roll' is separate from, and unrelated to, the 'pre-skip' used at the |
| beginning of the stream. |
| If the point 80 ms prior to the seek target comes before the initial PCM |
| sample position, an implementation SHOULD start decoding from the beginning of |
| the stream, applying pre-skip as normal, regardless of whether the pre-skip is |
| larger or smaller than 80 ms, and then continue to discard samples |
| to reach the seek target (if any). |
| </t> |
| </section> |
| |
| </section> |
| |
| <section anchor="headers" title="Header Packets"> |
| <t> |
| An Ogg Opus logical stream contains exactly two mandatory header packets: |
| an identification header and a comment header. |
| </t> |
| |
| <section anchor="id_header" title="Identification Header"> |
| |
| <figure anchor="id_header_packet" title="ID Header Packet" align="center"> |
| <artwork align="center"><![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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 'O' | 'p' | 'u' | 's' | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 'H' | 'e' | 'a' | 'd' | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Version = 1 | Channel Count | Pre-skip | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Input Sample Rate (Hz) | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Output Gain (Q7.8 in dB) | Mapping Family| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : |
| | | |
| : Optional Channel Mapping Table... : |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ]]></artwork> |
| </figure> |
| |
| <t> |
| The fields in the identification (ID) header have the following meaning: |
| <list style="numbers"> |
| <t>Magic Signature: |
| <vspace blankLines="1"/> |
| This is an 8-octet (64-bit) field that allows codec identification and is |
| human-readable. |
| It contains, in order, the magic numbers: |
| <list style="empty"> |
| <t>0x4F 'O'</t> |
| <t>0x70 'p'</t> |
| <t>0x75 'u'</t> |
| <t>0x73 's'</t> |
| <t>0x48 'H'</t> |
| <t>0x65 'e'</t> |
| <t>0x61 'a'</t> |
| <t>0x64 'd'</t> |
| </list> |
| Starting with "Op" helps distinguish it from audio data packets, as this is an |
| invalid TOC sequence. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Version (8 bits, unsigned): |
| <vspace blankLines="1"/> |
| The version number MUST always be '1' for this version of the encapsulation |
| specification. |
| Implementations SHOULD treat streams where the upper four bits of the version |
| number match that of a recognized specification as backwards-compatible with |
| that specification. |
| That is, the version number can be split into "major" and "minor" version |
| sub-fields, with changes to the "minor" sub-field (in the lower four bits) |
| signaling compatible changes. |
| For example, an implementation of this specification SHOULD accept any stream |
| with a version number of '15' or less, and SHOULD assume any stream with a |
| version number '16' or greater is incompatible. |
| The initial version '1' was chosen to keep implementations from relying on this |
| octet as a null terminator for the "OpusHead" string. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Output Channel Count 'C' (8 bits, unsigned): |
| <vspace blankLines="1"/> |
| This is the number of output channels. |
| This might be different than the number of encoded channels, which can change |
| on a packet-by-packet basis. |
| This value MUST NOT be zero. |
| The maximum allowable value depends on the channel mapping family, and might be |
| as large as 255. |
| See <xref target="channel_mapping"/> for details. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Pre-skip (16 bits, unsigned, little |
| endian): |
| <vspace blankLines="1"/> |
| This is the number of samples (at 48 kHz) to discard from the decoder |
| output when starting playback, and also the number to subtract from a page's |
| granule position to calculate its PCM sample position. |
| When cropping the beginning of existing Ogg Opus streams, a pre-skip of at |
| least 3,840 samples (80 ms) is RECOMMENDED to ensure complete |
| convergence in the decoder. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Input Sample Rate (32 bits, unsigned, little |
| endian): |
| <vspace blankLines="1"/> |
| This is the sample rate of the original input (before encoding), in Hz. |
| This field is <spanx style="emph">not</spanx> the sample rate to use for |
| playback of the encoded data. |
| <vspace blankLines="1"/> |
| Opus can switch between internal audio bandwidths of 4, 6, 8, 12, and |
| 20 kHz. |
| Each packet in the stream can have a different audio bandwidth. |
| Regardless of the audio bandwidth, the reference decoder supports decoding any |
| stream at a sample rate of 8, 12, 16, 24, or 48 kHz. |
| The original sample rate of the audio passed to the encoder is not preserved |
| by the lossy compression. |
| <vspace blankLines="1"/> |
| An Ogg Opus player SHOULD select the playback sample rate according to the |
| following procedure: |
| <list style="numbers"> |
| <t>If the hardware supports 48 kHz playback, decode at 48 kHz.</t> |
| <t>Otherwise, if the hardware's highest available sample rate is a supported |
| rate, decode at this sample rate.</t> |
| <t>Otherwise, if the hardware's highest available sample rate is less than |
| 48 kHz, decode at the next higher Opus supported rate above the highest |
| available hardware rate and resample.</t> |
| <t>Otherwise, decode at 48 kHz and resample.</t> |
| </list> |
| However, the 'Input Sample Rate' field allows the muxer to pass the sample |
| rate of the original input stream as metadata. |
| This is useful when the user requires the output sample rate to match the |
| input sample rate. |
| For example, when not playing the output, an implementation writing PCM format |
| samples to disk might choose to resample the audio back to the original input |
| sample rate to reduce surprise to the user, who might reasonably expect to get |
| back a file with the same sample rate. |
| <vspace blankLines="1"/> |
| A value of zero indicates 'unspecified'. |
| Muxers SHOULD write the actual input sample rate or zero, but implementations |
| which do something with this field SHOULD take care to behave sanely if given |
| crazy values (e.g., do not actually upsample the output to 10 MHz if |
| requested). |
| Implementations SHOULD support input sample rates between 8 kHz and |
| 192 kHz (inclusive). |
| Rates outside this range MAY be ignored by falling back to the default rate of |
| 48 kHz instead. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Output Gain (16 bits, signed, little endian): |
| <vspace blankLines="1"/> |
| This is a gain to be applied when decoding. |
| It is 20*log10 of the factor by which to scale the decoder output to achieve |
| the desired playback volume, stored in a 16-bit, signed, two's complement |
| fixed-point value with 8 fractional bits (i.e., |
| Q7.8 <xref target="q-notation"/>). |
| <vspace blankLines="1"/> |
| To apply the gain, an implementation could use |
| <figure align="center"> |
| <artwork align="center"><![CDATA[ |
| sample *= pow(10, output_gain/(20.0*256)) , |
| ]]></artwork> |
| </figure> |
| where output_gain is the raw 16-bit value from the header. |
| <vspace blankLines="1"/> |
| Players and media frameworks SHOULD apply it by default. |
| If a player chooses to apply any volume adjustment or gain modification, such |
| as the R128_TRACK_GAIN (see <xref target="comment_header"/>), the adjustment |
| MUST be applied in addition to this output gain in order to achieve playback |
| at the normalized volume. |
| <vspace blankLines="1"/> |
| A muxer SHOULD set this field to zero, and instead apply any gain prior to |
| encoding, when this is possible and does not conflict with the user's wishes. |
| A nonzero output gain indicates the gain was adjusted after encoding, or that |
| a user wished to adjust the gain for playback while preserving the ability |
| to recover the original signal amplitude. |
| <vspace blankLines="1"/> |
| Although the output gain has enormous range (+/- 128 dB, enough to amplify |
| inaudible sounds to the threshold of physical pain), most applications can |
| only reasonably use a small portion of this range around zero. |
| The large range serves in part to ensure that gain can always be losslessly |
| transferred between OpusHead and R128 gain tags (see below) without |
| saturating. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Channel Mapping Family (8 bits, unsigned): |
| <vspace blankLines="1"/> |
| This octet indicates the order and semantic meaning of the output channels. |
| <vspace blankLines="1"/> |
| Each currently specified value of this octet indicates a mapping family, which |
| defines a set of allowed channel counts, and the ordered set of channel names |
| for each allowed channel count. |
| The details are described in <xref target="channel_mapping"/>. |
| </t> |
| <t>Channel Mapping Table: |
| This table defines the mapping from encoded streams to output channels. |
| Its contents are specified in <xref target="channel_mapping"/>. |
| </t> |
| </list> |
| </t> |
| |
| <t> |
| All fields in the ID headers are REQUIRED, except for the channel mapping |
| table, which MUST be omitted when the channel mapping family is 0, but |
| is REQUIRED otherwise. |
| Implementations SHOULD treat a stream as invalid if it contains an ID header |
| that does not have enough data for these fields, even if it contain a valid |
| Magic Signature. |
| Future versions of this specification, even backwards-compatible versions, |
| might include additional fields in the ID header. |
| If an ID header has a compatible major version, but a larger minor version, |
| an implementation MUST NOT treat it as invalid for containing additional data |
| not specified here, provided it still completes on the first page. |
| </t> |
| |
| <section anchor="channel_mapping" title="Channel Mapping"> |
| <t> |
| An Ogg Opus stream allows mapping one number of Opus streams (N) to a possibly |
| larger number of decoded channels (M + N) to yet another number of |
| output channels (C), which might be larger or smaller than the number of |
| decoded channels. |
| The order and meaning of these channels are defined by a channel mapping, |
| which consists of the 'channel mapping family' octet and, for channel mapping |
| families other than family 0, a channel mapping table, as illustrated in |
| <xref target="channel_mapping_table"/>. |
| </t> |
| |
| <figure anchor="channel_mapping_table" title="Channel Mapping Table" |
| align="center"> |
| <artwork align="center"><![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 |
| +-+-+-+-+-+-+-+-+ |
| | Stream Count | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Coupled Count | Channel Mapping... : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ]]></artwork> |
| </figure> |
| |
| <t> |
| The fields in the channel mapping table have the following meaning: |
| <list style="numbers" counter="8"> |
| <t>Stream Count 'N' (8 bits, unsigned): |
| <vspace blankLines="1"/> |
| This is the total number of streams encoded in each Ogg packet. |
| This value is necessary to correctly parse the packed Opus packets inside an |
| Ogg packet, as described in <xref target="packet_organization"/>. |
| This value MUST NOT be zero, as without at least one Opus packet with a valid |
| TOC sequence, a demuxer cannot recover the duration of an Ogg packet. |
| <vspace blankLines="1"/> |
| For channel mapping family 0, this value defaults to 1, and is not coded. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Coupled Stream Count 'M' (8 bits, unsigned): |
| This is the number of streams whose decoders are to be configured to produce |
| two channels (stereo). |
| This MUST be no larger than the total number of streams, N. |
| <vspace blankLines="1"/> |
| Each packet in an Opus stream has an internal channel count of 1 or 2, which |
| can change from packet to packet. |
| This is selected by the encoder depending on the bitrate and the audio being |
| encoded. |
| The original channel count of the audio passed to the encoder is not |
| necessarily preserved by the lossy compression. |
| <vspace blankLines="1"/> |
| Regardless of the internal channel count, any Opus stream can be decoded as |
| mono (a single channel) or stereo (two channels) by appropriate initialization |
| of the decoder. |
| The 'coupled stream count' field indicates that the decoders for the first M |
| Opus streams are to be initialized for stereo (two-channel) output, and the |
| remaining (N - M) decoders are to be initialized for mono (a single |
| channel) only. |
| The total number of decoded channels, (M + N), MUST be no larger than |
| 255, as there is no way to index more channels than that in the channel |
| mapping. |
| <vspace blankLines="1"/> |
| For channel mapping family 0, this value defaults to (C - 1) |
| (i.e., 0 for mono and 1 for stereo), and is not coded. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Channel Mapping (8*C bits): |
| This contains one octet per output channel, indicating which decoded channel |
| is to be used for each one. |
| Let 'index' be the value of this octet for a particular output channel. |
| This value MUST either be smaller than (M + N), or be the special |
| value 255. |
| If 'index' is less than 2*M, the output MUST be taken from decoding stream |
| ('index'/2) as stereo and selecting the left channel if 'index' is even, and |
| the right channel if 'index' is odd. |
| If 'index' is 2*M or larger, but less than 255, the output MUST be taken from |
| decoding stream ('index' - M) as mono. |
| If 'index' is 255, the corresponding output channel MUST contain pure silence. |
| <vspace blankLines="1"/> |
| The number of output channels, C, is not constrained to match the number of |
| decoded channels (M + N). |
| A single index value MAY appear multiple times, i.e., the same decoded channel |
| might be mapped to multiple output channels. |
| Some decoded channels might not be assigned to any output channel, as well. |
| <vspace blankLines="1"/> |
| For channel mapping family 0, the first index defaults to 0, and if |
| C == 2, the second index defaults to 1. |
| Neither index is coded. |
| </t> |
| </list> |
| </t> |
| |
| <t> |
| After producing the output channels, the channel mapping family determines the |
| semantic meaning of each one. |
| There are three defined mapping families in this specification. |
| </t> |
| |
| <section anchor="channel_mapping_0" title="Channel Mapping Family 0"> |
| <t> |
| Allowed numbers of channels: 1 or 2. |
| RTP mapping. |
| This is the same channel interpretation as <xref target="RFC7587"/>. |
| </t> |
| <t> |
| <list style="symbols"> |
| <t>1 channel: monophonic (mono).</t> |
| <t>2 channels: stereo (left, right).</t> |
| </list> |
| Special mapping: This channel mapping value also |
| indicates that the contents consists of a single Opus stream that is stereo if |
| and only if C == 2, with stream index 0 mapped to output |
| channel 0 (mono, or left channel) and stream index 1 mapped to |
| output channel 1 (right channel) if stereo. |
| When the 'channel mapping family' octet has this value, the channel mapping |
| table MUST be omitted from the ID header packet. |
| </t> |
| </section> |
| |
| <section anchor="channel_mapping_1" title="Channel Mapping Family 1"> |
| <t> |
| Allowed numbers of channels: 1...8. |
| Vorbis channel order (see below). |
| </t> |
| <t> |
| Each channel is assigned to a speaker location in a conventional surround |
| arrangement. |
| Specific locations depend on the number of channels, and are given below |
| in order of the corresponding channel indices. |
| <list style="symbols"> |
| <t>1 channel: monophonic (mono).</t> |
| <t>2 channels: stereo (left, right).</t> |
| <t>3 channels: linear surround (left, center, right)</t> |
| <t>4 channels: quadraphonic (front left, front right, rear left, rear right).</t> |
| <t>5 channels: 5.0 surround (front left, front center, front right, rear left, rear right).</t> |
| <t>6 channels: 5.1 surround (front left, front center, front right, rear left, rear right, LFE).</t> |
| <t>7 channels: 6.1 surround (front left, front center, front right, side left, side right, rear center, LFE).</t> |
| <t>8 channels: 7.1 surround (front left, front center, front right, side left, side right, rear left, rear right, LFE)</t> |
| </list> |
| </t> |
| <t> |
| This set of surround options and speaker location orderings is the same |
| as those used by the Vorbis codec <xref target="vorbis-mapping"/>. |
| The ordering is different from the one used by the |
| WAVE <xref target="wave-multichannel"/> and |
| Free Lossless Audio Codec (FLAC) <xref target="flac"/> formats, |
| so correct ordering requires permutation of the output channels when decoding |
| to or encoding from those formats. |
| 'LFE' here refers to a Low Frequency Effects channel, often mapped to a |
| subwoofer with no particular spatial position. |
| Implementations SHOULD identify 'side' or 'rear' speaker locations with |
| 'surround' and 'back' as appropriate when interfacing with audio formats |
| or systems which prefer that terminology. |
| </t> |
| </section> |
| |
| <section anchor="channel_mapping_255" |
| title="Channel Mapping Family 255"> |
| <t> |
| Allowed numbers of channels: 1...255. |
| No defined channel meaning. |
| </t> |
| <t> |
| Channels are unidentified. |
| General-purpose players SHOULD NOT attempt to play these streams. |
| Offline implementations MAY deinterleave the output into separate PCM files, |
| one per channel. |
| Implementations SHOULD NOT produce output for channels mapped to stream index |
| 255 (pure silence) unless they have no other way to indicate the index of |
| non-silent channels. |
| </t> |
| </section> |
| |
| <section anchor="channel_mapping_undefined" |
| title="Undefined Channel Mappings"> |
| <t> |
| The remaining channel mapping families (2...254) are reserved. |
| A demuxer implementation encountering a reserved channel mapping family value |
| SHOULD act as though the value is 255. |
| </t> |
| </section> |
| |
| <section anchor="downmix" title="Downmixing"> |
| <t> |
| An Ogg Opus player MUST support any valid channel mapping with a channel |
| mapping family of 0 or 1, even if the number of channels does not match the |
| physically connected audio hardware. |
| Players SHOULD perform channel mixing to increase or reduce the number of |
| channels as needed. |
| </t> |
| |
| <t> |
| Implementations MAY use the matrices in |
| Figures <xref target="downmix-matrix-3" format="counter"/> |
| through <xref target="downmix-matrix-8" format="counter"/> to implement |
| downmixing from multichannel files using |
| <xref target="channel_mapping_1">Channel Mapping Family 1</xref>, which are |
| known to give acceptable results for stereo. |
| Matrices for 3 and 4 channels are normalized so each coefficient row sums |
| to 1 to avoid clipping. |
| For 5 or more channels they are normalized to 2 as a compromise between |
| clipping and dynamic range reduction. |
| </t> |
| <t> |
| In these matrices the front left and front right channels are generally |
| passed through directly. |
| When a surround channel is split between both the left and right stereo |
| channels, coefficients are chosen so their squares sum to 1, which |
| helps preserve the perceived intensity. |
| Rear channels are mixed more diffusely or attenuated to maintain focus |
| on the front channels. |
| </t> |
| |
| <figure anchor="downmix-matrix-3" |
| title="Stereo downmix matrix for the linear surround channel mapping" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| L output = ( 0.585786 * left + 0.414214 * center ) |
| R output = ( 0.414214 * center + 0.585786 * right ) |
| ]]></artwork> |
| <postamble> |
| Exact coefficient values are 1 and 1/sqrt(2), multiplied by |
| 1/(1 + 1/sqrt(2)) for normalization. |
| </postamble> |
| </figure> |
| |
| <figure anchor="downmix-matrix-4" |
| title="Stereo downmix matrix for the quadraphonic channel mapping" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| / \ / \ / FL \ |
| | L output | | 0.422650 0.000000 0.366025 0.211325 | | FR | |
| | R output | = | 0.000000 0.422650 0.211325 0.366025 | | RL | |
| \ / \ / \ RR / |
| ]]></artwork> |
| <postamble> |
| Exact coefficient values are 1, sqrt(3)/2 and 1/2, multiplied by |
| 1/(1 + sqrt(3)/2 + 1/2) for normalization. |
| </postamble> |
| </figure> |
| |
| <figure anchor="downmix-matrix-5" |
| title="Stereo downmix matrix for the 5.0 surround mapping" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| / FL \ |
| / \ / \ | FC | |
| | L | | 0.650802 0.460186 0.000000 0.563611 0.325401 | | FR | |
| | R | = | 0.000000 0.460186 0.650802 0.325401 0.563611 | | RL | |
| \ / \ / | RR | |
| \ / |
| ]]></artwork> |
| <postamble> |
| Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by |
| 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2) |
| for normalization. |
| </postamble> |
| </figure> |
| |
| <figure anchor="downmix-matrix-6" |
| title="Stereo downmix matrix for the 5.1 surround mapping" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| /FL \ |
| / \ / \ |FC | |
| |L| | 0.529067 0.374107 0.000000 0.458186 0.264534 0.374107 | |FR | |
| |R| = | 0.000000 0.374107 0.529067 0.264534 0.458186 0.374107 | |RL | |
| \ / \ / |RR | |
| \LFE/ |
| ]]></artwork> |
| <postamble> |
| Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by |
| 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2 + 1/sqrt(2)) |
| for normalization. |
| </postamble> |
| </figure> |
| |
| <figure anchor="downmix-matrix-7" |
| title="Stereo downmix matrix for the 6.1 surround mapping" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| / \ |
| | 0.455310 0.321953 0.000000 0.394310 0.227655 0.278819 0.321953 | |
| | 0.000000 0.321953 0.455310 0.227655 0.394310 0.278819 0.321953 | |
| \ / |
| ]]></artwork> |
| <postamble> |
| Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2, 1/2 and |
| sqrt(3)/2/sqrt(2), multiplied by |
| 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2 + |
| sqrt(3)/2/sqrt(2) + 1/sqrt(2)) for normalization. |
| The coefficients are in the same order as in <xref target="channel_mapping_1" />, |
| and the matrices above. |
| </postamble> |
| </figure> |
| |
| <figure anchor="downmix-matrix-8" |
| title="Stereo downmix matrix for the 7.1 surround mapping" |
| align="center"> |
| <artwork align="center"><![CDATA[ |
| / \ |
| | .388631 .274804 .000000 .336565 .194316 .336565 .194316 .274804 | |
| | .000000 .274804 .388631 .194316 .336565 .194316 .336565 .274804 | |
| \ / |
| ]]></artwork> |
| <postamble> |
| Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by |
| 2/(2 + 2/sqrt(2) + sqrt(3)) for normalization. |
| The coefficients are in the same order as in <xref target="channel_mapping_1" />, |
| and the matrices above. |
| </postamble> |
| </figure> |
| |
| </section> |
| |
| </section> <!-- end channel_mapping_table --> |
| |
| </section> <!-- end id_header --> |
| |
| <section anchor="comment_header" title="Comment Header"> |
| |
| <figure anchor="comment_header_packet" title="Comment Header Packet" |
| align="center"> |
| <artwork align="center"><![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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 'O' | 'p' | 'u' | 's' | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 'T' | 'a' | 'g' | 's' | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Vendor String Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| : Vendor String... : |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | User Comment List Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | User Comment #0 String Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| : User Comment #0 String... : |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | User Comment #1 String Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : : |
| ]]></artwork> |
| </figure> |
| |
| <t> |
| The comment header consists of a 64-bit magic signature, followed by data in |
| the same format as the <xref target="vorbis-comment"/> header used in Ogg |
| Vorbis, except (like Ogg Theora and Speex) the final "framing bit" specified |
| in the Vorbis spec is not present. |
| <list style="numbers"> |
| <t>Magic Signature: |
| <vspace blankLines="1"/> |
| This is an 8-octet (64-bit) field that allows codec identification and is |
| human-readable. |
| It contains, in order, the magic numbers: |
| <list style="empty"> |
| <t>0x4F 'O'</t> |
| <t>0x70 'p'</t> |
| <t>0x75 'u'</t> |
| <t>0x73 's'</t> |
| <t>0x54 'T'</t> |
| <t>0x61 'a'</t> |
| <t>0x67 'g'</t> |
| <t>0x73 's'</t> |
| </list> |
| Starting with "Op" helps distinguish it from audio data packets, as this is an |
| invalid TOC sequence. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Vendor String Length (32 bits, unsigned, little endian): |
| <vspace blankLines="1"/> |
| This field gives the length of the following vendor string, in octets. |
| It MUST NOT indicate that the vendor string is longer than the rest of the |
| packet. |
| <vspace blankLines="1"/> |
| </t> |
| <t>Vendor String (variable length, UTF-8 vector): |
| <vspace blankLines="1"/> |
| This is a simple human-readable tag for vendor information, encoded as a UTF-8 |
| string <xref target="RFC3629"/>. |
| No terminating null octet is necessary. |
| <vspace blankLines="1"/> |
| This tag is intended to identify the codec encoder and encapsulation |
| implementations, for tracing differences in technical behavior. |
| User-facing applications can use the 'ENCODER' user comment tag to identify |
| themselves. |
| <vspace blankLines="1"/> |
| </t> |
| <t>User Comment List Length (32 bits, unsigned, little endian): |
| <vspace blankLines="1"/> |
| This field indicates the number of user-supplied comments. |
| It MAY indicate there are zero user-supplied comments, in which case there are |
| no additional fields in the packet. |
| It MUST NOT indicate that there are so many comments that the comment string |
| lengths would require more data than is available in the rest of the packet. |
| <vspace blankLines="1"/> |
| </t> |
| <t>User Comment #i String Length (32 bits, unsigned, little endian): |
| <vspace blankLines="1"/> |
| This field gives the length of the following user comment string, in octets. |
| There is one for each user comment indicated by the 'user comment list length' |
| field. |
| It MUST NOT indicate that the string is longer than the rest of the packet. |
| <vspace blankLines="1"/> |
| </t> |
| <t>User Comment #i String (variable length, UTF-8 vector): |
| <vspace blankLines="1"/> |
| This field contains a single user comment encoded as a UTF-8 |
| string <xref target="RFC3629"/>. |
| There is one for each user comment indicated by the 'user comment list length' |
| field. |
| </t> |
| </list> |
| </t> |
| |
| <t> |
| The vendor string length and user comment list length are REQUIRED, and |
| implementations SHOULD treat a stream as invalid if it contains a comment |
| header that does not have enough data for these fields, or that does not |
| contain enough data for the corresponding vendor string or user comments they |
| describe. |
| Making this check before allocating the associated memory to contain the data |
| helps prevent a possible Denial-of-Service (DoS) attack from small comment |
| headers that claim to contain strings longer than the entire packet or more |
| user comments than than could possibly fit in the packet. |
| </t> |
| |
| <t> |
| Immediately following the user comment list, the comment header MAY |
| contain zero-padding or other binary data which is not specified here. |
| If the least-significant bit of the first byte of this data is 1, then editors |
| SHOULD preserve the contents of this data when updating the tags, but if this |
| bit is 0, all such data MAY be treated as padding, and truncated or discarded |
| as desired. |
| This allows informal experimentation with the format of this binary data until |
| it can be specified later. |
| </t> |
| |
| <t> |
| The comment header can be arbitrarily large and might be spread over a large |
| number of Ogg pages. |
| Implementations MUST avoid attempting to allocate excessive amounts of memory |
| when presented with a very large comment header. |
| To accomplish this, implementations MAY treat a stream as invalid if it has a |
| comment header larger than 125,829,120 octets (120 MB), and MAY |
| ignore individual comments that are not fully contained within the first |
| 61,440 octets of the comment header. |
| </t> |
| |
| <section anchor="comment_format" title="Tag Definitions"> |
| <t> |
| The user comment strings follow the NAME=value format described by |
| <xref target="vorbis-comment"/> with the same recommended tag names: |
| ARTIST, TITLE, DATE, ALBUM, and so on. |
| </t> |
| <t> |
| Two new comment tags are introduced here: |
| </t> |
| |
| <t>First, an optional gain for track normalization:</t> |
| <figure align="center"> |
| <artwork align="left"><![CDATA[ |
| R128_TRACK_GAIN=-573 |
| ]]></artwork> |
| </figure> |
| <t> |
| representing the volume shift needed to normalize the track's volume |
| during isolated playback, in random shuffle, and so on. |
| The gain is a Q7.8 fixed point number in dB, as in the ID header's 'output |
| gain' field. |
| This tag is similar to the REPLAYGAIN_TRACK_GAIN tag in |
| Vorbis <xref target="replay-gain"/>, except that the normal volume |
| reference is the <xref target="EBU-R128"/> standard. |
| </t> |
| <t>Second, an optional gain for album normalization:</t> |
| <figure align="center"> |
| <artwork align="left"><![CDATA[ |
| R128_ALBUM_GAIN=111 |
| ]]></artwork> |
| </figure> |
| <t> |
| representing the volume shift needed to normalize the overall volume when |
| played as part of a particular collection of tracks. |
| The gain is also a Q7.8 fixed point number in dB, as in the ID header's |
| 'output gain' field. |
| The values '-573' and '111' given here are just examples. |
| </t> |
| <t> |
| An Ogg Opus stream MUST NOT have more than one of each of these tags, and if |
| present their values MUST be an integer from -32768 to 32767, inclusive, |
| represented in ASCII as a base 10 number with no whitespace. |
| A leading '+' or '-' character is valid. |
| Leading zeros are also permitted, but the value MUST be represented by |
| no more than 6 characters. |
| Other non-digit characters MUST NOT be present. |
| </t> |
| <t> |
| If present, R128_TRACK_GAIN and R128_ALBUM_GAIN MUST correctly represent |
| the R128 normalization gain relative to the 'output gain' field specified |
| in the ID header. |
| If a player chooses to make use of the R128_TRACK_GAIN tag or the |
| R128_ALBUM_GAIN tag, it MUST apply those gains |
| <spanx style="emph">in addition</spanx> to the 'output gain' value. |
| If a tool modifies the ID header's 'output gain' field, it MUST also update or |
| remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present. |
| A muxer SHOULD place the gain it wants other tools to use by default into the |
| 'output gain' field, and not the comment tag. |
| </t> |
| <t> |
| To avoid confusion with multiple normalization schemes, an Opus comment header |
| SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, |
| REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags, unless they are only |
| to be used in some context where there is guaranteed to be no such confusion. |
| <xref target="EBU-R128"/> normalization is preferred to the earlier |
| REPLAYGAIN schemes because of its clear definition and adoption by industry. |
| Peak normalizations are difficult to calculate reliably for lossy codecs |
| because of variation in excursion heights due to decoder differences. |
| In the authors' investigations they were not applied consistently or broadly |
| enough to merit inclusion here. |
| </t> |
| </section> <!-- end comment_format --> |
| </section> <!-- end comment_header --> |
| |
| </section> <!-- end headers --> |
| |
| <section anchor="packet_size_limits" title="Packet Size Limits"> |
| <t> |
| Technically, valid Opus packets can be arbitrarily large due to the padding |
| format, although the amount of non-padding data they can contain is bounded. |
| These packets might be spread over a similarly enormous number of Ogg pages. |
| When encoding, implementations SHOULD limit the use of padding in audio data |
| packets to no more than is necessary to make a variable bitrate (VBR) stream |
| constant bitrate (CBR), unless they have no reasonable way to determine what |
| is necessary. |
| Demuxers SHOULD treat audio data packets as invalid (treat them as if they were |
| malformed Opus packets with an invalid TOC sequence) if they are larger than |
| 61,440 octets per Opus stream, unless they have a specific reason for |
| allowing extra padding. |
| Such packets necessarily contain more padding than needed to make a stream CBR. |
| Demuxers MUST avoid attempting to allocate excessive amounts of memory when |
| presented with a very large packet. |
| Demuxers MAY treat audio data packets as invalid or partially process them if |
| they are larger than 61,440 octets in an Ogg Opus stream with channel |
| mapping families 0 or 1. |
| Demuxers MAY treat audio data packets as invalid or partially process them in |
| any Ogg Opus stream if the packet is larger than 61,440 octets and also |
| larger than 7,680 octets per Opus stream. |
| The presence of an extremely large packet in the stream could indicate a |
| memory exhaustion attack or stream corruption. |
| </t> |
| <t> |
| In an Ogg Opus stream, the largest possible valid packet that does not use |
| padding has a size of (61,298*N - 2) octets. |
| With 255 streams, this is 15,630,988 octets and can |
| span up to 61,298 Ogg pages, all but one of which will have a granule |
| position of -1. |
| This is of course a very extreme packet, consisting of 255 streams, each |
| containing 120 ms of audio encoded as 2.5 ms frames, each frame |
| using the maximum possible number of octets (1275) and stored in the least |
| efficient manner allowed (a VBR code 3 Opus packet). |
| Even in such a packet, most of the data will be zeros as 2.5 ms frames |
| cannot actually use all 1275 octets. |
| </t> |
| <t> |
| The largest packet consisting of entirely useful data is |
| (15,326*N - 2) octets. |
| This corresponds to 120 ms of audio encoded as 10 ms frames in either |
| SILK or Hybrid mode, but at a data rate of over 1 Mbps, which makes little |
| sense for the quality achieved. |
| </t> |
| <t> |
| A more reasonable limit is (7,664*N - 2) octets. |
| 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). |
| For channel mapping family 1, N=8 provides a reasonable upper bound, as it |
| allows for each of the 8 possible output channels to be decoded from a |
| separate stereo Opus stream. |
| This gives a size of 61,310 octets, which is rounded up to a multiple of |
| 1,024 octets to yield the audio data packet size of 61,440 octets |
| that any implementation is expected to be able to process successfully. |
| </t> |
| </section> |
| |
| <section anchor="encoder" title="Encoder Guidelines"> |
| <t> |
| When encoding Opus streams, Ogg muxers SHOULD take into account the |
| algorithmic delay of the Opus encoder. |
| </t> |
| <t> |
| In encoders derived from the reference |
| implementation <xref target="RFC6716"/>, the number of samples can be |
| queried with: |
| </t> |
| <figure align="center"> |
| <artwork align="center"><![CDATA[ |
| opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD(&delay_samples)); |
| ]]></artwork> |
| </figure> |
| <t> |
| To achieve good quality in the very first samples of a stream, implementations |
| MAY use linear predictive coding (LPC) extrapolation to generate at least 120 |
| extra samples at the beginning to avoid the Opus encoder having to encode a |
| discontinuous signal. |
| For more information on linear prediction, see |
| <xref target="linear-prediction"/>. |
| For an input file containing 'length' samples, the implementation SHOULD set |
| the pre-skip header value to (delay_samples + extra_samples), encode |
| at least (length + delay_samples + extra_samples) |
| samples, and set the granule position of the last page to |
| (length + delay_samples + extra_samples). |
| This ensures that the encoded file has the same duration as the original, with |
| no time offset. The best way to pad the end of the stream is to also use LPC |
| extrapolation, but zero-padding is also acceptable. |
| </t> |
| |
| <section anchor="lpc" title="LPC Extrapolation"> |
| <t> |
| The first step in LPC extrapolation is to compute linear prediction |
| coefficients. <xref target="lpc-sample"/> |
| When extending the end of the signal, order-N (typically with N ranging from 8 |
| to 40) LPC analysis is performed on a window near the end of the signal. |
| The last N samples are used as memory to an infinite impulse response (IIR) |
| filter. |
| </t> |
| <t> |
| The filter is then applied on a zero input to extrapolate the end of the signal. |
| Let a(k) be the kth LPC coefficient and x(n) be the nth sample of the signal, |
| each new sample past the end of the signal is computed as: |
| </t> |
| <figure align="center"> |
| <artwork align="center"><![CDATA[ |
| N |
| --- |
| x(n) = \ a(k)*x(n-k) |
| / |
| --- |
| k=1 |
| ]]></artwork> |
| </figure> |
| <t> |
| The process is repeated independently for each channel. |
| It is possible to extend the beginning of the signal by applying the same |
| process backward in time. |
| When extending the beginning of the signal, it is best to apply a "fade in" to |
| the extrapolated signal, e.g. by multiplying it by a half-Hanning window |
| <xref target="hanning"/>. |
| </t> |
| |
| </section> |
| |
| <section anchor="continuous_chaining" title="Continuous Chaining"> |
| <t> |
| In some applications, such as Internet radio, it is desirable to cut a long |
| stream into smaller chains, e.g. so the comment header can be updated. |
| This can be done simply by separating the input streams into segments and |
| encoding each segment independently. |
| The drawback of this approach is that it creates a small discontinuity |
| at the boundary due to the lossy nature of Opus. |
| A muxer MAY avoid this discontinuity by using the following procedure: |
| <list style="numbers"> |
| <t>Encode the last frame of the first segment as an independent frame by |
| turning off all forms of inter-frame prediction. |
| De-emphasis is allowed.</t> |
| <t>Set the granule position of the last page to a point near the end of the |
| last frame.</t> |
| <t>Begin the second segment with a copy of the last frame of the first |
| segment.</t> |
| <t>Set the pre-skip value of the second stream in such a way as to properly |
| join the two streams.</t> |
| <t>Continue the encoding process normally from there, without any reset to |
| the encoder.</t> |
| </list> |
| </t> |
| <t> |
| In encoders derived from the reference implementation, inter-frame prediction |
| can be turned off by calling: |
| </t> |
| <figure align="center"> |
| <artwork align="center"><![CDATA[ |
| opus_encoder_ctl(encoder_state, OPUS_SET_PREDICTION_DISABLED(1)); |
| ]]></artwork> |
| </figure> |
| <t> |
| For best results, this implementation requires that prediction be explicitly |
| enabled again before resuming normal encoding, even after a reset. |
| </t> |
| |
| </section> |
| |
| </section> |
| |
| <section anchor="implementation" title="Implementation Status"> |
| <t> |
| A brief summary of major implementations of this draft is available |
| at <eref target="https://wiki.xiph.org/OggOpusImplementation"/>, |
| along with their status. |
| </t> |
| <t> |
| [Note to RFC Editor: please remove this entire section before |
| final publication per <xref target="RFC6982"/>, along with |
| its references.] |
| </t> |
| </section> |
| |
| <section anchor="security" title="Security Considerations"> |
| <t> |
| Implementations of the Opus codec need to take appropriate security |
| considerations into account, as outlined in <xref target="RFC4732"/>. |
| This is just as much a problem for the container as it is for the codec itself. |
| Malicious payloads and/or input streams can be used to attack codec |
| implementations. |
| Implementations MUST NOT overrun their allocated memory nor consume excessive |
| resources when decoding payloads or processing input streams. |
| Although problems in encoding applications are typically rarer, this still |
| applies to a muxer, as vulnerabilities would allow an attacker to attack |
| transcoding gateways. |
| </t> |
| |
| <t> |
| Header parsing code contains the most likely area for potential overruns. |
| It is important for implementations to ensure their buffers contain enough |
| data for all of the required fields before attempting to read it (for example, |
| for all of the channel map data in the ID header). |
| Implementations would do well to validate the indices of the channel map, also, |
| to ensure they meet all of the restrictions outlined in |
| <xref target="channel_mapping"/>, in order to avoid attempting to read data |
| from channels that do not exist. |
| </t> |
| |
| <t> |
| To avoid excessive resource usage, we advise implementations to be especially |
| wary of streams that might cause them to process far more data than was |
| actually transmitted. |
| For example, a relatively small comment header may contain values for the |
| string lengths or user comment list length that imply that it is many |
| gigabytes in size. |
| Even computing the size of the required buffer could overflow a 32-bit integer, |
| and actually attempting to allocate such a buffer before verifying it would be |
| a reasonable size is a bad idea. |
| After reading the user comment list length, implementations might wish to |
| verify that the header contains at least the minimum amount of data for that |
| many comments (4 additional octets per comment, to indicate each has a |
| length of zero) before proceeding any further, again taking care to avoid |
| overflow in these calculations. |
| If allocating an array of pointers to point at these strings, the size of the |
| pointers may be larger than 4 octets, potentially requiring a separate |
| overflow check. |
| </t> |
| |
| <t> |
| Another bug in this class we have observed more than once involves the handling |
| of invalid data at the end of a stream. |
| Often, implementations will seek to the end of a stream to locate the last |
| timestamp in order to compute its total duration. |
| If they do not find a valid capture pattern and Ogg page from the desired |
| logical stream, they will back up and try again. |
| If care is not taken to avoid re-scanning data that was already scanned, this |
| search can quickly devolve into something with a complexity that is quadratic |
| in the amount of invalid data. |
| </t> |
| |
| <t> |
| In general when seeking, implementations will wish to be cautious about the |
| effects of invalid granule position values, and ensure all algorithms will |
| continue to make progress and eventually terminate, even if these are missing |
| or out-of-order. |
| </t> |
| |
| <t> |
| Like most other container formats, Ogg Opus streams SHOULD NOT be used with |
| insecure ciphers or cipher modes that are vulnerable to known-plaintext |
| attacks. |
| Elements such as the Ogg page capture pattern and the magic signatures in the |
| ID header and the comment header all have easily predictable values, in |
| addition to various elements of the codec data itself. |
| </t> |
| </section> |
| |
| <section anchor="content_type" title="Content Type"> |
| <t> |
| An "Ogg Opus file" consists of one or more sequentially multiplexed segments, |
| each containing exactly one Ogg Opus stream. |
| The RECOMMENDED mime-type for Ogg Opus files is "audio/ogg". |
| </t> |
| |
| <t> |
| If more specificity is desired, one MAY indicate the presence of Opus streams |
| using the codecs parameter defined in <xref target="RFC6381"/> and |
| <xref target="RFC5334"/>, e.g., |
| </t> |
| <figure> |
| <artwork align="center"><![CDATA[ |
| audio/ogg; codecs=opus |
| ]]></artwork> |
| </figure> |
| <t> |
| for an Ogg Opus file. |
| </t> |
| |
| <t> |
| The RECOMMENDED filename extension for Ogg Opus files is '.opus'. |
| </t> |
| |
| <t> |
| When Opus is concurrently multiplexed with other streams in an Ogg container, |
| one SHOULD use one of the "audio/ogg", "video/ogg", or "application/ogg" |
| mime-types, as defined in <xref target="RFC5334"/>. |
| Such streams are not strictly "Ogg Opus files" as described above, |
| since they contain more than a single Opus stream per sequentially |
| multiplexed segment, e.g. video or multiple audio tracks. |
| In such cases the the '.opus' filename extension is NOT RECOMMENDED. |
| </t> |
| |
| <t> |
| In either case, this document updates <xref target="RFC5334"/> |
| to add 'opus' as a codecs parameter value with char[8]: 'OpusHead' |
| as Codec Identifier. |
| </t> |
| </section> |
| |
| <section anchor="iana" title="IANA Considerations"> |
| <t> |
| This document updates the IANA Media Types registry to add .opus |
| as a file extension for "audio/ogg", and to add itself as a reference |
| alongside <xref target="RFC5334"/> for "audio/ogg", "video/ogg", and |
| "application/ogg" Media Types. |
| </t> |
| <t> |
| This document defines a new registry "Opus Channel Mapping Families" to |
| indicate how the semantic meanings of the channels in a multi-channel Opus |
| stream are described. |
| IANA is requested to create a new name space of "Opus Channel Mapping |
| Families". |
| This will be a new registry on the IANA Matrix, and not a subregistry of an |
| existing registry. |
| Modifications to this registry follow the "Specification Required" registration |
| policy as defined in <xref target="RFC5226"/>. |
| Each registry entry consists of a Channel Mapping Family Number, which is |
| specified in decimal in the range 0 to 255, inclusive, and a Reference (or |
| list of references) |
| Each Reference must point to sufficient documentation to describe what |
| information is coded in the Opus identification header for this channel |
| mapping family, how a demuxer determines the Stream Count ('N') and Coupled |
| Stream Count ('M') from this information, and how it determines the proper |
| interpretation of each of the decoded channels. |
| </t> |
| <t> |
| This document defines three initial assignments for this registry. |
| </t> |
| <texttable> |
| <ttcol>Value</ttcol><ttcol>Reference</ttcol> |
| <c>0</c><c>[RFCXXXX] <xref target="channel_mapping_0"/></c> |
| <c>1</c><c>[RFCXXXX] <xref target="channel_mapping_1"/></c> |
| <c>255</c><c>[RFCXXXX] <xref target="channel_mapping_255"/></c> |
| </texttable> |
| <t> |
| The designated expert will determine if the Reference points to a specification |
| that meets the requirements for permanence and ready availability laid out |
| in <xref target="RFC5226"/> and that it specifies the information |
| described above with sufficient clarity to allow interoperable |
| implementations. |
| </t> |
| </section> |
| |
| <section anchor="Acknowledgments" title="Acknowledgments"> |
| <t> |
| Thanks to Ben Campbell, Joel M. Halpern, Mark Harris, Greg Maxwell, |
| Christopher "Monty" Montgomery, Jean-Marc Valin, Stephan Wenger, and Mo Zanaty |
| for their valuable contributions to this document. |
| Additional thanks to Andrew D'Addesio, Greg Maxwell, and Vincent Penquerc'h for |
| their feedback based on early implementations. |
| </t> |
| </section> |
| |
| <section title="RFC Editor Notes"> |
| <t> |
| In <xref target="iana"/>, "RFCXXXX" is to be replaced with the RFC number |
| assigned to this draft. |
| </t> |
| </section> |
| |
| </middle> |
| <back> |
| <references title="Normative References"> |
| &rfc2119; |
| &rfc3533; |
| &rfc3629; |
| &rfc5226; |
| &rfc5334; |
| &rfc6381; |
| &rfc6716; |
| |
| <reference anchor="EBU-R128" target="https://tech.ebu.ch/loudness"> |
| <front> |
| <title>Loudness Recommendation EBU R128</title> |
| <author> |
| <organization>EBU Technical Committee</organization> |
| </author> |
| <date month="August" year="2011"/> |
| </front> |
| </reference> |
| |
| <reference anchor="vorbis-comment" |
| target="https://www.xiph.org/vorbis/doc/v-comment.html"> |
| <front> |
| <title>Ogg Vorbis I Format Specification: Comment Field and Header |
| Specification</title> |
| <author initials="C." surname="Montgomery" |
| fullname="Christopher "Monty" Montgomery"/> |
| <date month="July" year="2002"/> |
| </front> |
| </reference> |
| |
| </references> |
| |
| <references title="Informative References"> |
| |
| <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml"?--> |
| &rfc4732; |
| &rfc6982; |
| &rfc7587; |
| |
| <reference anchor="flac" |
| target="https://xiph.org/flac/format.html"> |
| <front> |
| <title>FLAC - Free Lossless Audio Codec Format Description</title> |
| <author initials="J." surname="Coalson" fullname="Josh Coalson"/> |
| <date month="January" year="2008"/> |
| </front> |
| </reference> |
| |
| <reference anchor="hanning" |
| target="https://en.wikipedia.org/w/index.php?title=Window_function&oldid=703074467#Hann_.28Hanning.29_window"> |
| <front> |
| <title>Hann window</title> |
| <author> |
| <organization>Wikipedia</organization> |
| </author> |
| <date month="February" year="2016"/> |
| </front> |
| </reference> |
| |
| <reference anchor="linear-prediction" |
| target="https://en.wikipedia.org/w/index.php?title=Linear_predictive_coding&oldid=687498962"> |
| <front> |
| <title>Linear Predictive Coding</title> |
| <author> |
| <organization>Wikipedia</organization> |
| </author> |
| <date month="October" year="2015"/> |
| </front> |
| </reference> |
| |
| <reference anchor="lpc-sample" |
| target="https://svn.xiph.org/trunk/vorbis/lib/lpc.c"> |
| <front> |
| <title>Autocorrelation LPC coeff generation algorithm |
| (Vorbis source code)</title> |
| <author initials="J." surname="Degener" fullname="Jutta Degener"/> |
| <author initials="C." surname="Bormann" fullname="Carsten Bormann"/> |
| <date month="November" year="1994"/> |
| </front> |
| </reference> |
| |
| <reference anchor="q-notation" |
| target="https://en.wikipedia.org/w/index.php?title=Q_%28number_format%29&oldid=697252615"> |
| <front> |
| <title>Q (number format)</title> |
| <author><organization>Wikipedia</organization></author> |
| <date month="December" year="2015"/> |
| </front> |
| </reference> |
| |
| <reference anchor="replay-gain" |
| target="https://wiki.xiph.org/VorbisComment#Replay_Gain"> |
| <front> |
| <title>VorbisComment: Replay Gain</title> |
| <author initials="C." surname="Parker" fullname="Conrad Parker"/> |
| <author initials="M." surname="Leese" fullname="Martin Leese"/> |
| <date month="June" year="2009"/> |
| </front> |
| </reference> |
| |
| <reference anchor="seeking" |
| target="https://wiki.xiph.org/Seeking"> |
| <front> |
| <title>Granulepos Encoding and How Seeking Really Works</title> |
| <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/> |
| <author initials="C." surname="Parker" fullname="Conrad Parker"/> |
| <author initials="G." surname="Maxwell" fullname="Greg Maxwell"/> |
| <date month="May" year="2012"/> |
| </front> |
| </reference> |
| |
| <reference anchor="vorbis-mapping" |
| target="https://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-810004.3.9"> |
| <front> |
| <title>The Vorbis I Specification, Section 4.3.9 Output Channel Order</title> |
| <author initials="C." surname="Montgomery" |
| fullname="Christopher "Monty" Montgomery"/> |
| <date month="January" year="2010"/> |
| </front> |
| </reference> |
| |
| <reference anchor="vorbis-trim" |
| target="https://xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-132000A.2"> |
| <front> |
| <title>The Vorbis I Specification, Appendix A: Embedding Vorbis |
| into an Ogg stream</title> |
| <author initials="C." surname="Montgomery" |
| fullname="Christopher "Monty" Montgomery"/> |
| <date month="November" year="2008"/> |
| </front> |
| </reference> |
| |
| <reference anchor="wave-multichannel" |
| target="http://msdn.microsoft.com/en-us/windows/hardware/gg463006.aspx"> |
| <front> |
| <title>Multiple Channel Audio Data and WAVE Files</title> |
| <author> |
| <organization>Microsoft Corporation</organization> |
| </author> |
| <date month="March" year="2007"/> |
| </front> |
| </reference> |
| |
| </references> |
| |
| </back> |
| </rfc> |
