Intent to Ship: RTCDegradationPreference enum value "maintain-framerate-and-resolution"

[Chromestatus]

Contact emails

ssi...@chromium.org

Specification

https://www.w3.org/TR/mst-content-hint/#dom-rtcdegradationpreference-maintain-framerate-and-resolution

Summary

"maintain-framerate-and-resolution" disables WebRTC's internal video adaptation. This enables the application to implement its own adaptation logic and prevents interference from the internal adaptation. From https://www.w3.org/TR/mst-content-hint/#dom-rtcdegradationpreference-maintain-framerate-and-resolution: Maintain framerate and resolution regardless of video quality. The user agent SHOULD NOT prefer reducing the framerate or resolution for quality and performance reasons, but MAY drop frames before encoding if necessary not to overuse network and encoder resources.

Blink component

Blink>WebRTC>PeerConnection

Web Feature ID

webrtc

Motivation

WebRTC has an internal video adaptation mechanism that optimizes video quality and performance by adjusting encoding settings. This mechanism relies on hardcoded logic and thresholds, which may not yield optimal results across diverse use cases. Application may benefit from implementing and using its own, external adaptation. For the external adaptation to work properly, the internal one needs to be disabled. "maintain-framerate-and-resolution" allows to disable the WebRTC's internal adaptation. WebRTC WG presentation: https://docs.google.com/presentation/d/11rr8X4aOao1AmvyoDLX8o9CPCmnDHkWGRM3nB4Q_104/edit?slide=id.g3657813d9b5_0_0#slide=id.g3657813d9b5_0_0

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Low risk. This change adds "maintain-framerate-and-resolution" to the RTCDegradationPreference enum. This new mode will not be used as a default or as a fallback option.

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

No information provided

Finch feature name

No information provided

Non-finch justification

No information provided

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	144
Shipping on Android	144
Shipping on WebView	144

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5156290162720768?gate=5857376464928768

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Heya Sergey,

This seems like a great addition, but I'm not sure why we're adding this now? Are there any developers clamouring for it? Any sites that we know will benefit?

A short explainer that explains why this is an important problem to solve would help me here, particularly that there are no signals and we're going first, which raises the first-mover disadvantage risk.

Best,

Alex

[Sergey Silkin]

Hi Alex,

Google Meet needs this functionality. It gives WebRTC-based apps better control over video quality and performance. It has been reviewed and approved by representatives of Mozilla, Meta, Apple and Microsoft at a WebRTC WG meeting. This is a small, incremental change that exposes an existing mode to JS.

Regards,

Sergey

[Henrik Boström]

Alex, I don't see how this incremental improvement is anything different from other incremental improvements which are typically approved by the Blink owners given they have WG support, customers waiting to use it (Google Meet being one example which is often a sign that it's providing missing functionality) as well as Sergey being willing to implement it. What's the next step here?

[Daniel Bratell]

LGTM1

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5fe8bfd7-8778-43df-a7e2-0cd58b13bc5bn%40chromium.org.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1930ea87-17b2-42ba-bab2-de3e745288d0%40gmail.com.

[Vladimir Levin]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5fe8bfd7-8778-43df-a7e2-0cd58b13bc5bn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.