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

[Jan Skoglund <[e-mail]>]

Hey,

Thanks for the comments!



> 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.
>

Changed to the more prevalent notion "column-major order"

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.
>

Section 3,2 changed to MUST for 12th order, if full order is used. This is
also repeated in Section 3.3.


> 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?
>

This has not been considered. The structure proposed in the draft has been
implemented into Opus.


> I don't see an Implementation Status section (as recommended by RFC
> 6982). Are there multiple implementations of this draft? Test vectors?
>
>
This draft has been implemented and is fully available in the official Opus
repository. An experimental flag was recently removed. No specific test
vectors have been produced.


Cheers,
Jan