- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Feb 2021 09:07:12 +0000
- To: public-webrtc-logs@w3.org
@perahgren found [this](https://tools.ietf.org/html/rfc7587) yesterday: > The "stereo" parameter is a unidirectional receive-only parameter. > When sending to a single destination, a sender MUST NOT use stereo > when "stereo" is 0. Gateways or senders that are sending the same > encoded audio to multiple destinations SHOULD NOT use stereo when > "stereo" is 0, as this would lead to inefficient use of network > resources. If the browser is the sender, this would change the "stereo=0" from SHOULD NOT to MUST NOT send stereo, since RTCPeerConnection only sends to a single destination. This does not affect what a sensible implementation does. If the browser is the receiver, nothing changes, we still have to be prepared to receive stereo in case we are talking to a gateway. I'm still in favor of stereo=1 being the default because then "you send what you have" and don't need to worry about additional APIs to control SDP. It's then up to the application to agree on capture channel count, similar to how it is today up to the application to agree on capture resolution and frame rate. However the channel count's default has been raised as a concern to move forward. If we would accidentally have two channels then we may accidentally cause regressions. We may want to discuss https://github.com/w3c/mediacapture-main/issues/775 before merging a PR here? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/63#issuecomment-785738574 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 25 February 2021 09:07:15 UTC