[opus] Channel Mapping Family for Ambisonics

[Michael Graczyk]

On Tue, Apr 19, 2016 at 10:20 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:
> 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.

That makes sense. For now I will focus on encoder only changes. If an
adaptive pre/post transform had to send side information, would it
also need to go through the IETF process?

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

Great, I'll write up something precise and send it out.

On Tue, Apr 19, 2016 at 10:19 AM, Timothy B. Terriberry
<tterribe at xiph.org> wrote:
> I'm assuming that the pre/post transform would be something like a
> decorrelating transform on the channels, and the actual core parts of Opus
> would not change. For that, I think an extra channel mapping is a reasonable
> approach, without requiring a new version number.
>
> We've talked about using the Opus padding as a place to store extra side
> information in the past. I haven't thought deeply about the trade-offs
> between that and other approaches, like using an invalid TOC sequence to add
> additional packet data, as we did with the MPEG TS embedding
> (<https://wiki.xiph.org/OpusTS>).
>
> The difficulty with padding is that it prevents transparent repacketization,
> because the padding occurs once per Opus packet, while side information is
> typically required once per Opus frame (of which there can be several in an
> Opus packet). The invalid TOC sequence approach would put the data in its
> own Opus packet entirely, which might have other drawbacks.

Thanks for the link. It looks like that embedding carries metadata.
Would it be possible to include something like residual coded
transform coefficients that way?


> That seems like the best approach. See also
> <https://www.iana.org/assignments/opus-channel-mapping-families/opus-channel-mapping-families.xhtml>.
> As long as there is a specification somewhere (this does not have to be an
> IETF specification, though it could be), we can add it to this list.

Great, I will use these as a guide to writing a more precise
description of the ambisonic mapping.


-- 

Thanks,
Michael Graczyk