Subject: [codec] Comments on draft-ietf-codec-ambisonics-01

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 17 Feb 2017 16:57:15 -0500

Hi Jan,

Here's some comments based on my review of the ambisonics draft:

3.  Ambisonics With Ogg Opus

>    Ambisonics MAY be encapsulated in the Ogg format by encoding with the

I would suggest replacing the normative MAY by just "can"

3.1.  Channel Mapping Family 2

>    This channel mapping uses the same channel mapping table format used
>    by channel mapping families 1 and 255.

I would suggest saying "mapping family 1" rather than "mapping families
1 and 255" since otherwise, you have families 2 referencing itself.
Also, we don't know what families 4 and up will look like.

3.2.  Channel Mapping Family 3

I would suggest removing the "Output Channel Numbering" field because it
is fully equivalent to simply permuting lines of the matrix. Also, I
believe that the size of the matrix was meant to be "32*(N+M)*C bits"
rather than "32*N*C bits".

About the matrix -- and as previously discussed privately -- I think it
should probably be stored as 16-bit integers in Q15 format. If any
global scaling is ever required, then the "output gain" field can always
be used.

>    Note that [RFC7845] specifies that the identification header cannot
>    exceed one "page", which is 65,025 octets.  This sets a practical
>    maximum ambisonic order of 10, if full order is utilized and the
>    number of coded streams is the same as the ambisonic order plus the
>    two non-diegetic channels.

This text is unclear about whether partial order 11 is allowed. I have
no strong opinion on the subject, but think it should be clarified.

Cheers,

	Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 18 Feb 2017 01:02:56 -0500

> rather than "32*N*C bits".

So based further discussions off-list with Mark and Tim, it seems like
there's a few issues with RFC7845 that would need to be addressed:

5.1.1.  Channel Mapping

>    The order and meaning of these
>    channels are defined by a channel mapping, which consists of the
>    'channel mapping family' octet and, for channel mapping families
>    other than family 0, a 'channel mapping table', as illustrated
>    in Figure 3.

This seems to impose that all other families have a channel mapping
table, which as I pointed out for family 3, isn't always appropriate. So
I think this draft should update RFC7845 to state that only the "Stream
Count" and "Coupled Count" fields are required for all families greater
than 0. The channel mapping table isn't required unless a particular
family defines it.

5.1.1.4.  Undefined Channel Mappings

>    The remaining channel mapping families (2...254) are reserved.  A
>    demuxer implementation encountering a reserved 'channel mapping
>    family' value SHOULD act as though the value is 255.

If we change the channel mapping table to not be defined for all
families, then we would need to update this paragraph to state that
undefined families should be treated as 255, but assuming an "identity
ordering" rather than attempting to read a mapping table that may not
actually exist.

I also think we should officially mark families 250-254 (or maybe a
larger range?) as reserved for experimental features that have yet to be
assigned a permanent family number by IANA. For example, the Opus code
currently uses 254 and 253 to handle what would be families 2 and 3 ones
this draft becomes RFC.

Mark, Tim, did I forget anything?

Cheers,

	Jean-Marc