Re: [codec] Ambisonics in an Ogg Opus Container

[Michael Graczyk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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.