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?
On Thursday, October 23, 2025 at 4:00:24 PM UTC+2 Sergey Silkin wrote: > 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 <https://www.w3.org/2025/09/16-webrtc-minutes.html#cb3e> by > representatives of Mozilla, Meta, Apple and Microsoft at a WebRTC WG > meeting. This is a small, incremental change that exposes an existing mode > <https://webrtc-review.googlesource.com/c/src/+/415200> to JS. > > Regards, > Sergey > > On Wednesday, October 22, 2025 at 5:11:56 PM UTC+2 Alex Russell wrote: > >> 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 >> >> On Wednesday, October 22, 2025 at 4:41:25 AM UTC-7 Chromestatus wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *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 >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%3EPeerConnection%22> >>> >>> *Web Feature ID* >>> webrtc <https://webstatus.dev/features/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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> 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 >>> <https://chromestatus.com>. >>> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5fe8bfd7-8778-43df-a7e2-0cd58b13bc5bn%40chromium.org.
