LGTM3

On Wednesday, November 12, 2025 at 11:05:15 AM UTC-5 Chris Harrelson wrote:

> LGTM2
>
> On Wed, Nov 12, 2025 at 7:43 AM Daniel Bratell <[email protected]> 
> wrote:
>
>> LGTM1
>>
>> /Daniel
>> On 2025-11-07 08:27, 'Henrik Boström' via blink-dev wrote:
>>
>> 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
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5fe8bfd7-8778-43df-a7e2-0cd58b13bc5bn%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>> -- 
>> 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/1930ea87-17b2-42ba-bab2-de3e745288d0%40gmail.com
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1930ea87-17b2-42ba-bab2-de3e745288d0%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/aadf4728-fca1-448d-aeff-ea6222b6b374n%40chromium.org.

Reply via email to