[AVTCORE] Comments on draft-shin-avtcore-rtp-multi-opus-01

["Timothy B. Terriberry" <[e-mail]>]

Hi Shun,

Thanks again for working on this and bringing it to avtcore.

To follow up on the discussion in the room, if you are unsure about the 
purpose of mapping families in RFC 7845, I think the easiest way to 
think about them is that they are used to assign a _meaning_ to the 
audio data transmitted on the wire. They do not affect the format of the 
RTP payload itself (beyond establishing the number of streams and number 
of channels those get decoded into), but they tell you what those 
channels are. This can be simple speaker positions (mapping families 0 
and 1), or spherical harmonics as in Ambisonics (mapping families 2 and 
3, see RFC 8486), or something that must be agreed upon externally 
(mapping family 255). I think that even if this draft limits itself to 
mapping family 1, we should have a plan for how additional families 
could be supported. That said, I agree with Jean-Marc that adding 
support for mapping families 2 and 255 should be relatively painless.

I also had a few more pedantic comments on your draft that I thought 
were better suited to the mailing list than our limited meeting time. I 
don't think any of these should block working group adoption of the 
draft (and I would be in support of adoption).

1) In section 6.1.3, are all of the fields listed there mandatory? Can I 
leave out channel_mapping for 1 or 2 output channels with one stream 
(i.e., the equivalent of mapping family 0)?

2) RFC 7845 imposes some implicit limitations on the values of the 
num_streams, coupled_streams, and channel_mapping fields. E.g., because 
they are encoded in octets and treated as unsigned, they cannot be 
negative or exceed 255. Encoding them as text in SDP does not enforce 
those limitations. Should this draft make them explicit?

There are also some explicit limitations are tied to the mapping family, 
e.g., no more than 8 output channels for mapping family 1. This draft 
never discusses individual mapping families, so it may not be clear 
which of those limitations are intended to apply.

3) It is probably not a great idea to define channel_mapping with a 
normative reference to third-party source code (I tried visiting the 
libwebrtc link, but it just served me a blank page... probably that is 
some issue on my end, but I think it illustrates the point). Is this 
just RFC 7845's channel mapping as a comma-separated list? Does it 
support silence channels (255)?

4) For the SHOULD NOT in Section 7, what does it mean for the answerer 
to support the offered configuration? The ability to parse the format? 
The ability to decode or record it? The ability to render to some number 
(>2) of speakers?

What reasons would someone have for silently down-converting to stereo 
anyway (i.e., why is this SHOULD NOT instead of MUST NOT)?

5) What reasons would someone have for not including a stereo 
alternative (again, why is this a SHOULD and not a MUST)?