[opus] Channel Mapping Family for Ambisonics
Michael Graczyk
mgraczyk at google.com
Fri May 27 01:04:47 UTC 2016
Hello Jean-Marc,
Thanks for the quick reply and comments.
On Thu, May 26, 2016 at 5:41 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:
> Hi Michael,
>
> Here's some more minor comments below. As long as you address the two
> comments from my previous email (254 -> 2 and the draft name), the draft
> is good for submitting as initial version on the IETF website (even if
> you don't address all the minor comments from this email). FYI, this is
> the address for submitting a new draft:
> https://datatracker.ietf.org/submit/
Thanks I have fixed these and will submit.
> Introduction: "The Ogg format is a container which transmission and
> storage of audio coded using the Opus codec."
I changed "which" to "for"
> I think I forgot a word in this sentence. Also, Ogg is a general
> container and isn't just for Opus.
Rephrased to "... of audio. It can be used to encapsulate streamscoded
using the Opus codec."
> Section 3: "A demuxer implmentation encountering Channel Mapping Family
> 254 SHOULD interpret the Opus stream as containing ambisonics with the
> format described in Section 3.1."
>
> Aside from changing 254 to 2, the "SHOULD" should be a "MUST".
Changed to "MUST". I used SHOULD because that is what is in RFC7845
5.1.1.4. I reasoned that if an implementation were allowed to treat
mapping family 2 its own way (based on the language in 5.1.1.4), then
I shouldn't change that behavior. It makes sense to make this strict
though.
> Section 3.1: "Allowed numbers of channels: (1 + l)^2 for l = 0...14"
>
> Minor nit: unless the use of "l" is standard for talking about
> ambisonics, I would suggest using "k" instead, since "l" is easy to
> confuse with "1".
Actually "n" is common and is used in the [ambix] reference, so I
switched to that and changed the language here to be consistent with
[ambix].
> Section 3.1: If it's not too complicated, can you explain how the "m"
> index is derived?
I added equations to derive n and m from channel index.
I've attached updated versions of the document.
-------------- next part --------------
<?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 rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'>
<!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7845.xml'>
]>
<?rfc toc="yes" symrefs="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-graczyk-opus-ambisonics"
updates="7845">
<front>
<title abbrev="Opus Ambisonics">Ambisonics in an Ogg Opus Container</title>
<author initials="M.G." surname="Graczyk" fullname="Michael Graczyk">
<organization>Google Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>mgraczyk at google.com</email>
</address>
</author>
<date day="24" month="May" year="2016"/>
<area>RAI</area>
<workgroup>codec</workgroup>
<abstract>
<t>
This document defines an extension to the Ogg format to encapsulate
ambisonics coded using the Opus audio codec.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Ambisonics is a representation format for three dimensional sound fields which
can be used for surround sound and immersive virtual reality playback.
See <xref target="gerzon75"/> and <xref target="daniel04"/> for technical
details on the ambisonics format.
For the purposes of the this document, ambisonics can be considered a
multichannel audio stream.
The Ogg format is a container for transmission and storage of audio. It can be
used to encapsulate streamscoded using the Opus codec.
See <xref target="RFC6716"/> and <xref target="RFC7845"/> for technical details
on the Opus codec and its encapsulation in the Ogg container respectively.
</t>
<t>
This document extends the Ogg format by defining a new channel mapping family for
encoding ambisonics. The Ogg Opus format is extended indirectly by adding an
item with value 2 to the IANA "Opus Channel Mapping Families" registry. When
2 is used as the Channel Mapping Family Number in an Ogg stream, the semantic
meaning of the channels in the multichannel Opus stream is the ambisonics layout
defined in this document.
</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="ogg_extension" title="Ambisonics With Ogg Opus">
<t>
Ambisonics MAY be encapsulated in the Ogg format by encoding with the Opus codec
and setting the Channel Mapping Family value to 2 in the Ogg Identification
Header. A demuxer implmentation encountering Channel Mapping Family 2 MUST
interpret the Opus stream as containing ambisonics with the format described in
<xref target="channel_mapping"/>.
</t>
<section anchor="channel_mapping" title="Channel Mapping Family 2">
<t>
Allowed numbers of channels: (1 + n)^2 for n = 0...14.
Explicitly 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225.
Ambisonics from zeroth to fourteenth order.
</t>
<t>
This channel mapping uses the same channel mapping table format used by channel
mapping families 1 and 255. Each output channel is assigned to an ambisonic
component in Ambisonic Channel Number (ACN) order. The ambisonic component with
order n and degree m corresponds to channel (n * (n + 1) + m). The reverse
correspondence can also be computed for a channel with index k.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
order n = ceil(sqrt(k)) - 1,
degree m = k - n * (n + 1).
]]></artwork>
</figure>
<t>
Channels are normalized with Schmidt Semi-Normalization (SN3D) with no
Condon-Shortley phase factor. In SN3D, the spherical harmonic of order n and
degree m is normalized according to
</t>
<figure align="center">
<artwork align="center"><![CDATA[
sqrt((2 - delta(m)) * ((n - m)! / (n + m)!)),
]]></artwork>
</figure>
<t>
where delta(0) = 1 and delta(m) = 0 otherwise.
</t>
<t>
The interpretation of the ambisonics signal as well as the channel order and
normalization are described in <xref target="ambix"/>.
</t>
</section>
<section anchor="downmixing" title="Downmixing">
<t>
Implementations MAY use the matrix in Figure
<xref target="stereo_downmix_matrix" format="counter"/> to implement
downmixing from multichannel files using Channel Mapping Family 2
<xref target="channel_mapping"/>, which is known to give acceptable
results for stereo.
</t>
<figure anchor="stereo_downmix_matrix" title="Stereo Downmixing Matrix" align="center">
<artwork align="center"><![CDATA[
/ \ / \ / W \
| L | | 0.5 0.5 0.0 ... | | Y |
| R | = | 0.5 -0.5 0.0 ... | | ... |
\ / \ / \ ... /
]]></artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Implementations of the Ogg container need take appropriate security
considerations into account, as outlined in Section 10 of <xref target="RFC7845"/>.
The extension definied in this document requires that semantic meaning be
assigned to more channels than the existing Ogg format requires.
Since more allocations will be required to encode and decode these semantically
meaningful channels, care should be taken in any new allocation paths.
Implementations MUST NOT overrun their allocated memory nor read from
uninitialized memory when managing the ambisonic channel mapping.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This document updates the IANA Media Types registry "Opus Channel Mapping
Families" to add a new assignment.
</t>
<texttable>
<ttcol>Value</ttcol><ttcol>Reference</ttcol>
<c>2</c><c>This Document <xref target="channel_mapping"/></c>
</texttable>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
Thanks to Timothy Terriberry and Marcin Gorzel for their guidance and
valuable contributions to this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6716;
&rfc7845;
<reference anchor="ambix"
target="http://iem.kug.ac.at/fileadmin/media/iem/projects/2011/ambisonics11_nachbar_zotter_sontacchi_deleflie.pdf">
<front>
<title>AMBIX - A SUGGESTED AMBISONICS FORMAT</title>
<author initials="C." surname="Nachbar" fullname="Christian Nachbar"/>
<author initials="F." surname="Zotter" fullname="Franz Zotter"/>
<author initials="E." surname="Deleflie" fullname="Etienne Deleflie"/>
<author initials="A." surname="Sontacchi" fullname="Alois Sontacchi"/>
<date month="June" year="2011"/>
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="gerzon75"
target="http://www.michaelgerzonphotos.org.uk/articles/Ambisonics%201.pdf">
<front>
<title>Ambisonics. Part one: General system description</title>
<author initials="M." surname="Gerzon" fullname="Michael Gerzon"/>
<date month="August" year="1975"/>
</front>
</reference>
<reference anchor="daniel04"
target="http://pcfarina.eng.unipr.it/Public/phd-thesis/aes116%20high-passed%20hoa.pdf">
<front>
<title>Further Study of Sound Field Coding with Higher Order Ambisonics</title>
<author initials="J." surname="Daniel" fullname="Jérôme Daniel"/>
<author initials="S." surname="Moreau" fullname="Sébastien Moreau"/>
<date month="May" year="2004"/>
</front>
</reference>
</references>
</back>
</rfc>
-------------- next part --------------
codec M. Graczyk
Internet-Draft Google Inc.
Updates: 7845 (if approved) May 24, 2016
Intended status: Standards Track
Expires: November 25, 2016
Ambisonics in an Ogg Opus Container
draft-graczyk-opus-ambisonics
Abstract
This document defines an extension to the Ogg format to encapsulate
ambisonics coded using the Opus audio codec.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2016.
Graczyk Expires November 25, 2016 [Page 1]
Internet-Draft Opus Ambisonics May 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Ambisonics With Ogg Opus . . . . . . . . . . . . . . . . . . 2
3.1. Channel Mapping Family 2 . . . . . . . . . . . . . . . . 3
3.2. Downmixing . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Ambisonics is a representation format for three dimensional sound
fields which can be used for surround sound and immersive virtual
reality playback. See [gerzon75] and [daniel04] for technical
details on the ambisonics format. For the purposes of the this
document, ambisonics can be considered a multichannel audio stream.
The Ogg format is a container for transmission and storage of audio.
It can be used to encapsulate streamscoded using the Opus codec. See
[RFC6716] and [RFC7845] for technical details on the Opus codec and
its encapsulation in the Ogg container respectively.
This document extends the Ogg format by defining a new channel
mapping family for encoding ambisonics. The Ogg Opus format is
extended indirectly by adding an item with value 2 to the IANA "Opus
Channel Mapping Families" registry. When 2 is used as the Channel
Mapping Family Number in an Ogg stream, the semantic meaning of the
channels in the multichannel Opus stream is the ambisonics layout
defined in this document.
2. Terminology
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
[RFC2119].
3. Ambisonics With Ogg Opus
Ambisonics MAY be encapsulated in the Ogg format by encoding with the
Opus codec and setting the Channel Mapping Family value to 2 in the
Ogg Identification Header. A demuxer implmentation encountering
Graczyk Expires November 25, 2016 [Page 2]
Internet-Draft Opus Ambisonics May 2016
Channel Mapping Family 2 MUST interpret the Opus stream as containing
ambisonics with the format described in Section 3.1.
3.1. Channel Mapping Family 2
Allowed numbers of channels: (1 + n)^2 for n = 0...14. Explicitly 4,
9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225. Ambisonics
from zeroth to fourteenth order.
This channel mapping uses the same channel mapping table format used
by channel mapping families 1 and 255. Each output channel is
assigned to an ambisonic component in Ambisonic Channel Number (ACN)
order. The ambisonic component with order n and degree m corresponds
to channel (n * (n + 1) + m). The reverse correspondence can also be
computed for a channel with index k.
order n = ceil(sqrt(k)) - 1,
degree m = k - n * (n + 1).
Channels are normalized with Schmidt Semi-Normalization (SN3D) with
no Condon-Shortley phase factor. In SN3D, the spherical harmonic of
order n and degree m is normalized according to
sqrt((2 - delta(m)) * ((n - m)! / (n + m)!)),
where delta(0) = 1 and delta(m) = 0 otherwise.
The interpretation of the ambisonics signal as well as the channel
order and normalization are described in [ambix].
3.2. Downmixing
Implementations MAY use the matrix in Figure 1 to implement
downmixing from multichannel files using Channel Mapping Family 2
Section 3.1, which is known to give acceptable results for stereo.
/ \ / \ / W \
| L | | 0.5 0.5 0.0 ... | | Y |
| R | = | 0.5 -0.5 0.0 ... | | ... |
\ / \ / \ ... /
Figure 1: Stereo Downmixing Matrix
4. Security Considerations
Implementations of the Ogg container need take appropriate security
considerations into account, as outlined in Section 10 of [RFC7845].
The extension definied in this document requires that semantic
Graczyk Expires November 25, 2016 [Page 3]
Internet-Draft Opus Ambisonics May 2016
meaning be assigned to more channels than the existing Ogg format
requires. Since more allocations will be required to encode and
decode these semantically meaningful channels, care should be taken
in any new allocation paths. Implementations MUST NOT overrun their
allocated memory nor read from uninitialized memory when managing the
ambisonic channel mapping.
5. IANA Considerations
This document updates the IANA Media Types registry "Opus Channel
Mapping Families" to add a new assignment.
+-------+---------------------------+
| Value | Reference |
+-------+---------------------------+
| 2 | This Document Section 3.1 |
+-------+---------------------------+
6. Acknowledgments
Thanks to Timothy Terriberry and Marcin Gorzel for their guidance and
valuable contributions to this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
September 2012, <http://www.rfc-editor.org/info/rfc6716>.
[RFC7845] Terriberry, T., Lee, R., and R. Giles, "Ogg Encapsulation
for the Opus Audio Codec", RFC 7845, DOI 10.17487/RFC7845,
April 2016, <http://www.rfc-editor.org/info/rfc7845>.
[ambix] Nachbar, C., Zotter, F., Deleflie, E., and A. Sontacchi,
"AMBIX - A SUGGESTED AMBISONICS FORMAT", June 2011,
<http://iem.kug.ac.at/fileadmin/media/iem/projects/2011/
ambisonics11_nachbar_zotter_sontacchi_deleflie.pdf>.
Graczyk Expires November 25, 2016 [Page 4]
Internet-Draft Opus Ambisonics May 2016
7.2. Informative References
[gerzon75]
Gerzon, M., "Ambisonics. Part one: General system
description", August 1975,
<http://www.michaelgerzonphotos.org.uk/articles/
Ambisonics%201.pdf>.
[daniel04]
Daniel, J. and S. Moreau, "Further Study of Sound Field
Coding with Higher Order Ambisonics", May 2004,
<http://pcfarina.eng.unipr.it/Public/phd-thesis/
aes116%20high-passed%20hoa.pdf>.
Author's Address
Michael Graczyk
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
Email: mgraczyk at google.com
Graczyk Expires November 25, 2016 [Page 5]
More information about the opus
mailing list