1043543 - Respect Opus fmtp parameter maxplaybackrate

Status: NEW

(Core :: WebRTC: Signaling, defect, P5)

Description

[Timothy B. Terriberry (:derf)]

For sendonly or sendrecv Opus streams, we should respect the value of maxplaybackrate provided by the other side.

This is a request to us not to encode audio with a sampling rate higher than the given playback rate, since the receiver will not use it, and the bandwidth we spend on it will be wasted.

We should get the GIPS code to call opus_encoder_ctl(...,OPUS_SET_MAX_BANDIWDTH(x)) on its encoder based on the value of maxplaybackrate:

maxplaybackrate <= 8000:  x = OPUS_BANDWIDTH_NARROWBAND
maxplaybackrate <= 12000: x = OPUS_BANDWIDTH_MEDIUMBAND
maxplaybackrate <= 16000: x = OPUS_BANDWIDTH_WIDEBAND
maxplaybackrate <= 24000: x = OPUS_BANDWIDTH_SUPERWIDEBAND
maxplaybackrate > 24000:  x = OPUS_BANDWIDTH_FULLBAND

This may require some plumbing to get the information on the bandwidth the receiver wants to the GIPS encoder. I know the GIPS folks planned to implement that plumbing so Chrome could also respect these parameters, but I have lost track of the status of that work. It may already be done. We may have to do it ourselves.

Comment 1

[Timothy B. Terriberry (:derf)]

Looks like it is in progress: <https://webrtc-codereview.appspot.com/13099004/>.

Comment 2

[Timothy B. Terriberry (:derf)]

https://code.google.com/p/webrtc/issues/detail?id=1906

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

We'll need SDP, and we'll need to cherry-pick the patch for webrtc/trunk or wait for it to be in a stable branch we import.  Derf: any reason to cherry-pick?  I'm guessing not...

Comment 4

[Timothy B. Terriberry (:derf)]

I don't see a problem with waiting for the next import.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.

Comment 6

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)