PSA: RTCPeerConnection's mediaConstraints is deprecated and will soon be removed

[Henrik Boström]

The mediaConstraints dictionary is non-standard and was either used to control features which now have a standard API or to control legacy features that have either been removed or are about to be removed.

As of M102, some constraints are removed and others emit deprecation warnings.

The plan is to ignore/remove all constraints listed below in the M103-M104 time frame.

Deprecation by use cases

The RTCPeerConnection constructor's mediaConstraints:

• Constraints now emitting a deprecation warning that will soon be ignored:
  • googCpuOveruseDetection: Already enabled-by-default. Being able to set this to false will soon be removed.
  • googIPv6: Already enabled-by-default. Being able to set this to false will soon be removed.
    
  • googScreencastMinBitrate: The default behavior is now the same as setting this to 100. Setting it to anything else will soon be removed.
    
  • googSuspendBelowMinBitrate: Disabled-by-default and ability to set it to true will soon be removed.
    
• Constraints that used to do something that now are ignored:
  • googDscp: Setting this to true was previously a prerequisite for using any value of RTCRtpEncodingParameters.networkPriority other than the default value "low". As of M102, googDscp is no longer needed to control networkPriority and setting it to false is not possible.
• The following constraints were already not wired up to anything (were NO-OPs) and are now ignored by the parser (using them will now cause a warning):
  • googCombinedAudioVideoBwe
  • googHighStartBitrate
  • latencyMs
  • googNumUnsignalledRecvStreams
  • googUseRtpMUX
  • googPayloadPadding
    

RTCPeerConnection.createOffer() and createAnswer()'s use of mediaConstraints:

• The callback-based versions of these methods (which are non-standard) used mediaConstraints to control OfferToReceiveAudio, OfferToReceiveVideo, IceRestart and VoiceActivityDetection. Using these will now emit a deprecation warning and they will soon be removed.
• Use the spec-compliant promise-based versions of these methods instead. The RTCOfferOptions and RTCAnswerOptions argument contains spec-compliant equivalents (notice lower casing): offerToReceiveAudio, offerToReceiveVideo, iceRestart and voiceActivityDetection.

RTCPeerConnection.addStream()'s use of mediaConstraints is now removed. It was previously parsed but none of the constraints had any effect.

mediaConstraints are also used by getUserMedia(). Usage is discouraged (please use spec-compliant constraints instead) but deprecation of these is not happening yet due to high usage counts. We should revisit this in the future.

On a side note, deprecation warnings inside the JavaScript console are as of recently mainly listed under the "Issues" button of the JS console rather than in the JS console directly.

Happy spring cleaning,

Henrik

[Philipp Hancke]

by "MediaConstraints" you mean the second argument to RTCPeerConnection, right?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/007e84a1-af4b-4195-9aba-3196a557b6aen%40googlegroups.com.

[Henrik Boström]

On Tuesday, April 19, 2022 at 1:41:15 PM UTC+2 philipp...@googlemail.com wrote:

by "MediaConstraints" you mean the second argument to RTCPeerConnection, right?

Yes, this refers to...

- The second argument to the RTCPeerConnection (after RTCConfiguration).

- The third argument to the callback-based versions of createOffer() and createAnswer() (after successCallback and failureCallback). Note that callback-based createOffer() is overloaded: the third argument can either be an RTCOfferOptions or mediaConstraints, this only affects mediaConstraints.

- The second argument to addStream() (after the stream).

mediaConstraints are also parsed by getUserMedia() when non-standard formats are used which is not being deprecated right now but we should revisit this in the future.

[Henrik Boström]

FYI as a follow up, we're removing most constraints in M103: https://groups.google.com/u/3/g/discuss-webrtc/c/2l7jWgreYpw

[刘威]

Is there any alternative solutions when googCpuOveruseDetection is removed?

[Henrik Boström]

There is not. If you've identified a use case where CPU adaptation triggers even though it arguably shouldn't, consider filing a https://crbug.com/webrtc.

If adaptation is needed, but you don't want resolution to be degraded, consider using the degradationPreference API (https://w3c.github.io/mst-content-hint/#dom-rtcrtpsendparameters-degradationpreference), that way you can degrade frame rate instead of resolution.