Re: [codec] Ambisonics in an Ogg Opus Container

Michael Graczyk <mgraczyk@google.com> Tue, 31 May 2016 18:38 UTC

Return-Path: <mgraczyk@google.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F4612D5A1 for <codec@ietfa.amsl.com>; Tue, 31 May 2016 11:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level:
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4spp4k3M7vZD for <codec@ietfa.amsl.com>; Tue, 31 May 2016 11:38:39 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC6912D562 for <codec@ietf.org>; Tue, 31 May 2016 11:38:38 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id r140so273798188vkf.0 for <codec@ietf.org>; Tue, 31 May 2016 11:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=goG907cjF9tYEZX39rxX2mCr3ln44aY63UGmAMFGsZQ=; b=oTw2WW9GStgYH3pxGT3D3WRfzC7vNyMIQuJNfC+hylImSjdGPpppvuKZKvKODsQwhs GgWF6VCz6C1RBa8qJlihnY5Ul2CLHKa+N2gboN/yXN2+3yYAW/TrV32AbTt5ZIQ1r3fp NFGVhqbM4seJIm432Z3xomh2oKCgBO3oeMaNpm3ciEq2E7Y6n5EMuJjhTw6Nx3+15gs3 pVr65W+c6OUrU4mEhNB3F410cRrl/9NFSQtg4bHgALdDfl8+aAqmkjqn5qLkTIX8/vWd ed3yWbCisYyEMg8PXIg/yrEqwHT0UP5LrXPy2TfjKkCpXzsE+ivFmfJHopPWfs7wgqqg kXnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=goG907cjF9tYEZX39rxX2mCr3ln44aY63UGmAMFGsZQ=; b=L+cbnwolYmgua6T5yB9ap8gL7MKUmPRiX81sbCZyrCM85qUamuf869Nj1SKXJG8xa9 +RAr5+UFOt9/ydpA2UdEbJqh7AuDmVbTcSrNvHvRu8HzttFQYkHFryBnCtTQOoip0Pha 8nuXwVZe8BUWZ+5gS9KiL2URpGBMAnPFwc4kQavCev4kXTlTgkFH2JOGlDi3BF4y/YoJ wermI5Ren+JZaFhFH4Mb+BrNl36IFa12E2Ppyxa6+0EjP3zUXWKs5TA34dAE9Pc+0EHI 1bC1tZkcyYT57Oqy82tjLOvkrIHlhgYboU4d6y5KReiVa68qDQAbIqlnvrYQOfQZp2ch RTWQ==
X-Gm-Message-State: ALyK8tJUKDb2ejy/BqwAJDm8xt+s62avgMfrw8uQpvCK3BmXrw7Yxr/tvacScxKYQfwotZL8h6fQ4Rtkw+DVOGKC
X-Received: by 10.159.41.167 with SMTP id s36mr13629300uas.109.1464719917802; Tue, 31 May 2016 11:38:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.71.210 with HTTP; Tue, 31 May 2016 11:38:37 -0700 (PDT)
In-Reply-To: <20160529104233.1bfbda09@telecino>
References: <CABcu6-jN2gC0FRm5Vu6CmT5=yMdJr1WSaJJ_-FOXffw8bWjc_g@mail.gmail.com> <574887A3.30003@xiph.org> <CAMdZqKEer5GxSuOdHwY49=Pe_xy_7OnE-RR3Wgc2+C7=g3La1Q@mail.gmail.com> <20160529104233.1bfbda09@telecino>
From: Michael Graczyk <mgraczyk@google.com>
Date: Tue, 31 May 2016 11:38:37 -0700
Message-ID: <CABcu6-g3PiaofwuUwUgbXeXC1NyfZ-GBy9cqCdz47UZc_Pr-Fg@mail.gmail.com>
To: =?UTF-8?Q?Marc_Lavall=C3=A9e?= <marc@hacklava.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/eYJdSf0THCCTWm-JvZEAKGgBwy8>
Cc: codec@ietf.org
Subject: Re: [codec] Ambisonics in an Ogg Opus Container
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 18:38:41 -0000

Thanks Jean-Baptiste, Mark, and Marc for your comments.
Also thank you Ron for your support.

On Sat, May 28, 2016 at 1:47 AM, Jean-Baptiste Kempf <jb@videolan.org> wrote:
> Sorry, what I meant is that it would be nice that the info from this RFC
> carries the same kind of information than SA3D, so that a player like
> VLC only need to have one identical filter to process them, post
> decoder.

In lieu of the SA3D box's explicit metadata, this draft requires that
the ambisonic streams use ACN channel ordering and SN3D normalization.
The channel count and channel mapping are contained in the Ogg
identification header. I believe the only thing missing here is the
SA3D box's "ambisonic_type" field. I would like to require periphonic
(full 3D) ambisonics in this draft. I added the word "periphonic" to
section 3.1.



On Sat, May 28, 2016 at 10:35 PM, Mark Harris <mark.hsj@gmail.com> wrote:
> In section 3.2 perhaps it should be clarified that the first ambisonic
> channel (W) may be used directly for mono playback, particularly if
> streams with channel mapping family 2 might only have one channel.

I added a short paragraph to the end of 3.2. What do you think?

> Also there is a typo "definied" in section 4.

Thanks, fixed



On Sun, May 29, 2016 at 7:42 AM, Marc Lavallée <marc@hacklava.net> wrote:
> I would suggest to not include decoding of Ambisonics streams in the
> Opus decoders. Exceptions would be decoding/down-mixing to mono
> and stereo, as defaults for compatibility reasons, but in a carefully
> unobtrusive way; users of Opus for Ambisonics should easily have access
> to all channels, even if the Opus decoder (and the system) wants to
> "help" them.

Right. I do not want to include ambisonic decoding in the Opus
decoder. I reworded section 3.2 to make it clear that downmixing MAY
be done by Ogg Opus players, not decoders.

> Support for mixed-order is important too, mostly for horizontal-only ...

The draft allows users to send mixed-order ambisonics

> Normalisation is not the responsibility of a codec. It is used for
> Ambisonics format conversion (ex: A to B, FuMa to Ambix). That said,
> gain factors could be included to maximize dynamics, but it is
> unrelated to Ambisonics.

Right. Just to be clear, the Opus encoder and decoder do not do the
normalization, nor do they _need_ to know anything about it. The
encoder could perform masking computations that require knowledge of
the normalization, but the main purpose of including it in this draft
is to give Opus ambisonc streams an unambiguous semantic meaning.

When an Ogg Opus ambisonic player receives a stream with channel
mapping 2, that player needs to know the normalization. As written,
this draft promises that the stream would be SN3D normalized.