Subject: Re: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

From: Jan Skoglund <[email-masked]>
Date: Mon, 6 Aug 2018 19:43:30 +0200

Thanks for the comments! Our responses are inline below. A new version of
the draft has been uploaded.

Cheers,
Jan

> I see that Section 5.2 attempts to Update RFC 7845 to allow for the larger
> channel mapping information used by family 3, but I'm still a little
> unclear about what behavior I should expect from a pure RFC 7845
> implementation that receives a family 3 stream.  The actual mapping table
> would be "too long", but would the implementation detect that, or just note
> that it's an unrecognized family and generate silence?
>

This is the reason the changes below to 7845 are necessary. I.e., not
interpreting as channel mapping family 255, and instead “A
demuxer implementation encountering a 'channel mapping family'
value that it does not recognize SHOULD NOT attempt to decode the
packets“
I think that, depending on implementation, an old decoder would interpret a
Q15 value as an index and either, most likely, decide the value to be
invalid and not decode, or, if the index is lower-valued, decode the
streams according to the old rule
“If 'index' is less than 2*M, the output MUST be taken from
decoding stream ('index'/2) as stereo and selecting the left
channel if 'index' is even, and the right channel if 'index' is
odd. If 'index' is 2*M or larger, but less than 255, the output
MUST be taken from decoding stream ('index' - M) as mono. If
'index' is 255, the corresponding output channel MUST contain
pure silence”
So, it would either decode and play an unintended mixing, or not produce
audio at all.

> Section 1
>
> I think we want to say "by adding itesm with values 2 and 3" to the
> registry, since we add two entries and not a single superposed entry.
>

Changed.

> Section 3.1
>
> While I can deduce this from the list of allowed numbers of channels,
> noting that both ends of the range (0 and 14) are allowed values probably
> would add clarity.
>

It is now written as ”n = 0, 1, …, 14” , which we feel that most readers
will interpret such that all integers in the given range, including 0 and
14, are valid.

> Section 3.2
>
> Figure 3 could perhaps make it more clear that C and K are not necessarily
> equal.
>
>
We feel it's sufficiently clear in the figure, since the endpoints of the
vectors, and the rows and columns have specifically differently named
values (C and K). Added a mention in the paragraph.

> The term "side information" is used without definition (and is not used in
> RFC 7845).  Does this clause really add anything in comparison to if we
> just say "The matrix MUST be provided in the channel mapping table portion
> of the identification header, in place of a normal channel mapping table"?
>
>
Changed.

> Section 5.1
>
> Family 255 is specified in Section 5.1.1.3 of RFC 7845, not 5.1.1.4.
> (Also, the unqualified Section references should probably all be of the
> form Section N of RFC 7845, for the benefift of the HTML linkification
> tooling.)
>

Changed.

> Section 8
>
> Sometimes I see a "Description" column that allows for in-registry
> visibility that a range is for experimental usage.  I suppose it would not
> be too hard to also modify the registry structure to add such a thing, if
> you want.
>
>
Perhaps, but I’m afraid I wouldn’t know how to do that:)

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 Aug 2018 12:54:43 -0500

> So, it would either decode and play an unintended mixing, or not produce

Did you consider adding some text describing this situation to the
document?  I guess it is not strictly required from a protocol description
point of view, but would probably save readers some effort, when aggregated
over time.

> Perhaps, but I’m afraid I wouldn’t know how to do that:)

We can help you out if you do want to go down that route, but I don't think
anyone is insisting on it :)

Thanks,

Benjamin

---

From: Ralph Giles <[email-masked]>
Date: Thu, 9 Aug 2018 14:48:22 -0700

>>> be too hard to also modify the registry structure to add such a thing, if

I think this is a good idea. How about something like:

   +---------+---------------------------+---------------------------+
   | Value   | Description               | Reference                 |
   +---------+---------------------------+---------------------------+
   | 0       | Mono, L/R stereo          | RFC 7845, Section 5.1.1.1 |
   |         |                           |                           |
   | 1       | 1-8 channel surround      | RFC 7845, Section 5.1.1.2 |
   |         |                           |                           |
   | 2       | Ambisonic channel order   | This Document Section 3.1 |
   |         |                           |                           |
   | 3       | Ambisonic with mix matrix | This Document Section 3.2 |
   |         |                           |                           |
   | 240-254 | Experimental use          | This Document Section 6   |
   |         |                           |                           |
   | 255     | Discrete channels         | RFC 7845, Section 5.1.1.3 |
   +---------+---------------------------+---------------------------+

  -r