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

[Jan Skoglund <[e-mail]>]

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:)