[codec] Eric Rescorla's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-codec-ambisonics-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-codec-ambisonics/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3213



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


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.

This is outside the DISCUSS criteria, but I would strongly recommend
you split this into a separate document.


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?


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.


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