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

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

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.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Aug 2018 12:33:59 -0700

On Mon, Aug 6, 2018 at 10:33 AM, Jan Skoglund <[email-masked]> wrote:

> accommodate the proposed channel mapping families in this draft.
>

Sorry, I don't understand. Why did they need to be revised to have this
change?

The authors of RFC 7845 and RFC 6716 suggested that the necessary updates
> to RFC 7845 should be included in this draft.
>

I understand, but my point is that people are likely to ignore this draft
if they don't care about ambisonics and thereby miss out on a relevant
information. In any case, I'll defer to the WG and AD.

S 5.1.
>> >      Figure 6: Stereo Downmixing Matrix for Channel Mapping Family 2
>> and 3

Sorry, I'm not following. Is your point that previously it would have
misdecoded it and now it will just refuse to play? That's a reasonable
design choice, but it seems like it was always present in this design, so
why does it need to change?

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

All right.

-Ekr

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 13 Aug 2018 14:24:59 -0400

>     This is the reason the changes below to 7845 are necessary. I.e.,
>     not interpreting as channel mapping family 255, and instead “A
> design choice, but it seems like it was always present in this design,
> so why does it need to change?

Basically, RFC 7845 didn't consider the possibility of new mappings
requiring some kind of transformation (in the case of family 3, a matrix
multiply) between the Opus streams and what the decoder needs to output.
Once you consider that, then it makes no sense to output the "raw"
decoded streams as if it were a family 255.

Cheers,

	Jean-Marc

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Aug 2018 15:51:55 -0500

> On Aug 10, 2018, at 2:33 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> S 5.2.
> >         packets and SHOULD NOT use any information except for the first 19
> These paragraphs are updates to RFC 7845, which needed to be revised to accommodate the proposed channel mapping families in this draft.
> 
> Sorry, I don't understand. Why did they need to be revised to have this change?
> 
> 
> The authors of RFC 7845 and RFC 6716 suggested that the necessary updates to RFC 7845 should be included in this draft.
> 
> I understand, but my point is that people are likely to ignore this draft if they don't care about ambisonics and thereby miss out on a relevant information. In any case, I'll defer to the WG and AD.
> 

Closing the loop on this point:

We have commonly put updates to RFCs in the documents that create the need for the updates, even if the update is generally applicable. We have the “Updates/Updated by” relationships to track this sort of thing.

I am sympathetic to Ekr’s argument, in that I agree it would be more convenient for the reader to find the update in a smaller, dedicated draft. But at this point in the process, I highly doubt the wg has the energy to do that sort of restructuring. Therefore I am inclined to leave this the way it is.

Thanks,

Ben.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Aug 2018 15:29:58 -0700

It's a comment on my side, so I leave it to your discretion

On Fri, Aug 24, 2018 at 1:51 PM, Ben Campbell <[email-masked]> wrote:

> > The authors of RFC 7845 and RFC 6716 suggested that the necessary
> updates to RFC 7845 should be included in this draft.
> >
> > I understand, but my point is that people are likely to ignore this
> draft if they don't care about ambisonics and thereby miss out on a
> relevant information. In any case, I'll defer to the WG and AD.
> >
>
> We have commonly put updates to RFCs in the documents that create the need
> for the updates, even if the update is generally applicable. We have the
> “Updates/Updated by” relationships to track this sort of thing.
>
> I am sympathetic to Ekr’s argument, in that I agree it would be more
> convenient for the reader to find the update in a smaller, dedicated draft.
> But at this point in the process, I highly doubt the wg has the energy to
> do that sort of restructuring. Therefore I am inclined to leave this the
> way it is.
>
> Thanks,
>
> Ben.
>
>
>
>
>