- From: Justin Uberti via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Feb 2021 18:42:59 +0000
- To: public-webrtc-logs@w3.org
There are a lot of moving parts here, so let me try to summarize. **Summary of the summary: proposed PR is good, but we can't implement it yet without some refactoring in Chrome.** 1. I overall agree with @henbos 's overall suggestion for the PR from https://docs.google.com/presentation/d/1-ZB5pjq0hTl4iNxGhIc3polH9wjCps2Uzqg7D4v1n14/edit#slide=id.gae53209dde_0_16. Just like the default is to send 1080p if that's the captured video resolution, sending stereo should be the default if that's the # of captured audio channels. 2. As @henbos also mentions, if the remote side indicates stereo=0, we should not send stereo. This protects old browsers, or conferencing servers that can only handle mono. 3. I don't think receiving browsers should need to turn off stereo via SDP. Same as how we don't provide a hook for receiving browsers to clamp what video resolution or audio sampling rate they receive. 4. The default channel count should probably be 1 to avoid unexpected changes to apps, and certainly be set to 2 if and only if the mic is in fact a stereo mic. This avoids wasting bits for no benefit. 5. The code in https://chromium.googlesource.com/external/webrtc/stable/talk/+/d3ecbb30dc2684653d61e8ec88a5382aecf62773/media/webrtc/webrtcvoiceengine.cc#1892 needs to change in a few ways: a. I don't think this particular code knows enough about the channel count to properly configure the encoder. It probably needs to be pushed down to a lower layer. **This will hurt audio quality when audio bitrate is specified until fixed, I think.** b. The decision it makes about the default audio bitrate, for mono vs stereo, also requires knowledge of the channel count. Accordingly it should probably be pushed down to a lower layer. **This will waste bits when audio bitrate is unspecified until fixed. ** c. Tracks can be replaced, so the encoder config needs to be re-evaluated whenever this happens. Ergo, it needs to happen somewhere other than setSendCodecs. 6. It probably makes sense at some point to allow send-side control of stereo via RTCRtpEncodingParameters, similar to ptime, dtx, etc. So that is another place that would need to get plumbed down to encoder config. -- GitHub Notification of comment by juberti Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/63#issuecomment-786118846 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 18:43:01 UTC