[opus] ambisonics formats and channel mappings

[Michael Graczyk]

Hi Marc,

On Sat, May 28, 2016 at 10:44 AM, Marc Lavallée <marc at hacklava.net> wrote:
> I subscribed because your discussion on the IETF draft ("Ambisonics in
> an Ogg Opus Container") was mentioned on the sursound list.

Thanks for your interest! Please feel free to voice your support for this
work on the codec at ietf.org mailing list. The more support the better.

> I tried Opus for ambisonics more than a year ago. It does works with
> uncoupled channels (I had to patch the encoder). I don't know what else
> could be done to optimize support for ambisonics, as I'm not a codec
> expert.

I agree. We are decoupling channels and setting the bitrate allocation to
give progressively fewer bits to higher order channels. We have also
explored dynamic interchannel bitrate allocations based on a worst case
analysis (over all head rotations) of rendered binaural masking levels. We
did not find dynamic allocations to improve subjective quality enough to
explore that potential encoder optimization in depth.

> The allowed number of channels should not be restrained to a list like
> 1,4,9,16,etc, because ambisonics can support mixed-order schemes.

The way the Ogg headers work, it is possible to send 2,3,5,etc channels by
sending 4,4,9 respectively, and setting the channel index to 255 for those
channels which are not included ({2,3}, {3}, {5,6,7,8} in this example). We
reserved actual channel number "C" == 2,3,5,etc so that if mixed order
schemes with different basis functions become common in the future, we
could add them without breaking existing implementations.

> The Ambix format was adopted by Google, but it's a new format;
> the FuMa format is widely used and could easily be supported as well.
> https://en.wikipedia.org/wiki/Ambisonic_data_exchange_formats

Although FuMa conventions are commonly used, the ambix conventions of ACN
channel ordering and SN3D normalization are increasingly becoming the norm.
FuMa generally uses maxN normalization, which becomes complicated for
fourth order and above. I decided to require ACN and SN3D to limit
fracturing and potential confusion.

> Down-mixing to stereo is a sort of ambisonic decoding; it is simple and
> could be included in the Opus decoder. But decoding to binaural or 5.1
> is not trivial. Usually, decoding ambisonics is the job of a dedicated
> decoder, and depends on the role, number and positions of output
> channels. so I don't think that the Opus decoder should be involved,
> unless approximate methods could be considered good enough as default.

I included downmixing to stereo because it is simple and there is a clear
right way to do it. For 5.1 or other surround setups, there is no obvious
best solution so I did not include those downmixing matrices. The purpose
of this downmixing matrix is to give guidelines for what to do in the
likely case that an ambisonic Opus stream is encountered, but no ambisonic
decoder is available, In that case, the best thing to do (arguably besides
giving an error) is to decode with the provided downmixing mixing matrix.
Are you suggesting we exclude the stereo downmixing matrix?

-- 

Thanks,
Michael Graczyk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20160528/ff8678fb/attachment.html>