<p dir="ltr">Hi Marc,<br></p>
<p dir="ltr">On Sat, May 28, 2016 at 10:44 AM, Marc Lavallée <<a href="mailto:marc@hacklava.net">marc@hacklava.net</a>> wrote:<br>
> I subscribed because your discussion on the IETF draft ("Ambisonics in<br>
> an Ogg Opus Container") was mentioned on the sursound list.</p>
<p dir="ltr">Thanks for your interest! Please feel free to voice your support for this work on the <a href="mailto:codec@ietf.org">codec@ietf.org</a> mailing list. The more support the better.</p>
<p dir="ltr">> I tried Opus for ambisonics more than a year ago. It does works with<br>
> uncoupled channels (I had to patch the encoder). I don't know what else<br>
> could be done to optimize support for ambisonics, as I'm not a codec<br>
> expert.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> The allowed number of channels should not be restrained to a list like<br>
> 1,4,9,16,etc, because ambisonics can support mixed-order schemes.</p>
<p dir="ltr">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. </p>
<p dir="ltr">> The Ambix format was adopted by Google, but it's a new format;<br>
> the FuMa format is widely used and could easily be supported as well.<br>
> <a href="https://en.wikipedia.org/wiki/Ambisonic_data_exchange_formats">https://en.wikipedia.org/wiki/Ambisonic_data_exchange_formats</a></p>
<p dir="ltr">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. </p>
<p dir="ltr">> Down-mixing to stereo is a sort of ambisonic decoding; it is simple and<br>
> could be included in the Opus decoder. But decoding to binaural or 5.1<br>
> is not trivial. Usually, decoding ambisonics is the job of a dedicated<br>
> decoder, and depends on the role, number and positions of output<br>
> channels. so I don't think that the Opus decoder should be involved,<br>
> unless approximate methods could be considered good enough as default.</p>
<p dir="ltr">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?<br><br></p>
<p dir="ltr">-- </p>
<p dir="ltr">Thanks,<br>
Michael Graczyk</p>