Re: [codec] Eric Rescorla'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 doc has been uploaded.

Cheers,
Jan


> S 3.2.
> >                                                        | Stream Count  |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        | Coupled Count | Demixing Matrix                               :
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >          Figure 4: Channel Mapping Table for Channel Mapping Family 3
>
> Are you saying I MUST use family 3?
>
>
No, we say that if you use family 3 you MUST provide a matrix in the
channel mapping table.


> S 5.2.
> >         The remaining channel mapping families (2...254) are reserved.  A
> >         demuxer implementation encountering a 'channel mapping family'
> >         value that it does not recognize SHOULD NOT attempt to decode the
> >         packets and SHOULD NOT use any information except for the first
> 19
> >         octets of the ID header packet (Fig. 2) and the comment header
> >         (Fig. 10).
>
> What is the rationale for this change? Also, why are you doing it in
> this document? This seems like it's going to be extremely hard for
> implementors to find in future.
>

These paragraphs are updates to RFC 7845, which needed to be revised to
accommodate the proposed channel mapping families in this draft. The
authors of RFC 7845 and RFC 6716 suggested that the necessary updates to
RFC 7845 should be included in this draft.



> COMMENTS
> S 3.2.
> >      whether or not there is a separate non-diegetic stereo stream.  This
> >      corresponds to periphonic ambisonics from zeroth to fourteenth order
> >      plus potentially two channels of non-diegetic stereo.  Explicitly
> the
> >      allowed number of channels are 1, 3, 4, 6, 9, 11, 16, 18, 25, 27,
> 36,
> >      38, 49, 51, 64, 66, 81, 83, 100, 102, 121, 123, 144, 146, 169, 171,
> >      196, 198, 225, and 227.
>
> This seems like the same graf as in 3.1, so perhaps merge these?
>

Merged and moved to a separate sub-section.


> S 3.2.
> >
> >                 Figure 3: Demixing in Channel Mapping Family 3
> >
> >      The matrix MUST be provided as side information and MUST be stored
> in
> >      the channel mapping table part of the identification header, c.f.
> >      section 5.1.1 in [RFC7845].  The matrix replaces the need for a
>
> I don't think you want "c.f." here, b/c "cf." means "compare". I
> suspect you just want "see". Also, there's no period between c and f.
>

Changed.


>
> S 5.1.
> >      Figure 6: Stereo Downmixing Matrix for Channel Mapping Family 2 and
> 3
> >             - Ambisonic Channels Plus a Non-diegetic Stereo Stream
> >
> >   5.  Updates to RFC 7845
> >
> >   5.1.  Format of the Channel Mapping Table
>
> What are the interop implications of this? I.e., is a file formatted
> according to this document at all playable with an existing Ogg
> decoder? If not, perhaps say so
>

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.