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
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
