Open henbos opened 1 week ago
@jan-ivar @youennf @alessiob
Ah that old issue... it does seem to be in favor of defaulting to stereo=1 but allowing mono via channelCount:1 constraints.
However it does not capture the nuance between Proposal A or Proposal B here. For example, even if we encode mono or stereo depending on the local track's channelCount, there's a separate question regarding if when we decode this signal if the remote track's channelCount would be 1 or 2? According to the audio experts, there's "no harm" in having channelCount be 2 on the remote track regardless if the signal being decoded was mono or stereo. The benefit of defaulting to 2 is less complexity and less risk of glitches due to reconfiguring
Action items:
Filed #3011 for channelCount in settings
Opus is a codec that is capable of both mono and stereo.
In SDP, you can specify "stereo=X" to say what your receiver preference is, but importantly:
Today in Chrome, you get mono (track.getSettings().channelCount == 1) by default, but if "stereo=1" is used you get stereo (channelCount == 2). Importantly, the decoder will downmix or upmix to match the desired output (e.g. if stereo is used you will get a stereo track even if the input on the wire is mono).
We would like to support stereo without SDP munging. The question is what is the expected behavior?
While I originally thought 2) was more intuitive, I'm told that Firefox does 1). It also turns out that the audio team prefers to do 1) to avoid some complexity and to reduce the risk of audio glitches due to reconfiguring the decoder in the event that the signal switches back and forth on the fly (use case: virtual audio ssrc and speaker switching between mono and stereo signals, but this is also achievable with replaceTrack in a WPT).
Proposal A: Mandate "always stereo" for stereo codecs. Proposal B: Mandate dynamically switching between mono and stereo. Proposal C: Mandate nothing; it is up to the user agent.