<div dir="ltr">Hello,<br><br>We (Google) have been experimenting with configuration and adjustments to CELT-only Opus that give good results for compressing ambisonic audio signals [1]. Based on our results so far, we would like to use Opus to encode spatial audio. We hope to make it easy/possible to use libopus with other common tools and software modules (ffmpeg/libav in particular).<br><br>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.<div><br></div><div>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? </div><div><br></div><div>To summarize, should we add a new channel mapping for ambisonics? If not, what should we do?</div><div><br></div><div><br></div><div>[1] <a href="https://en.wikipedia.org/wiki/Ambisonics">https://en.wikipedia.org/wiki/Ambisonics</a><br>[2] <a href="https://tools.ietf.org/html/draft-ietf-codec-oggopus-14#section-5.1.1">https://tools.ietf.org/html/draft-ietf-codec-oggopus-14#section-5.1.1</a><br clear="all"><div><br></div><div><br></div><div class="gmail_signature"><div dir="ltr"><div>Thanks for your input,</div><div>Michael Graczyk</div></div></div>
</div></div>