Open Bug 1696519 Opened 3 years ago Updated 3 years ago

Is Firefox upsampling mono to stereo over RTCPeerConnection?

Categories

(Core :: WebRTC, defect)

defect

Tracking

()

People

(Reporter: jib, Unassigned, NeedInfo)

References

Details

Attachments

(1 file)

Attached image image.png

+++ This bug was initially created as a clone of Bug #1696508 +++

STRs (ideal):

  1. Make sure default mic is mono (MBP mic)
  2. Open https://jsfiddle.net/jib1/0pcdfmky/ and click Go (and hit Allow in any prompt).

Expected results:

  • Local shows mono, remote shows mono

Actual results:

  • Local shows mono, remote shows stereo

I haven't examined whether the upsampling happens sender side (wasting bandwidth) or receiver side (even a web audio quirk?), but I've confirmed Firefox is capable of sending stereo from a stereo source.

No longer depends on: 1696508
See Also: → 1696508

For Opus, yes. But this seems to also go through negotiation. And if stereo was negotiated, can we really send mono? Can we even change on the fly? Because the channel count could change on the fly.

Jan-Ivar would you mind setting the priority and severity flags?

Flags: needinfo?(jib)

(In reply to Andreas Pehrson [:pehrsons] from comment #1)

And if stereo was negotiated, can we really send mono?

I believe so. My understanding from w3c/webrtc-extensions#63 (comment) is that stereo=1 merely signals to a sender that the receiver is able to receive stereo. So the only violation would be sending stereo to a receiver that signaled stereo=0.

Can we even change on the fly? Because the channel count could change on the fly.

I would think yes, modulo the restriction above.

As to urgency of fixing this, I'll defer to Nils.

Flags: needinfo?(jib) → needinfo?(drno)

FWIW the negotiated value gets translated to a codec description here, which in turn is translated to an AudioSendStream::Config SdpAudioFormat parameter here, which is parsed for opus here. If stereo=1 is set there that will force the encoder to do stereo.

The better solution to this seems to be to make upstream recognize that both mono and stereo are allowed with stereo=1 (based on comment 3).

We could also detect such runtime changes ourselves and reconfigure the send stream (recreating the encoder) but that would make the actual channel count changes on the wire apply out-of-band to the channel count changes seen by the sender.

With bug 1654112 it actually looks like upstream can only handle 48kHz stereo for opus. Not sure if I'm missing something. Needs to be looked into.

Flags: needinfo?(drno) → needinfo?(jib)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: