[opus] Channel Mapping Family for Ambisonics

[Jean-Marc Valin]

On 04/17/2016 10:29 PM, Michael Graczyk wrote:
> Based on my reading of the libopus code and the IETF spec, it seems one
> reasonable option would be to add a new "Channel Mapping Family" for
> ambisonic audio [2]. The mapping family would indicate to the decoder
> that the audio is ambisonics and the channel mapping array would
> indicate which ambisonic channel (W, X, Y, etc) corresponds to which
> coded stream. This representation is analogous to Opus headers for
> surround sound.

Right. This shouldn't be very hard, and mostly just involve deciding on
which order you want to name the channels.

> There are a few caveats though. Although we believe we can achieve good
> compression at first without changing the bitstream or the decoder, we
> would like the flexibility to potentially modify both if potential
> improvements are compelling enough to impress you (specifically, we have
> a pre/post transform that would require sending compressible side
> information). Would changing either the bitstream or encoder require
> adding yet another channel mapping? Would it require a new Opus version
> number? 

So the important question is "can an existing decoder (assuming it knows
about the ambisonics channel mapping) decode your file?". If the answer
is yes, then it's just an encoder-only change and it's easy to add to
the code base. If the answer is no, then it's actually a bitstream
change. A bitstream change would either have to go through the IETF
process or (if it's just a pre/post transform) at the very least have a
formal definition somewhere. In either case, that's a lot more work than
just a new mapping or even an encoder-only change.

> To summarize, should we add a new channel mapping for ambisonics? If
> not, what should we do?

The first step is definitely to add a new channel mapping for ambisonics.

Cheers,

	Jean-Marc