Subject: [codec] SDP mapping for > 2 channels in OPUS?

From: Harald Alvestrand <[email-masked]>
Date: Tue, 12 Feb 2019 21:50:43 +0100

Hi,

I wonder if there exists some specification for multichannel OPUS in SDP
- I have searched for it and missed it.

I note that RFC 8486 (ambisonics) doesn't say anything about SDP
considerations.

Harald

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 12 Feb 2019 17:41:11 -0500

Hi Harald,

There's no such spec yet. It probably would not be too hard to come up
with one, starting from the RFC7845 and RFC8486. That being said, I
think we would need to define a new payload and corresponding media
subtype to avoid compatibility problems with RFC7587.

Cheers,

	Jean-Marc

On 02/12/2019 03:50 PM, Harald Alvestrand wrote:
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Feb 2019 09:46:21 +0100

> subtype to avoid compatibility problems with RFC7587.

Thanks for confirming the absence of specs. The hackaround that Google
folks are trying is to send 5.1 as 3 OPUS stereo channels, which doesn't
make me particularly happy.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 13 Feb 2019 04:05:05 -0500

> make me particularly happy.

No, don't do that. I think the correct solution is to define a new
subtype (e.g. mc-opus) and then just specify an SDP version of the
multi-channel fields of the Ogg header.

For something like 5.1, that would basically mean transmitting the
channel order and coupling. That also means being able to use the
existing libopus surround encoder code, which will have *much* better
quality than explicitly breaking down 5.1 into 3 independent stereo
streams. Even ambisonics should work, though mapping family 3 may result
in a few kB of data in the SDP for the matrices when using 3rd order.

Cheers,

	Jean-Marc