- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Feb 2021 08:04:11 +0000
- To: public-webrtc-logs@w3.org
> 1. the Opus encoder will be initialized to transmit stereo regardless of the # of channels, which probably results in worse efficiency and sound quality for the selected bitrate
and
> @juberti Wouldn't that show up in a Chrome←→Firefox p2p call today then?
Then it sounds like the compatibility problem already existed ever since Chrome initially shipped stereo. So we need to fix this regardless of how we decide to control stereo going forward.
To me I think it sounds like the proposed PR still makes sense as-is, but that code like https://chromium.googlesource.com/external/webrtc/stable/talk/+/d3ecbb30dc2684653d61e8ec88a5382aecf62773/media/webrtc/webrtcvoiceengine.cc#1892 need to be update so that the number of channels gets reconfigured to be the minimum of track channels and channels negotiated, and to trigger the possibility of reconfiguring the encoder on replaceTrack() if number of channels change.
Does this make sense to everybody? @juberti @perahgren
> To test Chrome, I used an in-content device picker to pick my BRIO: I get channelCount: 1 with {audio: true} in M88, but channelCount: 2 in M90. Did the default change recently?
@guidou Do you know?
--
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/63#issuecomment-784878491 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 February 2021 08:04:14 UTC