[codec] IANA Opus mapping comments on draft-ietf-codec-ambisonics-08

[Ralph Giles <[e-mail]>]

Hi,

I was asked to look at the ambisonics draft as a designated expert for 
the Opus Channel Mapping Families IANA registry.

First, thanks for writing this up. It's exciting to see ambisonic 
support for the Opus codec!

Channel mapping family 2 looks good to me. The change is documented in a 
proposed RFC. It defines the allowed number of channels, re-uses the 
channel mapping table from Ogg Opus RFC 7845, so I don't see 
interoperability issues. The draft explains how to map decoded channels 
to the correct ambisonic order and degree. I believe that fulfills the 
specification requirement.

The actual definition of the spherical harmonic expansion of the sound 
field is a conference paper. The paper appears to be publicly available. 
But, since this is a normative reference, it might be nice to reproduce 
at least a sketch of the relevant functions within the draft in case 
that reference becomes harder to obtain. It also wasn't clear to me, as 
someone without specific ambisonic knowledge what the annotations on the 
definition in the reference meant. Of course it can be painful to 
include complex equations in an RFC.


For mapping family 3, I'm concerned by the way the matrix is signaled.

You say the mixing matrix is "stored column-wise." I assume this means 
the order of the coefficients in the file is D11, D21, ..., DC1, D12, 
D22, ..., D1K, D2K, ..., DCK. Is that correct? Since matrix 
representation conventions vary, I suggest being more explicit here,
perhaps by listing a few coefficients in figure 4.

As you note at the end of section 3.2, the identification header must 
fit within a single page as described the Ogg Opus RFC 7845. This is 
also in the Ogg Format RFC 3533 (section 4, third paragraph). Violating 
this constraint will definitely cause interoperability problems. I'd 
like to see the language about this strengthened to a MUST limit on the 
packet size and some guidance given about maximum order and channel 
indexes for common configurations. Section 3.3 should be updated to 
mention this as well. It would be an easy thing for implementors to 
overlook.

As you noted in your response to Eric Rescorla's comments, replacing the 
RFC 7845 channel mapping table with the mixing matrix entries means that 
a decoder based solely on that RFC could either produce a random mix of 
of the ambisonic channels, or reject the header as invalid, depending on 
how the mixing coefficients match up with the available decoded streams 
when interpreted as bytes.

However, the RFC 7845 channel mapping table is only 'C' octets long, the 
length of half a row of the mixing matrix. It seems to me encoders could 
insert a compatibility table before the matrix coefficients without 
adding much to the encapsulation overhead or limiting the mixing options 
much. Was this considered by the working group?

Such a table could be all 255 values, to indicate no output, but 
probably SHOULD consist of a 1:1 mapping, with values 0,1,..,C-1. That 
way something like Digital Audio Workstation software written just 
against RFC 7845 could still load the coded tracks, even if the mix and 
interpretation as ambisonic signals is lost. That kind of compatibility 
was the intent of Section 5.1.1.3 of RFC 7845.

Decoders still MAY reject the stream because they don't recognize the 
channel mapping family field, or because they think the id header is too 
large. Players still SHOULD NOT play it based just on an unrecognized 
mapping family field.

If you want to completely block incompatible decoders, you could also 
bump the 'version' field in the id header.


Reserving mapping family values 240...254 for experimental use seems 
reasonable to me. I don't foresee much pressure on namespace allocation, 
and the number of reserved entries is appropriate.

You could reference the "experimental use" policy in Section 4.1 of RFC 
5226 here.


I don't see an Implementation Status section (as recommended by RFC 
6982). Are there multiple implementations of this draft? Test vectors?


I hope this review is helpful,
Ralph