Hello Tim and others,
Thanks for your help explaining this process on IRC. I wrote out a
first draft in the RFC xml format. I have attached the xml (labeled as
xml.txt so it will appear inline) and the rendered txt files. Please
let me know where I can make improvements. I will upload this draft to
the IETF datatracker and send it out to codec@ after addressing your
comments.
-------------- 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 which transmission and storage of audio coded
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 254 to the IANA "Opus Channel Mapping Families"
registry. When
254 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 254 in the Ogg Identification
Header. A demuxer implmentation encountering Channel Mapping Family 254 SHOULD
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 254">
<t>
Allowed numbers of channels: (1 + l)^2 for l = 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
degree n and ambisonic index m corresponds to channel (n * (n + 1) + m).
Channels are normalized with Schmidt Semi-Normalization (SN3D) with no
Condon-Shortley phase factor. In SN3D, the spherical harmonic of degree n and
index m is normalized according to
</t>
<figure align="center">
<artwork align="center"><![CDATA[
sqrt((2 - delta(m)) * ((l - m)! / (l + 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 254 (Section
TODO), 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>254</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 254 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 4
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 which transmission and storage of audio
coded 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 254 to the IANA
"Opus Channel Mapping Families" registry. When 254 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 254 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 254 SHOULD interpret the Opus stream as
containing ambisonics with the format described in Section 3.1.
3.1. Channel Mapping Family 254
Allowed numbers of channels: (1 + l)^2 for l = 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 degree n and ambisonic index m
corresponds to channel (n * (n + 1) + m). Channels are normalized
with Schmidt Semi-Normalization (SN3D) with no Condon-Shortley phase
factor. In SN3D, the spherical harmonic of degree n and index m is
normalized according to
sqrt((2 - delta(m)) * ((l - m)! / (l + 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 254
(Section TODO), 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
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
Graczyk Expires November 25, 2016 [Page 3]
Internet-Draft Opus Ambisonics May 2016
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 |
+-------+---------------------------+
| 254 | 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>.
7.2. Informative References
[gerzon75]
Gerzon, M., "Ambisonics. Part one: General system
description", August 1975,
<http://www.michaelgerzonphotos.org.uk/articles/
Ambisonics%201.pdf>.
Graczyk Expires November 25, 2016 [Page 4]
Internet-Draft Opus Ambisonics May 2016
[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]