Re: [blink-dev] Intent to Ship: jitterBufferTarget

[Henrik Boström]

>From a code owner and W3C participant's perspective, I'm very happy that 
we're finally aligning our attribute name with the spec + Firefox' 
implementation. Thank you Eldar!

(Ultimately we should deprecate and remove the old attribute name, but not 
until this has been shipped for a long time.)

On Tuesday, February 13, 2024 at 11:29:09 PM UTC+1 Mike Taylor wrote:

> Thanks! I had intended to reply that it's very simple to add a runtime 
> enabled feature to IDL, but it's been a busy day. :)
> On 2/13/24 3:57 PM, Eldar Rello wrote:
>
> >Can we add a flag? 
> https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md
>
> >(Or someone can explain why that's difficult and the risk is low here...).
>
> I made it as a runtime enabled feature now.
>
> On Monday, February 12, 2024 at 10:50:18 PM UTC+2 Eldar Rello wrote:
>
>> On Monday, February 12, 2024 at 4:53:50 PM UTC+2 mike...@chromium.org 
>> wrote:
>>
>> On 2/12/24 6:36 AM, Eldar Rello wrote:
>>
>> Contact emails eldar...@gmail.com
>>
>> Explainer None
>>
>> Specification 
>> https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget
>>
>> Summary 
>>
>> JitterBufferTarget attribute allows applications to specify a target 
>> duration of time in milliseconds of media for the RTCRtpReceiver's jitter 
>> buffer to hold. This influences the amount of buffering done by the user 
>> agent, which in turn affects retransmissions and packet loss recovery. 
>> Altering the target value allows applications to control the tradeoff 
>> between playout delay and the risk of running out of audio or video frames 
>> due to network jitter.
>>
>>
>> Essentially it is a rename of already shipped playoutDelayHint attribute.
>>
>> Is this purely a rename, or are there changes to the semantics?
>>
>> Other than the name change, it throws RangeError when delay parameter is 
>> out of range. playoutDelayHint is throwing only if delay is negative. 
>> Another difference is that jitterBuffferTarget is in milliseconds unit 
>> while playoutDelayHint is using seconds.
>>
>> And do we have any sense how widely used playoutDelayHint is in the wild? 
>> There is some discussion of the bikeshedding in 
>> https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html, 
>> but no consideration of existing usage (at least as reflected in the 
>> minutes).
>>
>> I do not have visibility over usage, but playoutDelayHint remains 
>> supported to enable smooth adaption.
>>
>>
>> Blink component Blink>WebRTC 
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Opening an issue seems useful, but that seems like a heavy tax for a 
>> contributor (vs the spec editors...).
>>
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> None
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> Mind providing a link to a bug?
>>
>>  
>> Added
>>
>>
>> *WebKit*: No signal
>>
>> Can we request a permission please? 
>> https://github.com/WebKit/standards-positions
>>
>>
>> Created ticket there.
>>  
>>
>>
>>
>> *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?
>>
>> None
>>
>>
>> Debuggability 
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)? No
>>
>> Which platforms will it be supported on, if not all of them?
>>
>>  
>> Fixed. Initially I was unsure, but it should be supported on all 
>> platforms where WebRTC is available. 
>>
>>
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? Yes 
>>
>>
>> https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental=master
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name None
>>
>> Can we add a flag? 
>> https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md
>>
>> (Or someone can explain why that's difficult and the risk is low here...).
>>
>> Personally I do not see any value for guarding as like already mentioned 
>> exactly same functionality is already exposed by legacy attribute 
>> playoutDelayHint. 
>>
>>
>> Non-finch justification None
>>
>> Requires code in //chrome? False
>>
>> Estimated milestones Shipping on desktop 123 
>>
>> 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).
>> None
>>
>> Link to entry on the 

Re: [blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

[Henrik Boström]

Having participated in both the WG meeting and the following editors 
meetings where the editors merged the PR, my memory too is that there was 
wide support for this.

To make sure I'm not misremembering, I rewatching the recording 
 just now. I don't 
hear anybody challenging the use case, it's mostly discussions about 
whether this should be considered a "parameter" or not. Philipp explains 
why it needs to be set at the same time as the other parameters even though 
it's not a traditional parameter, Harald expresses a need for getParameters 
and setParameters to work with the same params and Florent suggests a way 
to solve this by introducing a second argument to the method. There are 
some questions about whether the use case might already be covered by the 
"active" flag, a point first made by Jan-Ivar, but there are problems with 
that IMO and ultimately we ran out of time. So there was some ambiguity if 
this was just bike shedding or if there were legitimately other options, 
but most voices were supporting this and the recorded outcome was to 
"refine the PR". So these discussions continued in follow-ups.

The follow-ups happened during the editors meeting where the PR 
 was refined, approved 
by Jan-Ivar (Mozilla), Bernard (Microsoft) and myself (Google) and merged. 
We went with Florent's suggestion of a second argument which avoided the 
parameter issue that Harald initially raised. My understanding is that 
everyone was happy with it, but I can't speak for other people.
On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1 vmp...@google.com wrote:

> Based on the WG discussion (meeting notes: 
> https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem 
> that there is a very strong consensus that this is a right spot to add an 
> extra parameter. There are also no signals on the RFPs, but the spec PR has 
> landed. How would you assess the vendor support for this change?
>
> Thanks,
> Vlad
>
> On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> This extension has consensus in the WEBRTC WG, and CLs are approved by 
>> the Chrome WebRTC folks.
>>
>>
>> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> phan...@microsoft.com, ma...@microsoft.com
>>>
>>> Explainer
>>>
>>> https://fippo.github.io/webrtc-explainers/rtcrtpsender-setparameters
>>>
>>> Specification
>>>
>>>
>>> https://w3c.github.io/webrtc-extensions/#rtcrtpsender-setparameters-keyframe
>>>
>>> Summary
>>>
>>> Adds an optional second parameter to WebRTC's RTCRtpSender.setParameters 
>>> call which can be used to ask the associated encoder to generate a key 
>>> frame.
>>>
>>> Blink component
>>>
>>> Blink>WebRTC>PeerConnection 
>>> 
>>>
>>> TAG review
>>>
>>> None, small addition to WebRTC
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> RisksInteroperability and Compatibility
>>>
>>> None
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/858)
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/237)
>>>
>>> Web developers: Positive Microsoft Teams is quite interested in the 
>>> feature.
>>>
>>> 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?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>> 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 
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> See WPT added as part of 
>>> https://chromium-review.googlesource.com/c/chromium/src/+/4643591
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> None
>>>
>>> Non-finch justification
>>>
>>> None
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1354101
>>>
>>> Estimated milestones
>>>
>>> Shipping on desktop
>>>
>>> 122
>>>
>>>
>>> Anticipated spec changes
>>>
>>> None
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5161082937409536
>>>
>>> This intent message was generated by Chrome Platform Status 
>>>  and then copy-pasted around
>>>
>>> -- 
>>> 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+unsubscr...@chromium.org.
>>> To 

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

[Henrik Boström]

Excellent, we have a plan!

On Wednesday, December 20, 2023 at 7:13:36 PM UTC+1 Mike Taylor wrote:

> LGTM3, with same condition.
> On 12/20/23 11:58 AM, Chris Harrelson wrote:
>
> LGTM2 to ship, with a commitment to move this part of the spec to WICG if 
> it gets removed from the mediacapture-extensions spec.
>
> On Thu, Dec 14, 2023 at 11:06 AM Alex Russell  
> wrote:
>
>> LGTM1
>>
>> On Thursday, December 14, 2023 at 8:00:41 AM UTC-8 Rick Byers wrote:
>>
>>> Sounds good Henrik! Yes, from our brief discussion in the API owners 
>>> meeting I believe you have support from at least 3 API owners to proceed in 
>>> this direction. It's important to us that we engage constructively in the 
>>> standards process even in areas of differing opinion, but it's also crucial 
>>> to our process that we not let such differences in opinion and priority be 
>>> an effective veto power over what we choose to ship in Chromium. I'd 
>>> encourage you and the WebRTC group to formalize processes for amicably 
>>> agreeing to disagree on the importance of different use cases, while still 
>>> being open to technical feedback and doing what we reasonably can to 
>>> maximize the chance that the APIs we ship can eventually be interoperable 
>>> if priorities of the other engines someday change [*]. API owners would 
>>> also be interested to hear any other arguments for why Chromium shipping 
>>> these APIs would be bad for the web (on this list, or anywhere else). I 
>>> know there's a messy history with WebRTC in particular and services coming 
>>> to depend on Chromium-only APIs when suitable standards-track alternatives 
>>> are available in other engines. That's IMHO definitely not a pattern we 
>>> want to risk repeating. 
>>>
>>> Of course you also need Chrome privacy and security reviews, since it's 
>>> important that features like this don't create a hole in our careful 
>>> balance of side channel attack mitigations. But I see you already have 
>>> privacy approval so hopefully security isn't too far off. You might want to 
>>> wait for a signal there before starting implementation.
>>>
>>> Personally I'm also less concerned about interoperability risks when it 
>>> comes to metrics API. It's already the case that our top 
>>> performance metrics (Core Web Vitals) have APIs exposed only in Chromium. 
>>> There's certainly some interop risk there, eg. of sites optimizing in 
>>> engine-specific ways. But in practice we've seen developers use these APIs 
>>> mostly to make their sites faster in ways that generally apply to all 
>>> engines. So in that case, Safari and Firefox are getting most of the 
>>> benefit of these APIs existing without having to incur most of the cost, 
>>> which seems like a fine outcome to me. Also, I'm confident that if we 
>>> eventually agree with other engines on some better way to expose the same 
>>> information, then we can deprecate and remove any API shape we ship today 
>>> and customers can migrate over without causing user-visible breakage 
>>> (worst-case we just return dummy values on the deprecated APIs). 
>>>
>>> Rick
>>>
>>> [*] My favorite example of this is Pointer Events where Apple was 
>>> opposed to the use case, but also had good technical critiques of the API. 
>>> We eventually (after a lot of research, open debate, and some flip-flopping 
>>> by me) shipped a version of the API that addressed the legitimate technical 
>>> concerns without addressing Apple's objections around the use case. Years 
>>> later when a use case materialized for Apple (the Apple Pen), they just 
>>> shipped the API in a fully interoperable fashion. That (as well as cases of 
>>> the inverse where we realize we were wrong and unship) is what we mean by 
>>> the blink process being designed for "eventual interoperability". 
>>>
>>>
>>> On Thu, Dec 14, 2023 at 4:34 AM Henrik Boström  
>>> wrote:
>>>
>>>> Thanks, Rick. Responses inline.
>>>>
>>>> On Wednesday, December 13, 2023 at 6:39:48 PM UTC+1 Rick Byers wrote:
>>>>
>>>> I looked into the details of the standards debate on this issue. It 
>>>> sounds like it's still unclear whether the spec for this has WG support or 
>>>> not, right? I certainly wouldn't want to mislead anyone as to API maturity 
>>>> / likely interoperability by shipping based on a WebRTC WG specification 
>>>> if 
>>

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

[Henrik Boström]

Thanks, Rick. Responses inline.

On Wednesday, December 13, 2023 at 6:39:48 PM UTC+1 Rick Byers wrote:

I looked into the details of the standards debate on this issue. It sounds 
like it's still unclear whether the spec for this has WG support or not, 
right? I certainly wouldn't want to mislead anyone as to API maturity / 
likely interoperability by shipping based on a WebRTC WG specification if 
there is an unresolved process concern.


I think it's safe to say we don't have consensus on the frame counters 
(exposing dropped/glitches), while capture latency hopefully be less 
contentious.


That said, I think Chromium's position on the technical debate here is 
pretty clear - we do believe there's value in such stats APIs, even IF they 
can only represent browser bugs (it's why we ship a crash reporting API 
<https://wicg.github.io/crash-reporting/>, which has been similarly 
controversial with Mozilla and Apple). We disagree that "there's nothing 
web developers can do about it". Maybe that's true for Apple and Mozilla, 
but for Google we rely critically on developer feedback through both open (
crbug.com) and private (Google partnerships) channels and we want to make 
it as easy as possible for developers to report an issue they're seeing to 
us in a way that's actionable. Our privacy policy limits Chrome's 
visibility into what's going on in the wild. So usually we find this 
requires a mix of both site-acquired telemetry and browser-required 
telemetry, and find the two can often complement each other nicely.  

Henrik, my advice if the WG doesn't have consensus for this API is to move 
it to some incubation venue (like a WICG group). You clearly have a 
community of web developers who want it, so it's probably more productive 
to focus standards energy among allies who share an interest for the use 
case, right? If you're willing to promptly move this to a WICG spec in the 
event the WG asks to remove it from their spec, then I don't think this 
debate changes anything from a blink API owner's perspective so I'm OK 
treating it as non-blocking. A subset of API owners met today (Daniel, Mike 
Taylor, Philip and I), and agreed with this stance. WDYT?


Me moving this to a WICG spec in the event that the WG asks to remove them 
from mediacapture-extensions sounds good to me.
If me and/or the WebRTC Audio Team has access to a WICG spec for these 
things, that may also give us a venue for, in the future, exploring 
*playout* glitch metrics in a more enthusiastic setting, which is in the 
early stages of discussions internally.


In terms of testing, normally we ask to see the tests land before approving 
an I2S. Any reason we shouldn't wait for that here?


Given the "controversy" around the glitch metrics, the WebRTC Audio Team 
wanted to get some Blink owners signals before they spend the engineering 
efforts to implement this (including WPTs).
But if Blink owners also see the value in these metrics and we have a plan 
(= move to WICG in the event that they are removed) I see no reason not to 
ask them to start implementation today.

For reference, see the WPTs we added for the video track stats here 
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-extensions/MediaStreamTrack-video-stats.https.html>.
 
The audio track stats WPTs should be similar and also complemented by C++ 
unit tests in lower layers.


Thanks,
   Rick



On Fri, Dec 8, 2023 at 11:53 AM Henrik Boström  wrote:

Contact emails
h...@chromium.org, o...@chromium.org, h...@chromium.org

Specification
https://w3c.github.io/mediacapture-extensions/#the-
mediastreamtrackaudiostats-interface

Summary

The MediaStreamTrack Statistics API, or `track.stats`, has already shipped 
for video tracks: see previous I2S here 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/ttzYv-30gY4/m/2FvJpxqMGQAJ>
.


This is the same API but for audio tracks, also motivated by the app's 
desire to measure capture quality. This is very important for conferencing 
websites such as Google Meet, Microsoft Teams, Zoom, Goto Meetings, etc. 
All of which has expressed an interest in the audio portion of this API.


The API is only available for getUserMedia() sourced audio tracks, i.e. 
microphone, so the API is behind a user prompt and only available during 
capture.


The new interface we want to ship is MediaStreamTrackAudioStats 
<https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackaudiostats-interface>
 
which allow measuring two things from the audio capture pipeline:

1. The number of audio frames, including if any audio frames are dropped by 
the device, OS or User Agent. This allows measuring glitches in captured 
audio.

2. The input latency, such as due to buffering or other delays in 
delivering the audio frames to the track's sinks.

Blink component
Blink>GetUserMedia 
<https://bugs.chromium.org/p/chromium/is

[blink-dev] Intent to Ship: MediaStreamTrack Stats (Audio)

[Henrik Boström]

Contact emails
h...@chromium.org, o...@chromium.org, h...@chromium.org

Specification
https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackaudiostats-interface

Summary

The MediaStreamTrack Statistics API, or `track.stats`, has already shipped 
for video tracks: see previous I2S here 

.


This is the same API but for audio tracks, also motivated by the app's 
desire to measure capture quality. This is very important for conferencing 
websites such as Google Meet, Microsoft Teams, Zoom, Goto Meetings, etc. 
All of which has expressed an interest in the audio portion of this API.


The API is only available for getUserMedia() sourced audio tracks, i.e. 
microphone, so the API is behind a user prompt and only available during 
capture.


The new interface we want to ship is MediaStreamTrackAudioStats 

 
which allow measuring two things from the audio capture pipeline:

1. The number of audio frames, including if any audio frames are dropped by 
the device, OS or User Agent. This allows measuring glitches in captured 
audio.

2. The input latency, such as due to buffering or other delays in 
delivering the audio frames to the track's sinks.

Blink component
Blink>GetUserMedia 


Risks
Interoperability and Compatibility

Because the API provides *statistics* about capture quality, rather than 
providing capture *functionality, *the interop/compatibility risk is small.

*Gecko*: Standards position issue 

*WebKit*: Standards position issue 


Standardization
While the audio stats API is written by the W3C WebRTC Working Group and 
track statistics overall is not controversial, there is an ongoing 
disagreement with Mozilla about whether or not dropped frames (= 
totalFrames - deliveredFrames) should be exposed to the web in the audio 
case. The disagreement is tracked by this issue 
. Our need for 
this metric has been discussed at Virtual Interims, see recording with 
10:39 timestamp  but no 
consensus could be reached (rough consensus was reached between everyone 
except Mozilla). Youenn (Apple) has shown that frames can be dropped due to 
Bluetooth connection 

 and 
is not just "measuring browser bugs".

*Web developers*: Positive
- The I2P 

 shows 
support from Teams, Zoom and GoTo meetings.
- In the spec issue 
 regarding the 
disagreement, more developer support is expressed (e.g. alfredh from Nvidia 
and steely-glint).

WebView application risks

None

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 

?
Yes and WPTs will be written as part of implementing this, however unit 
tests will also be needed to verify accuracy of metrics on a lower level. 
WPTs will be more general like "frame counters increase over time during 
capture" and that run-to-completion semantics are preserved.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5141112910249984

Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb6c1af3-9eb3-4c6f-a136-dee709b7f906n%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a594fc55-8030-4848-9fe6-549eccfdd8a8n%40chromium.org.

Re: [blink-dev] Intent to Prototype: MediaStreamTrack Stats (Audio)

[Henrik Boström]

Thanks for the feedback from developers.

On Thursday, November 16, 2023 at 5:39:27 PM UTC+1 michae...@zoom.us wrote:

Zoom is interested in this as well - it is critical for us to understand 
where in our audio pipeline that frames have been dropped.

Would this be supported for audio tracks in all MediaStream contexts, or 
just the stream obtained via `getUserMedia`? In particular, I would love if 
we could also get these statistics for audio tracks on a stream obtained 
via WebAudio's `createMediaStreamDestination` (https://developer.mozilla.
org/en-US/docs/Web/API/AudioContext/createMediaStreamDestination).


The audio stats API is currently only specified for getUserMedia() sourced 
tracks. It might be worth discussing stats for more tracks in the future 
once the spec and implementation is stable (I personally thought about 
getDisplayMedia() as well, which we support in the video stats case), but 
we're currently keeping the scope limited to reduce complexity.
 


On Wednesday, November 15, 2023 at 9:50:19 AM UTC-6 Michael Fröhlich wrote:

We (GoTo) would also be interested in have dropped frame counts as well as 
input latency counts. Thanks for adding this.

philipp...@googlemail.com schrieb am Mittwoch, 15. November 2023 um 
12:14:16 UTC+1:

[snip]

 

*Web developers*: Positive


Any links?


I don't have any links but I've been told that web developers have been 
"asking for input latency metrics for years".
On behalf of Google, Google Meet web developers are asking for both dropped 
frames ratio metrics and input latency metrics, so I am developing these 
PRs together with the WebRTC audio experts who requested them.


I've asked my Microsoft Teams Web audio folks and they look forward  to 
being able to measure capture glitches this way.
Nobody likes audio glitches and I hope this will help reduce them and/or 
identifying devices which are more prone.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/faa3486f-8bbb-46c2-8387-adcdccf3b2c9n%40chromium.org.

Re: [blink-dev] Intent to Prototype: MediaStreamTrack Stats (Audio)

[Henrik Boström]

On Tuesday, November 14, 2023 at 8:12:41 AM UTC+1 Yoav Weiss wrote:

On Mon, Nov 13, 2023 at 4:04 PM Henrik Boström  wrote:

Contact emails
h...@chromium.org, o...@chromium.org, h...@chromium.org

Specification
https://w3c.github.io/mediacapture-extensions/#the-
mediastreamtrackaudiostats-interface

Summary

The `track.stats` API allows an application to measure quality related to 
the capturing of a MediaStreamTrack (getUserMedia). This API has already 
shipped for video tracks (Chrome Status 
<https://chromestatus.com/feature/5087376775053312>, Intent to Ship 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/ttzYv-30gY4>). This 
intent relates to the audio version of the same API, which has similar 
metrics plus input latency metrics.

The spec is actively under development. It currently contains frame counters 
<https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackaudiostats-interface>
 (like 
the video counterpart) which in the audio case allows calculating ratio of 
dropped audio which is a measure of capture glitches. There is also a PR in 
review <https://github.com/w3c/mediacapture-extensions/pull/124> which will 
add current input latency and a follow-up issue to add min/max/avg latency 
<https://github.com/w3c/mediacapture-extensions/issues/128>.

Blink component
Blink>GetUserMedia 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EGetUserMedia>

Motivation
The motivation is similar to that of video stats 
<https://github.com/mozilla/standards-positions/issues/895>, but this time 
it is audio related.

Quality measurements are important to understand user reports that app gets 
(e.g. in Google Meet, users may file bugs containing quality dumps) and A/B 
experiments to understand how features impact quality (e.g. adding heavy 
video processing in an app may impact audio quality). Latency may be useful 
for audio processing. Together with WebRTC metrics, capture metrics help 
provide context as to which parts of the pipeline are contributing to 
quality in what way.

TAG review status
N/A small addition to existing spec and the `track.stats` API shape has 
already shipped for video.

Risks
Interoperability and Compatibility

Risk is relatively small since this is a stats API. The MediaStreamTrack 
functions whether or not you can measure quality related properties of the 
track.

*Gecko*: No signal
*WebKit*: No signal


Have we reached out?


The spec is still being worked on and I have not officially reached out, 
but representatives from both Mozilla and Apple are part of the WG 
discussions.
On the video stats side (same API shape but not the same metrics), Mozilla 
was positive <https://github.com/mozilla/standards-positions/issues/895> and 
Apple was unresponsive 
<https://github.com/WebKit/standards-positions/issues/260>.

At the moment, there is a disagreement about whether or not frame dropping 
is worth measuring 
<https://github.com/w3c/mediacapture-extensions/issues/129> but we are in 
agreement - at least Google and Mozilla - that capture input latency is 
something we want to have, but the PR needs more work to get the definition 
right before it can be merged. This sends both positive and negative 
signals, but I do not have an official statement yet.
 

 

*Web developers*: Positive


Any links?


I don't have any links but I've been told that web developers have been 
"asking for input latency metrics for years".
On behalf of Google, Google Meet web developers are asking for both dropped 
frames ratio metrics and input latency metrics, so I am developing these 
PRs together with the WebRTC audio experts who requested them.

 

*Other signals*:

WebView application risks

None


Debuggability

None

Is this feature fully tested by web-platform-tests 
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?
Test coverage will be added as part of implementation, including which 
metrics are supported by the browser. In addition to WPTs, correctness of 
quality metrics may require browser tests e.g. for fake devices.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5141112910249984

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/bb6c1af3-9eb3-4c6f-a136-
dee709b7f906n%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb6c1af3-9eb3-4c6f-a136-dee709b7f906n%40chromium.org?utm_medium=email_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 
t

[blink-dev] Intent to Prototype: MediaStreamTrack Stats (Audio)

[Henrik Boström]

Contact emails
h...@chromium.org, o...@chromium.org, h...@chromium.org

Specification
https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackaudiostats-interface

Summary

The `track.stats` API allows an application to measure quality related to 
the capturing of a MediaStreamTrack (getUserMedia). This API has already 
shipped for video tracks (Chrome Status 
, Intent to Ship 
). This 
intent relates to the audio version of the same API, which has similar 
metrics plus input latency metrics.

The spec is actively under development. It currently contains frame counters 

 (like 
the video counterpart) which in the audio case allows calculating ratio of 
dropped audio which is a measure of capture glitches. There is also a PR in 
review  which will 
add current input latency and a follow-up issue to add min/max/avg latency 
.

Blink component
Blink>GetUserMedia 


Motivation
The motivation is similar to that of video stats 
, but this time 
it is audio related.

Quality measurements are important to understand user reports that app gets 
(e.g. in Google Meet, users may file bugs containing quality dumps) and A/B 
experiments to understand how features impact quality (e.g. adding heavy 
video processing in an app may impact audio quality). Latency may be useful 
for audio processing. Together with WebRTC metrics, capture metrics help 
provide context as to which parts of the pipeline are contributing to 
quality in what way.

TAG review status
N/A small addition to existing spec and the `track.stats` API shape has 
already shipped for video.

Risks
Interoperability and Compatibility

Risk is relatively small since this is a stats API. The MediaStreamTrack 
functions whether or not you can measure quality related properties of the 
track.

*Gecko*: No signal
*WebKit*: No signal
*Web developers*: Positive
*Other signals*:

WebView application risks

None


Debuggability

None

Is this feature fully tested by web-platform-tests 

?
Test coverage will be added as part of implementation, including which 
metrics are supported by the browser. In addition to WPTs, correctness of 
quality metrics may require browser tests e.g. for fake devices.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5141112910249984

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb6c1af3-9eb3-4c6f-a136-dee709b7f906n%40chromium.org.

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats

['Henrik Boström' via blink-dev]

https://chromestatus.com/feature/5087376775053312

On Wednesday, October 11, 2023 at 4:09:32 PM UTC+2 Mike Taylor wrote:

> Also, could you please create a chromestatus entry and request the various 
> review gate bits?
> On 10/11/23 10:08 AM, Mike Taylor wrote:
>
> LGTM2
> On 10/11/23 8:49 AM, Philip Jägenstedt wrote:
>
> LGTM1, this is a minor addition to an existing API, was discussed in the 
> WG at TPAC, and has a positive standards position from Mozilla.
>
> On Mon, Oct 9, 2023 at 4:16 PM Henrik Boström  wrote:
>
>> *Contant emails:* 
>> hb...@chromium.org, h...@chromium.org
>>
>> *Explainer:*
>> This is a small addition to the MediaStreamTrack 
>> <https://rawgit.com/w3c/mediacapture-main/master/getusermedia.html#dom-mediastreamtrack>.
>>  
>> The new `track.stats` attribute getter allows a JS app to obtain statistics 
>> of a track, which in the case of video refers to frame counters. For 
>> example, if you use getUserMedia() to open a camera at a specific frame 
>> rate setting, this API lets you know how many frames the camera is actually 
>> producing (e.g. frame rate may be lower in low light conditions or higher 
>> than the app wants due to HW capabilities) and how many frames, if any, are 
>> discarded or dropped by the user agent, which is useful for investigations 
>> and experiments (some concrete examples mentioned here 
>> <https://github.com/mozilla/standards-positions/issues/895>).
>>
>> *Spec:*
>> https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics
>> This is an extension spec, owned by the same working group who owns the 
>> main spec.
>>
>> The spec and implementation currently only covers video frames, but 
>> similar audio frame counters are being considered for the future as well.
>>
>> *Summary:*
>> Add frame counters to MediaStreamTrack.
>>
>> *Is this feature supported on all six Blink platforms?*
>> Yes.
>>
>> *Measurements*
>> Will add [Measure].
>>
>> *Risks*
>> Compatibility: MediaStreamTrack is supported on all browsers and the new 
>> stats API is a read-only statistics API rather than core functionality, so 
>> interop risks should be relatively limited.
>>
>> Signals from other implementers:
>> - Firefox: positive (request for position 
>> <https://github.com/mozilla/standards-positions/issues/895>)
>> - Safari: no signal at the time of writing (request for position 
>> <https://github.com/WebKit/standards-positions/issues/260>)
>>
>> Ergonomics: Used together with MediaStreamTrack and WebRTC 
>> (RTCPeerConnection)
>>
>> Activation: N/A
>>
>> *Web Platform Tests*
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-extensions/MediaStreamTrack-video-stats.https.html
>>
>> -- 
>> 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 on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/029c4aea-9a60-4e9e-bc9c-773cac617454n%40chromium.org
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/029c4aea-9a60-4e9e-bc9c-773cac617454n%40chromium.org?utm_medium=email_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 blink-dev+...@chromium.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcfV8inYFU5ChgPrTVRUX7%3D%2BFTTjL4D%3DLaYYYdQX1Wsbw%40mail.gmail.com
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcfV8inYFU5ChgPrTVRUX7%3D%2BFTTjL4D%3DLaYYYdQX1Wsbw%40mail.gmail.com?utm_medium=email_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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9a15321-d5d8-49ce-86da-b22a490486den%40chromium.org.

[blink-dev] Intent to Ship: MediaStreamTrack Stats

[Henrik Boström]

*Contant emails:*
h...@chromium.org, h...@chromium.org

*Explainer:*
This is a small addition to the MediaStreamTrack 
.
 
The new `track.stats` attribute getter allows a JS app to obtain statistics 
of a track, which in the case of video refers to frame counters. For 
example, if you use getUserMedia() to open a camera at a specific frame 
rate setting, this API lets you know how many frames the camera is actually 
producing (e.g. frame rate may be lower in low light conditions or higher 
than the app wants due to HW capabilities) and how many frames, if any, are 
discarded or dropped by the user agent, which is useful for investigations 
and experiments (some concrete examples mentioned here 
).

*Spec:*
https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics
This is an extension spec, owned by the same working group who owns the 
main spec.

The spec and implementation currently only covers video frames, but similar 
audio frame counters are being considered for the future as well.

*Summary:*
Add frame counters to MediaStreamTrack.

*Is this feature supported on all six Blink platforms?*
Yes.

*Measurements*
Will add [Measure].

*Risks*
Compatibility: MediaStreamTrack is supported on all browsers and the new 
stats API is a read-only statistics API rather than core functionality, so 
interop risks should be relatively limited.

Signals from other implementers:
- Firefox: positive (request for position 
)
- Safari: no signal at the time of writing (request for position 
)

Ergonomics: Used together with MediaStreamTrack and WebRTC 
(RTCPeerConnection)

Activation: N/A

*Web Platform Tests*
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-extensions/MediaStreamTrack-video-stats.https.html

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/029c4aea-9a60-4e9e-bc9c-773cac617454n%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

['Henrik Boström' via blink-dev]

Thanks Mason, we're reaching out

On Sat, May 13, 2023 at 3:27 AM Mason Freed  wrote:

> Chiming in briefly here - it appears (from my console messages) that
> BrowserStack is currently hitting this deprecation. BrowserStack sessions
> in M115 restart on ~5 second intervals with a console error pointing to
> this deprecation.  Might be worth reaching out to them to talk about
> mitigations.
>
>
> On Friday, February 24, 2023 at 2:28:21 PM UTC-8 Mike Taylor wrote:
>
>> LGTM3
>> On 2/24/23 12:31 PM, Philip Jägenstedt wrote:
>>
>> LGTM2, even better!
>>
>> On Fri, Feb 24, 2023 at 5:04 PM Yoav Weiss 
>> wrote:
>>
>>> SGTM!
>>>
>>> On Fri, Feb 24, 2023 at 4:40 PM Henrik Boström  wrote:
>>>
>>>> Yes, I think throwing in M117, stable on Aug 30 would be even better.
>>>>
>>>> On Friday, February 24, 2023 at 4:32:21 PM UTC+1 Philip Jägenstedt
>>>> wrote:
>>>>
>>>>> I think the overall timeline looks great, the final removal is almost
>>>>> a year from now, after the 2023 holiday season.
>>>>>
>>>>> However, I'd like to bikeshed "Throw an exception if the trial is not
>>>>> used in Stable in M119 (Release: October 31, 2023)". This is when the
>>>>> breakage will be apparent to most users/developers, anyone who isn't 
>>>>> paying
>>>>> attention to deprecation warnings. Oct 31 doesn't give a whole lot of time
>>>>> to figure out how origin trials work and opt into that, so I would suggest
>>>>> M117, stable on Aug 30. That's as early as seems reasonable given summer
>>>>> vacations in the northern hemisphere.
>>>>>
>>>>> WDYT Henrik, would that work just as well for you?
>>>>>
>>>>> On Thu, Feb 23, 2023 at 1:17 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> LGTM1 for that plan
>>>>>>
>>>>>> On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström 
>>>>>> wrote:
>>>>>>
>>>>>>> In that case the proposal is:
>>>>>>> - Add deprecation warning in M113 (Release: May 2, 2023) with the
>>>>>>> possibility to opt-in to the Deprecation Trial.
>>>>>>> - Throw an exception if the trial is not used in Canary/Dev/Beta in
>>>>>>> M114.
>>>>>>> - Throw an exception if the trial is not used in Stable in M119
>>>>>>> (Release: October 31, 2023).
>>>>>>> - Let M121 be the last version where the Trial is available
>>>>>>> (Release: January 9, 2024). In other words the first version where the
>>>>>>> trial and legacy getStats API is entirely removed is M122 (Release:
>>>>>>> February 6, 2024).
>>>>>>>
>>>>>>> On Thursday, February 23, 2023 at 11:38:48 AM UTC+1 Yoav Weiss wrote:
>>>>>>>
>>>>>>>> SGTM
>>>>>>>>
>>>>>>>> On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström <
>>>>>>>>> hb...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>> OK, so deprecation warning in M113, throwing in Beta in M114 and
>>>>>>>>> throwing in Stable on M119. We can do that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Awesome!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Under this less aggressive timeline, for how many more milestones
>>>>>>>>> would the Deprecation Trial span?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How much would be needed for people to schedule the work to make
>>>>>>>>> the switch?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If they notice the deprecation warning they would have enough time
>>>>>>>>> to migrate before the Depre

[blink-dev] Re: Intent-to-Ship: MediaRecorder keyframe configurability

[Henrik Boström]

I was present when the WG discussed this pull request and can confirm that 
representatives of Apple, Microsoft, Firefox and Google were present when 
the PR was merged.
This API solves problems relating to variable frame rate tracks and being 
able to ensure key frames in the streams. Allowing implementing this seems 
like a good thing as it plugs an existing hole, so to speak.

On Friday, April 21, 2023 at 6:48:17 PM UTC+2 Markus Handell wrote:

> Contact emails:
>
> hand...@google.com
>
> Explainer:
>
>- 
>
>https://github.com/w3c/mediacapture-record/pull/216
>- 
>
>crbug.com/1371449
>
>
> TAG review:
>
> N/A, small incremental change
>
> Summary:
>
> The `MediaRecorder` spec was recently updated to allow users to configure 
> video keyframe generation parameters of the encoder. Previously there was 
> no such support, and no spec requirements related to keyframe generation 
> existed, leading to recorded streams that sometimes contain a single 
> keyframe at the beginning of the stream. When played back those streams are 
> inefficient to seek in, and it’s impossible to excise segments from them 
> without resorting to transcoding. These problems present significant 
> hurdles to use the MR API for some applications.
>
> Link to “Intent to Prototype”
>
> N/A, small incremental change and going directly for shipping.
>
> Risks
>
> Interoperability and Compatibility
>
> This is now in the editors draft 
> https://w3c.github.io/mediacapture-record/#mediarecorder-api
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> The pull request adding this feature was reviewed and approved by the 
> WebRTC WG containing representatives from Apple, Microsoft, and Mozilla. 
> Feedback was addressed in the spec PR. But we have not reached out for 
> comments on signals.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Testability requires muxer parsers which MediaRecorder WPTs are currently 
> lacking. https://github.com/web-platform-tests/wpt/issues/39642 has been 
> filed to ensure WPTs are added when this is fixed.
>
> Tracking bug
>
> crbug.com/1371449
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5117302963437568
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e104767c-a31e-4553-ad18-1a101e33d0een%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

['Henrik Boström' via blink-dev]

Yes, I think throwing in M117, stable on Aug 30 would be even better.

On Friday, February 24, 2023 at 4:32:21 PM UTC+1 Philip Jägenstedt wrote:

> I think the overall timeline looks great, the final removal is almost a 
> year from now, after the 2023 holiday season.
>
> However, I'd like to bikeshed "Throw an exception if the trial is not used 
> in Stable in M119 (Release: October 31, 2023)". This is when the breakage 
> will be apparent to most users/developers, anyone who isn't paying 
> attention to deprecation warnings. Oct 31 doesn't give a whole lot of time 
> to figure out how origin trials work and opt into that, so I would suggest 
> M117, stable on Aug 30. That's as early as seems reasonable given summer 
> vacations in the northern hemisphere.
>
> WDYT Henrik, would that work just as well for you?
>
> On Thu, Feb 23, 2023 at 1:17 PM Yoav Weiss  wrote:
>
>> LGTM1 for that plan
>>
>> On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström  
>> wrote:
>>
>>> In that case the proposal is:
>>> - Add deprecation warning in M113 (Release: May 2, 2023) with the 
>>> possibility to opt-in to the Deprecation Trial.
>>> - Throw an exception if the trial is not used in Canary/Dev/Beta in M114.
>>> - Throw an exception if the trial is not used in Stable in M119 
>>> (Release: October 31, 2023).
>>> - Let M121 be the last version where the Trial is available (Release: 
>>> January 9, 2024). In other words the first version where the trial and 
>>> legacy getStats API is entirely removed is M122 (Release: February 6, 2024).
>>>
>>> On Thursday, February 23, 2023 at 11:38:48 AM UTC+1 Yoav Weiss wrote:
>>>
>>>> SGTM
>>>>
>>>> On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström  
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss wrote:
>>>>>
>>>>> On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström  
>>>>> wrote:
>>>>>
>>>>> OK, so deprecation warning in M113, throwing in Beta in M114 and 
>>>>> throwing in Stable on M119. We can do that.
>>>>>
>>>>>
>>>>> Awesome!
>>>>>  
>>>>>
>>>>> Under this less aggressive timeline, for how many more milestones 
>>>>> would the Deprecation Trial span?
>>>>>
>>>>>
>>>>> How much would be needed for people to schedule the work to make the 
>>>>> switch? 
>>>>>
>>>>>
>>>>> If they notice the deprecation warning they would have enough time to 
>>>>> migrate before the Deprecation Trial is even needed. If they don't, how 
>>>>> about 3 months extra?
>>>>>
>>>>>  
>>>>>
>>>>>
>>>>> I do not have any more deprecations planned on my end and I think this 
>>>>> is "standalone" enough (stats being rather specific) that in my opinion 
>>>>> it 
>>>>> should not be bundled together with anything else.
>>>>>
>>>>>
>>>>> OK, cool!
>>>>>  
>>>>>
>>>>> On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote:
>>>>>
>>>>> Hey Henrik!
>>>>>
>>>>> I think the general outline of the plan makes sense, but the timelines 
>>>>> seem too aggressive. As we've recently seen in the track stats removal, 
>>>>> there can be a time difference between the point a developer puts in the 
>>>>> work to opt-in for a deprecation trial and the point in which this work 
>>>>> reaches users.
>>>>>
>>>>> I think it would make sense to:
>>>>> * Add a deprecation warning in M113 and enable a Deprecation Trial. 
>>>>> Set a tentative removal milestone for M119.
>>>>> * Start throwing an exception up to Beta in M114 to try and get 
>>>>> people's attention
>>>>> * Broadly communicate this change is coming in multiple channels. 
>>>>> DevRel folks may be able to help there. +Paul Kinlan and +Andre 
>>>>> Bandarra for thoughts.
>>>>> * In parallel to the above, turn the usecounters into UKM 
>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm=chrom

Re: [blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

[Henrik Boström]

In that case the proposal is:
- Add deprecation warning in M113 (Release: May 2, 2023) with the 
possibility to opt-in to the Deprecation Trial.
- Throw an exception if the trial is not used in Canary/Dev/Beta in M114.
- Throw an exception if the trial is not used in Stable in M119 (Release: 
October 31, 2023).
- Let M121 be the last version where the Trial is available (Release: 
January 9, 2024). In other words the first version where the trial and 
legacy getStats API is entirely removed is M122 (Release: February 6, 2024).

On Thursday, February 23, 2023 at 11:38:48 AM UTC+1 Yoav Weiss wrote:

> SGTM
>
> On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström  wrote:
>
>>
>>
>> On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss wrote:
>>
>> On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström  
>> wrote:
>>
>> OK, so deprecation warning in M113, throwing in Beta in M114 and throwing 
>> in Stable on M119. We can do that.
>>
>>
>> Awesome!
>>  
>>
>> Under this less aggressive timeline, for how many more milestones would 
>> the Deprecation Trial span?
>>
>>
>> How much would be needed for people to schedule the work to make the 
>> switch? 
>>
>>
>> If they notice the deprecation warning they would have enough time to 
>> migrate before the Deprecation Trial is even needed. If they don't, how 
>> about 3 months extra?
>>
>>  
>>
>>
>> I do not have any more deprecations planned on my end and I think this is 
>> "standalone" enough (stats being rather specific) that in my opinion it 
>> should not be bundled together with anything else.
>>
>>
>> OK, cool!
>>  
>>
>> On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote:
>>
>> Hey Henrik!
>>
>> I think the general outline of the plan makes sense, but the timelines 
>> seem too aggressive. As we've recently seen in the track stats removal, 
>> there can be a time difference between the point a developer puts in the 
>> work to opt-in for a deprecation trial and the point in which this work 
>> reaches users.
>>
>> I think it would make sense to:
>> * Add a deprecation warning in M113 and enable a Deprecation Trial. Set a 
>> tentative removal milestone for M119.
>> * Start throwing an exception up to Beta in M114 to try and get people's 
>> attention
>> * Broadly communicate this change is coming in multiple channels. DevRel 
>> folks may be able to help there. +Paul Kinlan 
>>  and +Andre Bandarra  for thoughts.
>> * In parallel to the above, turn the usecounters into UKM 
>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm=chromium>,
>>  
>> and try to see where most usage lies. (and try to understand if it's coming 
>> from libraries with longer deployment lifecycles)
>> * Flip the switch (and be ready to revert) in M119
>>
>> I know this is a bit longer and more work than the plan you outlined, but 
>> given the few fire drills we had recently, it seems better to err on the 
>> cautious side.
>>
>> Also, do you know if more removals are planned on your side? It seems 
>> like it'd be better to "bundle" them so that library authors only have to 
>> "respin" their deployment once, rather than every few milestones.
>>  
>>
>> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström  wrote:
>>
>> *This deprecation is not to be confused with the track stats deprecation 
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, which 
>> is deprecating a small subset of the modern API. This deprecation related 
>> to the removal of the legacy API, a different API with the same name.*
>>
>> *Contact emails*
>> h...@chromium.org, h...@chromium.org
>>
>> *Specification*
>> The legacy getStats() API has no spec, no official documentation and no 
>> web platform tests.
>>
>> The modern (promise-based) version of getStats() does have a spec, but 
>> this is a different method returning different stats objects: 
>> https://w3c.github.io/webrtc-stats/
>>
>> There are lots of similarities between the modern and legacy APIs, 
>> including several metrics that are the same, but the stats report structure 
>> is different and the legacy API contains several "goog"-prefixed metrics or 
>> metrics that behave differently from the modern API.
>>
>> In 2019, a document was created outlining the differences between the 
&g

Re: [blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

[Henrik Boström]

On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss wrote:

On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström  wrote:

OK, so deprecation warning in M113, throwing in Beta in M114 and throwing 
in Stable on M119. We can do that.


Awesome!
 

Under this less aggressive timeline, for how many more milestones would the 
Deprecation Trial span?


How much would be needed for people to schedule the work to make the 
switch? 


If they notice the deprecation warning they would have enough time to 
migrate before the Deprecation Trial is even needed. If they don't, how 
about 3 months extra?

 


I do not have any more deprecations planned on my end and I think this is 
"standalone" enough (stats being rather specific) that in my opinion it 
should not be bundled together with anything else.


OK, cool!
 

On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote:

Hey Henrik!

I think the general outline of the plan makes sense, but the timelines seem 
too aggressive. As we've recently seen in the track stats removal, there 
can be a time difference between the point a developer puts in the work to 
opt-in for a deprecation trial and the point in which this work reaches 
users.

I think it would make sense to:
* Add a deprecation warning in M113 and enable a Deprecation Trial. Set a 
tentative removal milestone for M119.
* Start throwing an exception up to Beta in M114 to try and get people's 
attention
* Broadly communicate this change is coming in multiple channels. DevRel 
folks may be able to help there. +Paul Kinlan  and 
+Andre 
Bandarra  for thoughts.
* In parallel to the above, turn the usecounters into UKM 
<https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm=chromium>,
 
and try to see where most usage lies. (and try to understand if it's coming 
from libraries with longer deployment lifecycles)
* Flip the switch (and be ready to revert) in M119

I know this is a bit longer and more work than the plan you outlined, but 
given the few fire drills we had recently, it seems better to err on the 
cautious side.

Also, do you know if more removals are planned on your side? It seems like 
it'd be better to "bundle" them so that library authors only have to 
"respin" their deployment once, rather than every few milestones.
 

On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström  wrote:

*This deprecation is not to be confused with the track stats deprecation 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, which 
is deprecating a small subset of the modern API. This deprecation related 
to the removal of the legacy API, a different API with the same name.*

*Contact emails*
h...@chromium.org, h...@chromium.org

*Specification*
The legacy getStats() API has no spec, no official documentation and no web 
platform tests.

The modern (promise-based) version of getStats() does have a spec, but this 
is a different method returning different stats objects: 
https://w3c.github.io/webrtc-stats/

There are lots of similarities between the modern and legacy APIs, 
including several metrics that are the same, but the stats report structure 
is different and the legacy API contains several "goog"-prefixed metrics or 
metrics that behave differently from the modern API.

In 2019, a document was created outlining the differences between the 
legacy and modern API 
<https://docs.google.com/document/d/1z-D4SngG36WPiMuRvWeTMN7mWQXrf1XKZwVl3Nf1BIE/edit?usp=sharing>
 which 
may still be a useful resource, but for latest information we refer to the 
modern API's spec <https://w3c.github.io/webrtc-stats/> and code search 
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h>
.

*Summary*
WebRTC is a set of JavaScript APIs (spec <https://w3c.github.io/webrtc-pc/>) 
enabling real-time communication, most notably realtime audio and video for 
Video Conferencing in the browser. getStats() is an API that allow apps to 
measure things like bitrate and media quality information about the session.

The history is that spec and implementations evolved so quickly that the 
API was forked into two paths: the callback-based one that only exists in 
Chromium and has no spec and the promise-based one which has both a spec 
and pretty good cross-browser compatibility support 
<https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental=master>
.

In Chromium, the legacy API has been on feature freeze for several years 
and the goal was always to deprecate and remove it, but due to high usage 
this was not a possibility. This story is finally changing: usage graphs 
<https://webrtchacks.github.io/chromestatus/?buckets=1058,1476,1402=2022-01-01=7>
.

[image: Screenshot 2023-02-16 at 13.43.40.png]

According to chromestatus.com stats 
<https://

Re: [blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

[Henrik Boström]

OK, so deprecation warning in M113, throwing in Beta in M114 and throwing 
in Stable on M119. We can do that.
Under this less aggressive timeline, for how many more milestones would the 
Deprecation Trial span?

I do not have any more deprecations planned on my end and I think this is 
"standalone" enough (stats being rather specific) that in my opinion it 
should not be bundled together with anything else.
On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote:

> Hey Henrik!
>
> I think the general outline of the plan makes sense, but the timelines 
> seem too aggressive. As we've recently seen in the track stats removal, 
> there can be a time difference between the point a developer puts in the 
> work to opt-in for a deprecation trial and the point in which this work 
> reaches users.
>
> I think it would make sense to:
> * Add a deprecation warning in M113 and enable a Deprecation Trial. Set a 
> tentative removal milestone for M119.
> * Start throwing an exception up to Beta in M114 to try and get people's 
> attention
> * Broadly communicate this change is coming in multiple channels. DevRel 
> folks may be able to help there. +Paul Kinlan  and 
> +Andre 
> Bandarra  for thoughts.
> * In parallel to the above, turn the usecounters into UKM 
> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm=chromium>,
>  
> and try to see where most usage lies. (and try to understand if it's coming 
> from libraries with longer deployment lifecycles)
> * Flip the switch (and be ready to revert) in M119
>
> I know this is a bit longer and more work than the plan you outlined, but 
> given the few fire drills we had recently, it seems better to err on the 
> cautious side.
>
> Also, do you know if more removals are planned on your side? It seems like 
> it'd be better to "bundle" them so that library authors only have to 
> "respin" their deployment once, rather than every few milestones.
>  
>
> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström  wrote:
>
>> *This deprecation is not to be confused with the track stats deprecation 
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, which 
>> is deprecating a small subset of the modern API. This deprecation related 
>> to the removal of the legacy API, a different API with the same name.*
>>
>> *Contact emails*
>> h...@chromium.org, h...@chromium.org
>>
>> *Specification*
>> The legacy getStats() API has no spec, no official documentation and no 
>> web platform tests.
>>
>> The modern (promise-based) version of getStats() does have a spec, but 
>> this is a different method returning different stats objects: 
>> https://w3c.github.io/webrtc-stats/
>>
>> There are lots of similarities between the modern and legacy APIs, 
>> including several metrics that are the same, but the stats report structure 
>> is different and the legacy API contains several "goog"-prefixed metrics or 
>> metrics that behave differently from the modern API.
>>
>> In 2019, a document was created outlining the differences between the 
>> legacy and modern API 
>> <https://docs.google.com/document/d/1z-D4SngG36WPiMuRvWeTMN7mWQXrf1XKZwVl3Nf1BIE/edit?usp=sharing>
>>  which 
>> may still be a useful resource, but for latest information we refer to the 
>> modern API's spec <https://w3c.github.io/webrtc-stats/> and code search 
>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h>
>> .
>>
>> *Summary*
>> WebRTC is a set of JavaScript APIs (spec 
>> <https://w3c.github.io/webrtc-pc/>) enabling real-time communication, 
>> most notably realtime audio and video for Video Conferencing in the 
>> browser. getStats() is an API that allow apps to measure things like 
>> bitrate and media quality information about the session.
>>
>> The history is that spec and implementations evolved so quickly that the 
>> API was forked into two paths: the callback-based one that only exists in 
>> Chromium and has no spec and the promise-based one which has both a spec 
>> and pretty good cross-browser compatibility support 
>> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental=master>
>> .
>>
>> In Chromium, the legacy API has been on feature freeze for several years 
>> and the goal was always to deprecate and remove it, but due to high usage 
>> this was not a possibility. This story is finally ch

[blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

[Henrik Boström]

*This deprecation is not to be confused with the track stats deprecation 
, which 
is deprecating a small subset of the modern API. This deprecation related 
to the removal of the legacy API, a different API with the same name.*

*Contact emails*
h...@chromium.org, h...@chromium.org

*Specification*
The legacy getStats() API has no spec, no official documentation and no web 
platform tests.

The modern (promise-based) version of getStats() does have a spec, but this 
is a different method returning different stats objects: 
https://w3c.github.io/webrtc-stats/

There are lots of similarities between the modern and legacy APIs, 
including several metrics that are the same, but the stats report structure 
is different and the legacy API contains several "goog"-prefixed metrics or 
metrics that behave differently from the modern API.

In 2019, a document was created outlining the differences between the 
legacy and modern API 

 which 
may still be a useful resource, but for latest information we refer to the 
modern API's spec  and code search 

.

*Summary*
WebRTC is a set of JavaScript APIs (spec ) 
enabling real-time communication, most notably realtime audio and video for 
Video Conferencing in the browser. getStats() is an API that allow apps to 
measure things like bitrate and media quality information about the session.

The history is that spec and implementations evolved so quickly that the 
API was forked into two paths: the callback-based one that only exists in 
Chromium and has no spec and the promise-based one which has both a spec 
and pretty good cross-browser compatibility support 

.

In Chromium, the legacy API has been on feature freeze for several years 
and the goal was always to deprecate and remove it, but due to high usage 
this was not a possibility. This story is finally changing: usage graphs 

.

[image: Screenshot 2023-02-16 at 13.43.40.png]

According to chromestatus.com stats 
,
- RTCPeerConnectionGetStatsLegacyNonCompliant is 0.0183% and
- RTCPeerConnectionGetStats is 0.2177% of page loads.
In other words, legacy is 8% as popular as modern.

According to UMA stats,
- RTCPeerConnectionGetStatsLegacyNonCompliant is 0.000177% and
- RTCPeerConnectionGetStats is 0.00114% of page loads.
In other words, legacy is 15% as popular as modern.

I don't know why UMAs and chromestatus shows different orders of magnitude 
when it comes to usage, but we're roughly talking about the legacy API 
being 1/10th as popular as the modern API. I think it is time to add a 
deprecation warning to the legacy API.

*Risks*
Usage is still high and migrating from the legacy API to the modern API may 
require a significant amount of work from developers.

To mitigate this, we should have a long deprecation timeline and allow 
developers to opt-in to a Deprecation Trial to get more time.

*Proposal*
Add a deprecation warning in M113 and the possibility to opt-in to a 
deprecation trial.
Add use counts for how many of the legacy API uses do and do not use the 
deprecation trial and track this over time.

In M114, start throwing an exception in Canary/Beta if attempting to use 
the legacy API outside the trial *but do not throw* in Stable yet. Give 
apps more time to sign up to the trial.

In M115, gently roll out the throwing of the exception to Stable, i.e. from 
this milestone onwards apps are required to use the deprecation trial if 
they want to continue to use the legacy getStats() API.

M115 is Stable on June 27.
Set the Deprecation Trial end date to M120 / December 5, 2023.
This gives apps paying attention to the deprecation warning ~9 months to 
migrate and apps only paying attention to exceptions on stable ~6 months to 
migrate.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

Proposal based on our meeting:
- Requesting to make this ENABLED_BY_DEFAULT in M112 but to have a Reverse 
Origin Trial available with an end date date 3 milestones out: M115.

On Tuesday, February 7, 2023 at 10:19:35 PM UTC+1 Chris Thompson wrote:

> > Do we have trackable statistics on the usage of corporate policies?
> > ie if nobody uses the policy in 2 milestones, can we detect that and 
> decide that it is not needed and delete it, or will we be as unsure as we 
> are now?
>
> It is quite common in my experience to handle removals with an enterprise 
> policy that is stated upfront to be temporary (i.e., the enterprise release 
> notes give a deadline milestone), with no metrics needed.
>
> On Tue, Feb 7, 2023 at 1:17 PM 'Manjesh Malavalli' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi team,
>>
>> Thank you for postponing the rollout to M112. This gives our customers 
>> some time to migrate to the newest version of the Twilio Video SDK, which 
>> does not depend on the removed stats. We will do an internal post-mortem 
>> regarding why our tests did not catch this sooner and make the necessary 
>> corrections on our end.
>>
>> Thanks,
>>
>> Manjesh
>>
>> On Tuesday, February 7, 2023 at 2:36:43 AM UTC-8 Henrik Boström wrote:
>>
>>> I have the same concern as Harald regarding corporate policies. Why not 
>>> a Deprecation Origin Trial in that case for list of users and more concrete 
>>> timeline?
>>>
>>> On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:
>>>
>>>> Do we have trackable statistics on the usage of corporate policies?
>>>> ie if nobody uses the policy in 2 milestones, can we detect that and 
>>>> decide that it is not needed and delete it, or will we be as unsure as we 
>>>> are now?
>>>>
>>>>
>>>> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  
>>>> wrote:
>>>>
>>> We don't know what we don't know, but it's not hard to imagine an 
>>>>> in-house enterprise WebRTC application that is using "stats" or "track". 
>>>>> Twilio is the breakage we know about (because a developer took the time 
>>>>> to 
>>>>> report a bug). Having a policy so an app continues to work while a fix is 
>>>>> made is a good thing - and comes with the nice side effect of appearing 
>>>>> on 
>>>>> the Enterprise release notes, increasing awareness.
>>>>>
>>>>> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>>>>>
>>>> What's the imagined scenario in which an enterprise policy would be 
>>>>> useful? 
>>>>>
>>>>> The only place I could imagine it being relevant is if there exists a 
>>>>> WebRTC application that is only used within a single enterprise (neither 
>>>>> hosting nor usage exists outside the enterprise), and that WebRTC 
>>>>> application depends on non-upgraded Twilio libraries.
>>>>>
>>>>> I don't know that we have evidence that such applications exist.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  
>>>>> wrote:
>>>>>
>>>>> I agree with Johnny that an enterprise policy would be useful, at 
>>>>>> least for a few milestones.
>>>>>>
>>>>>> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>>>>>>
>>>>> I'm not sure an enterprise policy is appropriate - I see the same 
>>>>>> problem with sunsetting the policy as with sunsetting the stat in 
>>>>>> general, 
>>>>>> and usage of enterprise policies is (as far as I know) far more opaque 
>>>>>> to 
>>>>>> us than origin trials or Finch feature usage. 
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback 
>>>>>>> wrote:
>>>>>>> Is there an enterprise policy in place for this deprecation already? 
>>>>>>> If not, adding one seems appropriate given the challenges of rolling 
>>>>>>> out 
>>>>>>> even simple fixes in some enterprise environments.

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

I have the same concern as Harald regarding corporate policies. Why not a 
Deprecation Origin Trial in that case for list of users and more concrete 
timeline?

On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:

> Do we have trackable statistics on the usage of corporate policies?
> ie if nobody uses the policy in 2 milestones, can we detect that and 
> decide that it is not needed and delete it, or will we be as unsure as we 
> are now?
>
>
> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:
>
>> We don't know what we don't know, but it's not hard to imagine an 
>> in-house enterprise WebRTC application that is using "stats" or "track". 
>> Twilio is the breakage we know about (because a developer took the time to 
>> report a bug). Having a policy so an app continues to work while a fix is 
>> made is a good thing - and comes with the nice side effect of appearing on 
>> the Enterprise release notes, increasing awareness.
>>
>> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>>
>> What's the imagined scenario in which an enterprise policy would be 
>> useful? 
>>
>> The only place I could imagine it being relevant is if there exists a 
>> WebRTC application that is only used within a single enterprise (neither 
>> hosting nor usage exists outside the enterprise), and that WebRTC 
>> application depends on non-upgraded Twilio libraries.
>>
>> I don't know that we have evidence that such applications exist.
>>
>>
>>
>> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  
>> wrote:
>>
>>> I agree with Johnny that an enterprise policy would be useful, at least 
>>> for a few milestones.
>>>
>>> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>>>
>>> I'm not sure an enterprise policy is appropriate - I see the same 
>>> problem with sunsetting the policy as with sunsetting the stat in general, 
>>> and usage of enterprise policies is (as far as I know) far more opaque to 
>>> us than origin trials or Finch feature usage. 
>>>
>>>
>>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  
>>> wrote:
>>>
>>>>
>>>>
>>>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>>>> Is there an enterprise policy in place for this deprecation already? If 
>>>> not, adding one seems appropriate given the challenges of rolling out even 
>>>> simple fixes in some enterprise environments.
>>>>
>>>> One does not exist at the moment but I can add one 
>>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
>>>> .
>>>>
>>>>
>>>> Thanks,
>>>> Johnny
>>>>
>>>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  
>>>> wrote:
>>>> Delaying the enabled-by-default to M112 is fine by me but I'll wait for 
>>>> a resolution here before taking action. Currently it is enabled-by-default 
>>>> in Canary.
>>>>
>>>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 
>>>> philipp...@googlemail.com wrote:
>>>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>>>> h...@chromium.org>:
>>>> *Contact emails* 
>>>> h...@chromium.org, h...@chromium.org
>>>>
>>>> *Background*
>>>> I attempted to remove this feature before but had forgotten to file an 
>>>> intent to deprecate, background here 
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
>>>>
>>>> *Specification*
>>>> The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and 
>>>> it contains all the metrics. The deprecated metrics are also listed, but 
>>>> in 
>>>> the obsolete section 
>>>> <https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
>>>>  
>>>> There's an open issue to remove obsolete metrics from the spec as soon as 
>>>> they are unshipped from modern browsers. This is considered a blocker for 
>>>> the document to reach Proposed Recommendation status.
>>>>
>>>> *Summary*
>>>> WebRTC is a set of JavaScript APIs (spec 
>>>> <https://w3c.github.io/webrtc-pc/>) that allow real-time communication 
>>>> between browsers. For the relevant metrics being removed, we're only 
>>>> talking about the WebRTC use 

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

That makes sense, I'll work on a revert of the enabled-by-default soon.

By the looks of this comment 
<https://github.com/twilio/twilio-video.js/issues/1968#issuecomment-1412982869> 
it 
sounds like Twilio has released a fix to the bug, but I assume it will take 
some time for users to update their library.

On Wednesday, February 1, 2023 at 4:35:03 PM UTC+1 Yoav Weiss wrote:

> Enabling by default on Canary and then turning it off right before branch 
> could definitely be a good way to get lab testers that test on Canary be 
> aware of this.
> At the same time, the release managers may not be excited about it, 
> because it reduces Canary's testing relevance.
>
> Maybe we can settle on having this enabled at the early stages of the 
> Canary milestone, and then revert as we approach Beta?
>
> On Wed, Feb 1, 2023 at 11:49 AM Henrik Boström  wrote:
>
>> Ping. Does my proposal to do enabled-by-default (so that testing 
>> environments don't miss this again) prior to having ramped this up to 100% 
>> make sense or is that considered bad practise?
>> Current status is ENABLED_BY_DEFAULT in M111 (currently Canary), which 
>> would need to be reverted if we either want to delay this to M112 or not do 
>> ENABLED_BY_DEFAULT at all until 100% launch.
>>
>>
>> On Tuesday, January 31, 2023 at 12:45:20 PM UTC+1 Henrik Boström wrote:
>>
>>> On Tuesday, January 31, 2023 at 11:39:36 AM UTC+1 Yoav Weiss wrote:
>>> Thanks for filing an intent and moving the trial to 0% on stable.
>>>
>>> From responses on the other thread, it seems like there may be a few 
>>> months of lag between the time developers notice this upcoming change and 
>>> the time it'd reach users.
>>> Do you know if a 3P deprecation trial would have better deployment 
>>> latency?
>>>
>>> If a 3P deprecation trial still requires the affected websites to get 
>>> the latest version of the affected library in order to get that trial then, 
>>> if I understand correctly, I don't think this will help because it sounds 
>>> like the next version of Twilio will contain the fix for this in which case 
>>> the trial would not be needed.
>>>
>>> It sounds like it is just a matter of waiting for updates to be pushed, 
>>> but please correct me if I'm wrong about this +Anna and if a trial would 
>>> help.
>>>  
>>>
>>> On Mon, Jan 30, 2023 at 11:20 AM Henrik Boström  
>>> wrote:
>>>
>>>
>>> On Monday, January 30, 2023 at 11:16:59 AM UTC+1 Harald Alvestrand wrote:
>>> I'm not sure an enterprise policy is appropriate - I see the same 
>>> problem with sunsetting the policy as with sunsetting the stat in general, 
>>> and usage of enterprise policies is (as far as I know) far more opaque to 
>>> us than origin trials or Finch feature usage.
>>>
>>> Oh, we definitely don't want that. If a flag is needed (other than the 
>>> Finch one) then I would much rather do a Reverse Origin Trial in that case. 
>>> I still think that has limited value but if that mitigates concerns then 
>>> I'm supportive of it.
>>>
>>>
>>>
>>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  
>>> wrote:
>>>
>>>
>>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>>> Is there an enterprise policy in place for this deprecation already? If 
>>> not, adding one seems appropriate given the challenges of rolling out even 
>>> simple fixes in some enterprise environments.
>>>
>>> One does not exist at the moment but I can add one 
>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
>>> .
>>>
>>>
>>> Thanks,
>>> Johnny
>>>
>>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  
>>> wrote:
>>> Delaying the enabled-by-default to M112 is fine by me but I'll wait for 
>>> a resolution here before taking action. Currently it is enabled-by-default 
>>> in Canary.
>>>
>>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 
>>> philipp...@googlemail.com wrote:
>>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>>> h...@chromium.org>:
>>> *Contact emails*
>>> h...@chromium.org, h...@chromium.org
>>>
>>> *Background*
>>> I attempted to remove this feature before but had forgotten to file an 
>>> intent to deprecate, background here 
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIk

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

Ping. Does my proposal to do enabled-by-default (so that testing 
environments don't miss this again) prior to having ramped this up to 100% 
make sense or is that considered bad practise?
Current status is ENABLED_BY_DEFAULT in M111 (currently Canary), which 
would need to be reverted if we either want to delay this to M112 or not do 
ENABLED_BY_DEFAULT at all until 100% launch.


On Tuesday, January 31, 2023 at 12:45:20 PM UTC+1 Henrik Boström wrote:

> On Tuesday, January 31, 2023 at 11:39:36 AM UTC+1 Yoav Weiss wrote:
> Thanks for filing an intent and moving the trial to 0% on stable.
>
> From responses on the other thread, it seems like there may be a few 
> months of lag between the time developers notice this upcoming change and 
> the time it'd reach users.
> Do you know if a 3P deprecation trial would have better deployment latency?
>
> If a 3P deprecation trial still requires the affected websites to get the 
> latest version of the affected library in order to get that trial then, if 
> I understand correctly, I don't think this will help because it sounds like 
> the next version of Twilio will contain the fix for this in which case the 
> trial would not be needed.
>
> It sounds like it is just a matter of waiting for updates to be pushed, 
> but please correct me if I'm wrong about this +Anna and if a trial would 
> help.
>  
>
> On Mon, Jan 30, 2023 at 11:20 AM Henrik Boström  wrote:
>
>
> On Monday, January 30, 2023 at 11:16:59 AM UTC+1 Harald Alvestrand wrote:
> I'm not sure an enterprise policy is appropriate - I see the same problem 
> with sunsetting the policy as with sunsetting the stat in general, and 
> usage of enterprise policies is (as far as I know) far more opaque to us 
> than origin trials or Finch feature usage.
>
> Oh, we definitely don't want that. If a flag is needed (other than the 
> Finch one) then I would much rather do a Reverse Origin Trial in that case. 
> I still think that has limited value but if that mitigates concerns then 
> I'm supportive of it.
>
>
>
> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  wrote:
>
>
> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
> Is there an enterprise policy in place for this deprecation already? If 
> not, adding one seems appropriate given the challenges of rolling out even 
> simple fixes in some enterprise environments.
>
> One does not exist at the moment but I can add one 
> <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
> .
>
>
> Thanks,
> Johnny
>
> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:
> Delaying the enabled-by-default to M112 is fine by me but I'll wait for a 
> resolution here before taking action. Currently it is enabled-by-default in 
> Canary.
>
> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com 
> wrote:
> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
> h...@chromium.org>:
> *Contact emails*
> h...@chromium.org, h...@chromium.org
>
> *Background*
> I attempted to remove this feature before but had forgotten to file an 
> intent to deprecate, background here 
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
>
> *Specification*
> The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and 
> it contains all the metrics. The deprecated metrics are also listed, but in 
> the obsolete section 
> <https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
>  
> There's an open issue to remove obsolete metrics from the spec as soon as 
> they are unshipped from modern browsers. This is considered a blocker for 
> the document to reach Proposed Recommendation status.
>
> *Summary*
> WebRTC is a set of JavaScript APIs (spec 
> <https://w3c.github.io/webrtc-pc/>) that allow real-time communication 
> between browsers. For the relevant metrics being removed, we're only 
> talking about the WebRTC use case that is sending or receiving audio or 
> video (typically Video Conferencing use cases), not the data channel use 
> cases that is a popular WebRTC use case, since data channel only use cases 
> would never have any tracks/streams.
>
> RTCPeerConnection.getStats() returns a map of string-to-objects, where 
> each object is one of the dictionaries defined in the stats spec. The 
> reason an app calls getStats() is mostly to report quality metrics (send 
> and receive resolutions, bitrates, glitches, video QP, etc) which can be 
> important for A/B experimentation. It can also be used in a way that 
> impacts app logic or even UX inside the app. Most common use case I can 
> think of: poll getStats() at 10 Hz and render 

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

On Tuesday, January 31, 2023 at 11:39:36 AM UTC+1 Yoav Weiss wrote:
Thanks for filing an intent and moving the trial to 0% on stable.

>From responses on the other thread, it seems like there may be a few months 
of lag between the time developers notice this upcoming change and the time 
it'd reach users.
Do you know if a 3P deprecation trial would have better deployment latency?

If a 3P deprecation trial still requires the affected websites to get the 
latest version of the affected library in order to get that trial then, if 
I understand correctly, I don't think this will help because it sounds like 
the next version of Twilio will contain the fix for this in which case the 
trial would not be needed.

It sounds like it is just a matter of waiting for updates to be pushed, but 
please correct me if I'm wrong about this +Anna and if a trial would help.
 

On Mon, Jan 30, 2023 at 11:20 AM Henrik Boström  wrote:


On Monday, January 30, 2023 at 11:16:59 AM UTC+1 Harald Alvestrand wrote:
I'm not sure an enterprise policy is appropriate - I see the same problem 
with sunsetting the policy as with sunsetting the stat in general, and 
usage of enterprise policies is (as far as I know) far more opaque to us 
than origin trials or Finch feature usage.

Oh, we definitely don't want that. If a flag is needed (other than the 
Finch one) then I would much rather do a Reverse Origin Trial in that case. 
I still think that has limited value but if that mitigates concerns then 
I'm supportive of it.



On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  wrote:


On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
Is there an enterprise policy in place for this deprecation already? If 
not, adding one seems appropriate given the challenges of rolling out even 
simple fixes in some enterprise environments.

One does not exist at the moment but I can add one 
<https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
.


Thanks,
Johnny

On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:
Delaying the enabled-by-default to M112 is fine by me but I'll wait for a 
resolution here before taking action. Currently it is enabled-by-default in 
Canary.

On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com 
wrote:
Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström :
*Contact emails*
h...@chromium.org, h...@chromium.org

*Background*
I attempted to remove this feature before but had forgotten to file an 
intent to deprecate, background here 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.

*Specification*
The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and 
it contains all the metrics. The deprecated metrics are also listed, but in 
the obsolete section 
<https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
 
There's an open issue to remove obsolete metrics from the spec as soon as 
they are unshipped from modern browsers. This is considered a blocker for 
the document to reach Proposed Recommendation status.

*Summary*
WebRTC is a set of JavaScript APIs (spec <https://w3c.github.io/webrtc-pc/>) 
that allow real-time communication between browsers. For the relevant 
metrics being removed, we're only talking about the WebRTC use case that is 
sending or receiving audio or video (typically Video Conferencing use 
cases), not the data channel use cases that is a popular WebRTC use case, 
since data channel only use cases would never have any tracks/streams.

RTCPeerConnection.getStats() returns a map of string-to-objects, where each 
object is one of the dictionaries defined in the stats spec. The reason an 
app calls getStats() is mostly to report quality metrics (send and receive 
resolutions, bitrates, glitches, video QP, etc) which can be important for 
A/B experimentation. It can also be used in a way that impacts app logic or 
even UX inside the app. Most common use case I can think of: poll 
getStats() at 10 Hz and render volume bars for each participant based on 
volume levels from stats objects.

The deprecation in question is to remove some stats objects that were made 
obsolete several years ago: all metrics on the "track" dictionary have been 
moved to non-obsolete objects ("inbound-rtp", "outbound-rtp", 
"media-source"). Reasons for wanting to deprecate include:

   - Spec-compliance: needed for browser implementations to align and for 
   the spec to become Proposed Recommendation.
   - Web compat: Firefox never implement "track" or "steam" 
   
<https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental=master>
 due 
   to them being obsolete.
   - Performance: the duplicated metrics make up ~40% of the stats report 
   size, which can be a significant number of bytes in larger meetings and it 
   is common for apps to poll getStats() 10 ti

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Henrik Boström' via blink-dev]

Yes, the experiment has been rolled back on Stable. Note that users need to
restart their browser to get the new config.

On Mon, Jan 30, 2023 at 11:22 PM Sudheer Boynapally 
wrote:

> Hi Henrik,
>
> Just want to confirm if this is rolled-back today at 9am PST ?
>
>
> On Sat, Jan 28, 2023 at 1:59 AM Henrik Boström  wrote:
>
>> Hi Anna, yes the experiment is being rolled back to 0% Stable (it's still
>> 50% on Canary/Beta though).
>> The rollback has already been submitted, but unfortunately we must wait
>> for the next config push. I'm told this happens on *Monday, 9AM Pacific
>> Time*. Users will need to restart their browser to get the config.
>>
>> In preparation for the next rollout, I've filed the much needed intent to
>> deprecate here:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8.
>> Please provide input on the proposed plans.
>> On Saturday, January 28, 2023 at 12:45:00 AM UTC+1 Anna Vasilko wrote:
>>
>>> Hi Henrik,
>>> Just wanted to double check that the latest plan is to revert the
>>> experiment, correct? Asking because there was somewhat different comment on
>>> the PR here
>>> <https://github.com/twilio/twilio-video.js/pull/1970#issuecomment-1404596109>
>>> .
>>> At Twilio we really hope the experiment can be reverted asap given that
>>> it is breaking for our customers and their end users in the wild. The
>>> adoption of our new sdk release (with the above PR change) will take long
>>> time for most of the customers as they need to 1) learn about the issue 2)
>>> pick-up the new sdk version 3) roll out their applications with the new sdk
>>> version. For some customers it takes months.
>>> Basically the only way to really stop the breaking impact is to stop the
>>> experiment and give some notice and time to adopt the changes.
>>>
>>> I have to acknowledge it took surprisingly long time for us to discover
>>> this breaking change and act on it. Holidays probably played a role here.
>>> But we will do a retrospective internally to understand the reasons better
>>> and to catch such issues sooner in the future.
>>>
>>> On Friday, January 27, 2023 at 12:57:38 AM UTC-8 Henrik Boström wrote:
>>>
>>>> I'll roll it back and file an intent to deprecate thread. It was a big
>>>> mistake that I forgot to do that in the first place, and it's unfortunate
>>>> that we have to roll this back. But I take having reached 50% Stable and
>>>> only knowing for sure about Twilio as a positive sign (if this was very
>>>> widespread we would have heard about it earlier than we did). Still it
>>>> seems like Finch is a problem for Selenium test environments in that it's
>>>> possible to run test code for several months without noticing a feature is
>>>> on. That's a bit sad.
>>>>
>>>> On Thursday, January 26, 2023 at 8:46:19 PM UTC+1 Sudheer Boynapally
>>>> wrote:
>>>>
>>>>> Is the experiment rolled back on January 25th ? or it is still at 50%
>>>>> stable for M 109?
>>>>>
>>>>> On Thu, Jan 26, 2023 at 10:47 AM Alex Russell 
>>>>> wrote:
>>>>>
>>>>>> It appears this change is causing breakage at scale, including for
>>>>>> our partners.
>>>>>>
>>>>>> Given how this is going, I'd like to suggest the following course of
>>>>>> action:
>>>>>>
>>>>>>- Turn down the Finch rollout to 0% immediately
>>>>>>- Revert the change in 111
>>>>>>- File an intent-to-deprecate here ASAP w/ whatever data on
>>>>>>compat we can gather (as it looks like usecounters won't work) so we 
>>>>>> can
>>>>>>discuss a new plan to land this
>>>>>>
>>>>>> We have options that might be more suitable (e.g., reverse OT), or
>>>>>> maybe the change just needs devrel in wider channels + time to breathe.
>>>>>> Either way, backing off of this rollout seems like the right thing to do.
>>>>>> In future, web-visible WebRTC changes also need to come through the main
>>>>>> Blink intents process. Let's start down that path now.
>>>>>>
>>>>>> Curious for other API OWNERs feedback, so cc-ing
>>>>>> blink-api-owners-discuss@.
>>>>>>
>>>>>> Best,
>>>>>>
>>>&g

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

On Monday, January 30, 2023 at 11:16:59 AM UTC+1 Harald Alvestrand wrote:
I'm not sure an enterprise policy is appropriate - I see the same problem 
with sunsetting the policy as with sunsetting the stat in general, and 
usage of enterprise policies is (as far as I know) far more opaque to us 
than origin trials or Finch feature usage.

Oh, we definitely don't want that. If a flag is needed (other than the 
Finch one) then I would much rather do a Reverse Origin Trial in that case. 
I still think that has limited value but if that mitigates concerns then 
I'm supportive of it.



On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  wrote:


On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
Is there an enterprise policy in place for this deprecation already? If 
not, adding one seems appropriate given the challenges of rolling out even 
simple fixes in some enterprise environments.

One does not exist at the moment but I can add one 
<https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
.


Thanks,
Johnny

On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:
Delaying the enabled-by-default to M112 is fine by me but I'll wait for a 
resolution here before taking action. Currently it is enabled-by-default in 
Canary.

On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com 
wrote:
Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström :
*Contact emails*
h...@chromium.org, h...@chromium.org

*Background*
I attempted to remove this feature before but had forgotten to file an 
intent to deprecate, background here 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.

*Specification*
The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and 
it contains all the metrics. The deprecated metrics are also listed, but in 
the obsolete section 
<https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
 
There's an open issue to remove obsolete metrics from the spec as soon as 
they are unshipped from modern browsers. This is considered a blocker for 
the document to reach Proposed Recommendation status.

*Summary*
WebRTC is a set of JavaScript APIs (spec <https://w3c.github.io/webrtc-pc/>) 
that allow real-time communication between browsers. For the relevant 
metrics being removed, we're only talking about the WebRTC use case that is 
sending or receiving audio or video (typically Video Conferencing use 
cases), not the data channel use cases that is a popular WebRTC use case, 
since data channel only use cases would never have any tracks/streams.

RTCPeerConnection.getStats() returns a map of string-to-objects, where each 
object is one of the dictionaries defined in the stats spec. The reason an 
app calls getStats() is mostly to report quality metrics (send and receive 
resolutions, bitrates, glitches, video QP, etc) which can be important for 
A/B experimentation. It can also be used in a way that impacts app logic or 
even UX inside the app. Most common use case I can think of: poll 
getStats() at 10 Hz and render volume bars for each participant based on 
volume levels from stats objects.

The deprecation in question is to remove some stats objects that were made 
obsolete several years ago: all metrics on the "track" dictionary have been 
moved to non-obsolete objects ("inbound-rtp", "outbound-rtp", 
"media-source"). Reasons for wanting to deprecate include:

   - Spec-compliance: needed for browser implementations to align and for 
   the spec to become Proposed Recommendation.
   - Web compat: Firefox never implement "track" or "steam" 
   
<https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental=master>
 due 
   to them being obsolete.
   - Performance: the duplicated metrics make up ~40% of the stats report 
   size, which can be a significant number of bytes in larger meetings and it 
   is common for apps to poll getStats() 10 times per second.
   - Tech debt: unblock removal of 1400 LOC.

In the meantime, the obsolete metrics is duplicated in several places of 
the stats report.

*Risks*
*- Impossible to properly measure usage*
Because stats objects are exposed as JavaScript dictionaries, and because 
apps have to iterate all objects of the stats report in order to find the 
ones they are interested in or if they just dump all the data without 
filtering, there is no way to measure how big the dependency is on track in 
the real world.

While we lack use counters, we have some positive signs:

   - Because Firefox does not have "track" or "stream" stats, any app that 
   can run on Firefox already exercises the paths of these not existing.


   - An experiment to "unship deprecated metrics" has been running at 50% 
   Canary since October 
   
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/m/3i

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
Is there an enterprise policy in place for this deprecation already? If 
not, adding one seems appropriate given the challenges of rolling out even 
simple fixes in some enterprise environments.

One does not exist at the moment but I can add one 
<https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
.


Thanks,
Johnny

On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:
Delaying the enabled-by-default to M112 is fine by me but I'll wait for a 
resolution here before taking action. Currently it is enabled-by-default in 
Canary.

On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com 
wrote:
Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström :
*Contact emails*
h...@chromium.org, h...@chromium.org

*Background*
I attempted to remove this feature before but had forgotten to file an 
intent to deprecate, background here 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.

*Specification*
The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and 
it contains all the metrics. The deprecated metrics are also listed, but in 
the obsolete section 
<https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
 
There's an open issue to remove obsolete metrics from the spec as soon as 
they are unshipped from modern browsers. This is considered a blocker for 
the document to reach Proposed Recommendation status.

*Summary*
WebRTC is a set of JavaScript APIs (spec <https://w3c.github.io/webrtc-pc/>) 
that allow real-time communication between browsers. For the relevant 
metrics being removed, we're only talking about the WebRTC use case that is 
sending or receiving audio or video (typically Video Conferencing use 
cases), not the data channel use cases that is a popular WebRTC use case, 
since data channel only use cases would never have any tracks/streams.

RTCPeerConnection.getStats() returns a map of string-to-objects, where each 
object is one of the dictionaries defined in the stats spec. The reason an 
app calls getStats() is mostly to report quality metrics (send and receive 
resolutions, bitrates, glitches, video QP, etc) which can be important for 
A/B experimentation. It can also be used in a way that impacts app logic or 
even UX inside the app. Most common use case I can think of: poll 
getStats() at 10 Hz and render volume bars for each participant based on 
volume levels from stats objects.

The deprecation in question is to remove some stats objects that were made 
obsolete several years ago: all metrics on the "track" dictionary have been 
moved to non-obsolete objects ("inbound-rtp", "outbound-rtp", 
"media-source"). Reasons for wanting to deprecate include:

   - Spec-compliance: needed for browser implementations to align and for 
   the spec to become Proposed Recommendation.
   - Web compat: Firefox never implement "track" or "steam" 
   
<https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental=master>
 due 
   to them being obsolete.
   - Performance: the duplicated metrics make up ~40% of the stats report 
   size, which can be a significant number of bytes in larger meetings and it 
   is common for apps to poll getStats() 10 times per second.
   - Tech debt: unblock removal of 1400 LOC.

In the meantime, the obsolete metrics is duplicated in several places of 
the stats report.

*Risks*
*- Impossible to properly measure usage*
Because stats objects are exposed as JavaScript dictionaries, and because 
apps have to iterate all objects of the stats report in order to find the 
ones they are interested in or if they just dump all the data without 
filtering, there is no way to measure how big the dependency is on track in 
the real world.

While we lack use counters, we have some positive signs:

   - Because Firefox does not have "track" or "stream" stats, any app that 
   can run on Firefox already exercises the paths of these not existing.


   - An experiment to "unship deprecated metrics" has been running at 50% 
   Canary since October 
   
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/m/3iqjODsMBwAJ>,
 
   giving developers testing Canary a heads-up. Nobody complained until the 
   experiment reached Stable.
   - We got to 50% Stable in M109 and while we're in the process of rolling 
   it back now due to breaking twilio-video.js 
   <https://github.com/twilio/twilio-video.js/issues/1968>, it's 
   interesting to note that this is the only breakage we are aware of (that 
   does not mean there aren't more breakages, but I believe this at least says 
   something about the severity).

*- Selenium et al typically starts browsers from fresh profiles and hence 
does not know the finch trial seed*
The most likely expla

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Henrik Boström' via blink-dev]

Hi Anna, yes the experiment is being rolled back to 0% Stable (it's still 
50% on Canary/Beta though).
The rollback has already been submitted, but unfortunately we must wait for 
the next config push. I'm told this happens on *Monday, 9AM Pacific Time*. 
Users will need to restart their browser to get the config.

In preparation for the next rollout, I've filed the much needed intent to 
deprecate 
here: https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8. 
Please provide input on the proposed plans.
On Saturday, January 28, 2023 at 12:45:00 AM UTC+1 Anna Vasilko wrote:

> Hi Henrik,
> Just wanted to double check that the latest plan is to revert the 
> experiment, correct? Asking because there was somewhat different comment on 
> the PR here 
> <https://github.com/twilio/twilio-video.js/pull/1970#issuecomment-1404596109>
> . 
> At Twilio we really hope the experiment can be reverted asap given that it 
> is breaking for our customers and their end users in the wild. The adoption 
> of our new sdk release (with the above PR change) will take long time for 
> most of the customers as they need to 1) learn about the issue 2) pick-up 
> the new sdk version 3) roll out their applications with the new sdk 
> version. For some customers it takes months. 
> Basically the only way to really stop the breaking impact is to stop the 
> experiment and give some notice and time to adopt the changes. 
>
> I have to acknowledge it took surprisingly long time for us to discover 
> this breaking change and act on it. Holidays probably played a role here. 
> But we will do a retrospective internally to understand the reasons better 
> and to catch such issues sooner in the future. 
>
> On Friday, January 27, 2023 at 12:57:38 AM UTC-8 Henrik Boström wrote:
>
>> I'll roll it back and file an intent to deprecate thread. It was a big 
>> mistake that I forgot to do that in the first place, and it's unfortunate 
>> that we have to roll this back. But I take having reached 50% Stable and 
>> only knowing for sure about Twilio as a positive sign (if this was very 
>> widespread we would have heard about it earlier than we did). Still it 
>> seems like Finch is a problem for Selenium test environments in that it's 
>> possible to run test code for several months without noticing a feature is 
>> on. That's a bit sad.
>>
>> On Thursday, January 26, 2023 at 8:46:19 PM UTC+1 Sudheer Boynapally 
>> wrote:
>>
>>> Is the experiment rolled back on January 25th ? or it is still at 50% 
>>> stable for M 109?
>>>
>>> On Thu, Jan 26, 2023 at 10:47 AM Alex Russell  
>>> wrote:
>>>
>>>> It appears this change is causing breakage at scale, including for our 
>>>> partners.
>>>>
>>>> Given how this is going, I'd like to suggest the following course of 
>>>> action:
>>>>
>>>>- Turn down the Finch rollout to 0% immediately
>>>>- Revert the change in 111
>>>>- File an intent-to-deprecate here ASAP w/ whatever data on compat 
>>>>we can gather (as it looks like usecounters won't work) so we can 
>>>> discuss a 
>>>>new plan to land this
>>>>
>>>> We have options that might be more suitable (e.g., reverse OT), or 
>>>> maybe the change just needs devrel in wider channels + time to breathe. 
>>>> Either way, backing off of this rollout seems like the right thing to do. 
>>>> In future, web-visible WebRTC changes also need to come through the main 
>>>> Blink intents process. Let's start down that path now.
>>>>
>>>> Curious for other API OWNERs feedback, so cc-ing 
>>>> blink-api-owners-discuss@.
>>>>
>>>> Best,
>>>>
>>>> Alex
>>>>
>>>> On Wed, Jan 25, 2023 at 10:04 PM Henrik Boström  
>>>> wrote:
>>>>
>>>>> The track and stream removal experiment is at 50% Stable for M109. On 
>>>>> January 23rd it went from 10% to 50%. The intent is to ramp up to 100%.
>>>>> Which experiment group you end up with (have or not have the 
>>>>> deprecated stats) are chosen with a dice roll every time the user 
>>>>> restarts 
>>>>> their browser.
>>>>>
>>>>> In M111 (which is currently Canary) the removal is enabled-by-default 
>>>>> so in that version there is no dependency on getting finch configs pushed 
>>>>> anymore.
>>>>>
>>>>> On Thu, Jan 26, 2023 at 12:52 AM Sudheer Boynapally <
>>>>> 

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

Delaying the enabled-by-default to M112 is fine by me but I'll wait for a 
resolution here before taking action. Currently it is enabled-by-default in 
Canary.

On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com 
wrote:

> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
> h...@chromium.org>:
>
>> *Contact emails*
>> h...@chromium.org, h...@chromium.org
>>
>> *Background*
>> I attempted to remove this feature before but had forgotten to file an 
>> intent to deprecate, background here 
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
>>
>> *Specification*
>> The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and 
>> it contains all the metrics. The deprecated metrics are also listed, but in 
>> the obsolete section 
>> <https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
>>  
>> There's an open issue to remove obsolete metrics from the spec as soon as 
>> they are unshipped from modern browsers. This is considered a blocker for 
>> the document to reach Proposed Recommendation status.
>>
>> *Summary*
>> WebRTC is a set of JavaScript APIs (spec 
>> <https://w3c.github.io/webrtc-pc/>) that allow real-time communication 
>> between browsers. For the relevant metrics being removed, we're only 
>> talking about the WebRTC use case that is sending or receiving audio or 
>> video (typically Video Conferencing use cases), not the data channel use 
>> cases that is a popular WebRTC use case, since data channel only use cases 
>> would never have any tracks/streams.
>>
>> RTCPeerConnection.getStats() returns a map of string-to-objects, where 
>> each object is one of the dictionaries defined in the stats spec. The 
>> reason an app calls getStats() is mostly to report quality metrics (send 
>> and receive resolutions, bitrates, glitches, video QP, etc) which can be 
>> important for A/B experimentation. It can also be used in a way that 
>> impacts app logic or even UX inside the app. Most common use case I can 
>> think of: poll getStats() at 10 Hz and render volume bars for each 
>> participant based on volume levels from stats objects.
>>
>> The deprecation in question is to remove some stats objects that were 
>> made obsolete several years ago: all metrics on the "track" dictionary have 
>> been moved to non-obsolete objects ("inbound-rtp", "outbound-rtp", 
>> "media-source"). Reasons for wanting to deprecate include:
>>
>>- Spec-compliance: needed for browser implementations to align and 
>>for the spec to become Proposed Recommendation.
>>- Web compat: Firefox never implement "track" or "steam" 
>>
>> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental=master>
>>  due 
>>to them being obsolete.
>>- Performance: the duplicated metrics make up ~40% of the stats 
>>report size, which can be a significant number of bytes in larger 
>> meetings 
>>and it is common for apps to poll getStats() 10 times per second.
>>- Tech debt: unblock removal of 1400 LOC.
>>
>> In the meantime, the obsolete metrics is duplicated in several places of 
>> the stats report.
>>
>> *Risks*
>> *- Impossible to properly measure usage*
>> Because stats objects are exposed as JavaScript dictionaries, and because 
>> apps have to iterate all objects of the stats report in order to find the 
>> ones they are interested in or if they just dump all the data without 
>> filtering, there is no way to measure how big the dependency is on track in 
>> the real world.
>>
>> While we lack use counters, we have some positive signs:
>>
>>- Because Firefox does not have "track" or "stream" stats, any app 
>>that can run on Firefox already exercises the paths of these not existing.
>>
>>
>>- An experiment to "unship deprecated metrics" has been running at 50% 
>>Canary since October 
>>
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/m/3iqjODsMBwAJ>,
>>  
>>giving developers testing Canary a heads-up. Nobody complained until the 
>>experiment reached Stable.
>>- We got to 50% Stable in M109 and while we're in the process of 
>>rolling it back now due to breaking twilio-video.js 
>><https://github.com/twilio/twilio-video.js/issues/1968>, it's 
>>interesting to note that this is the o

[blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

*Contact emails*
h...@chromium.org, h...@chromium.org

*Background*
I attempted to remove this feature before but had forgotten to file an 
intent to deprecate, background here 
.

*Specification*
The getStats() API spec is here  and 
it contains all the metrics. The deprecated metrics are also listed, but in 
the obsolete section 
.
 
There's an open issue to remove obsolete metrics from the spec as soon as 
they are unshipped from modern browsers. This is considered a blocker for 
the document to reach Proposed Recommendation status.

*Summary*
WebRTC is a set of JavaScript APIs (spec ) 
that allow real-time communication between browsers. For the relevant 
metrics being removed, we're only talking about the WebRTC use case that is 
sending or receiving audio or video (typically Video Conferencing use 
cases), not the data channel use cases that is a popular WebRTC use case, 
since data channel only use cases would never have any tracks/streams.

RTCPeerConnection.getStats() returns a map of string-to-objects, where each 
object is one of the dictionaries defined in the stats spec. The reason an 
app calls getStats() is mostly to report quality metrics (send and receive 
resolutions, bitrates, glitches, video QP, etc) which can be important for 
A/B experimentation. It can also be used in a way that impacts app logic or 
even UX inside the app. Most common use case I can think of: poll 
getStats() at 10 Hz and render volume bars for each participant based on 
volume levels from stats objects.

The deprecation in question is to remove some stats objects that were made 
obsolete several years ago: all metrics on the "track" dictionary have been 
moved to non-obsolete objects ("inbound-rtp", "outbound-rtp", 
"media-source"). Reasons for wanting to deprecate include:

   - Spec-compliance: needed for browser implementations to align and for 
   the spec to become Proposed Recommendation.
   - Web compat: Firefox never implement "track" or "steam" 
   

 due 
   to them being obsolete.
   - Performance: the duplicated metrics make up ~40% of the stats report 
   size, which can be a significant number of bytes in larger meetings and it 
   is common for apps to poll getStats() 10 times per second.
   - Tech debt: unblock removal of 1400 LOC.

In the meantime, the obsolete metrics is duplicated in several places of 
the stats report.

*Risks*
*- Impossible to properly measure usage*
Because stats objects are exposed as JavaScript dictionaries, and because 
apps have to iterate all objects of the stats report in order to find the 
ones they are interested in or if they just dump all the data without 
filtering, there is no way to measure how big the dependency is on track in 
the real world.

While we lack use counters, we have some positive signs:

   - Because Firefox does not have "track" or "stream" stats, any app that 
   can run on Firefox already exercises the paths of these not existing.
   - An experiment to "unship deprecated metrics" has been running at 50% 
   Canary since October 
   
,
 
   giving developers testing Canary a heads-up. Nobody complained until the 
   experiment reached Stable.
   - We got to 50% Stable in M109 and while we're in the process of rolling 
   it back now due to breaking twilio-video.js 
   , it's 
   interesting to note that this is the only breakage we are aware of (that 
   does not mean there aren't more breakages, but I believe this at least says 
   something about the severity).

*- Selenium et al typically starts browsers from fresh profiles and hence 
does not know the finch trial seed*
The most likely explanation for breakage is not testing Canary or test 
environments not having access to Finch experiments. This makes the 
behavior on Stable a surprise.

*- To have a Reverse Origin Trial or not to have a Reverse Origin Trial?*
Migrating should require so few lines of code (look for stats.type == 
'inbound-rtp' instead of stats.type == 'track', for example) that it seems 
to be a bigger hurdle for a developer to enroll in the trial than to simply 
fix their code.

*- Compatiblity risk*
There is one particular metric out of all metrics that, if you run Safari, 
does not exist on "inbound-rtp" yet. This can be a problem, but again is 
probably not a big problem because this particular metric was never 
implemented on Firefox so apps already need to survive without it, and it 
is very easy to write a fallback path for the Safari case:

let trackIdentifer = null;  // In Firefox this will never be set regardless.
if 

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Henrik Boström' via blink-dev]

I'll roll it back and file an intent to deprecate thread. It was a big 
mistake that I forgot to do that in the first place, and it's unfortunate 
that we have to roll this back. But I take having reached 50% Stable and 
only knowing for sure about Twilio as a positive sign (if this was very 
widespread we would have heard about it earlier than we did). Still it 
seems like Finch is a problem for Selenium test environments in that it's 
possible to run test code for several months without noticing a feature is 
on. That's a bit sad.

On Thursday, January 26, 2023 at 8:46:19 PM UTC+1 Sudheer Boynapally wrote:

> Is the experiment rolled back on January 25th ? or it is still at 50% 
> stable for M 109?
>
> On Thu, Jan 26, 2023 at 10:47 AM Alex Russell  
> wrote:
>
>> It appears this change is causing breakage at scale, including for our 
>> partners.
>>
>> Given how this is going, I'd like to suggest the following course of 
>> action:
>>
>>- Turn down the Finch rollout to 0% immediately
>>- Revert the change in 111
>>- File an intent-to-deprecate here ASAP w/ whatever data on compat we 
>>can gather (as it looks like usecounters won't work) so we can discuss a 
>>new plan to land this
>>
>> We have options that might be more suitable (e.g., reverse OT), or maybe 
>> the change just needs devrel in wider channels + time to breathe. Either 
>> way, backing off of this rollout seems like the right thing to do. In 
>> future, web-visible WebRTC changes also need to come through the main Blink 
>> intents process. Let's start down that path now.
>>
>> Curious for other API OWNERs feedback, so cc-ing 
>> blink-api-owners-discuss@.
>>
>> Best,
>>
>> Alex
>>
>> On Wed, Jan 25, 2023 at 10:04 PM Henrik Boström  wrote:
>>
>>> The track and stream removal experiment is at 50% Stable for M109. On 
>>> January 23rd it went from 10% to 50%. The intent is to ramp up to 100%.
>>> Which experiment group you end up with (have or not have the deprecated 
>>> stats) are chosen with a dice roll every time the user restarts their 
>>> browser.
>>>
>>> In M111 (which is currently Canary) the removal is enabled-by-default so 
>>> in that version there is no dependency on getting finch configs pushed 
>>> anymore.
>>>
>>> On Thu, Jan 26, 2023 at 12:52 AM Sudheer Boynapally  
>>> wrote:
>>>
>>>> Was there any change on January 23rd corresponding to this? like 
>>>> rolling out this deprecation?
>>>>
>>>> Thanks,
>>>> On Wednesday, January 25, 2023 at 2:57:16 PM UTC-8 Sudheer Boynapally 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is the deprecation of 'track' and 'stream' objects completed 100% on 
>>>>> all the versions of chrome v109 or any specific sub version of 109? 
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> On Tuesday, January 10, 2023 at 5:56:04 AM UTC-8 Henrik Boström wrote:
>>>>>
>>>>>> On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  
>>>>>> wrote:
>>>>>>
>>>>>>> +Henrik Boström - was there an intent sent for this removal? Any 
>>>>>>> form of developer communication?
>>>>>>>
>>>>>>
>>>>>> There was developer communication dating as far back as July but I 
>>>>>> admit I had forgotten to send out a formal blink-dev intent to deprecate!
>>>>>>
>>>>>> - I should have done that.
>>>>>>
>>>>>> The getStats() API in question is not being deprecated, but the 
>>>>>> RTCStatsReport (an id-to-stats-object map) report will stop containing 
>>>>>> the 
>>>>>> stats object which were made obsolete in the spec several years ago due 
>>>>>> to 
>>>>>> the contents of these stats objects having been moved to other stats 
>>>>>> objects that are still being returned. Same values, different location. 
>>>>>> In 
>>>>>> other words, the report is being trimmed down by removing duplicate 
>>>>>> information. Stats processing code in an application is gated on stats 
>>>>>> type 
>>>>>> for knowing which metrics to look for on an individual stats object 
>>>>>> which 
>>>>>> should make this lower risk compared to other depracations. Th

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Henrik Boström' via blink-dev]

The track and stream removal experiment is at 50% Stable for M109. On
January 23rd it went from 10% to 50%. The intent is to ramp up to 100%.
Which experiment group you end up with (have or not have the deprecated
stats) are chosen with a dice roll every time the user restarts their
browser.

In M111 (which is currently Canary) the removal is enabled-by-default so in
that version there is no dependency on getting finch configs pushed anymore.

On Thu, Jan 26, 2023 at 12:52 AM Sudheer Boynapally 
wrote:

> Was there any change on January 23rd corresponding to this? like rolling
> out this deprecation?
>
> Thanks,
> On Wednesday, January 25, 2023 at 2:57:16 PM UTC-8 Sudheer Boynapally
> wrote:
>
>> Hi,
>>
>> Is the deprecation of 'track' and 'stream' objects completed 100% on all
>> the versions of chrome v109 or any specific sub version of 109?
>>
>> Thanks,
>>
>>
>> On Tuesday, January 10, 2023 at 5:56:04 AM UTC-8 Henrik Boström wrote:
>>
>>> On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  wrote:
>>>
>>>> +Henrik Boström - was there an intent sent for this removal? Any form
>>>> of developer communication?
>>>>
>>>
>>> There was developer communication dating as far back as July but I admit
>>> I had forgotten to send out a formal blink-dev intent to deprecate!
>>>
>>> - I should have done that.
>>>
>>> The getStats() API in question is not being deprecated, but the
>>> RTCStatsReport (an id-to-stats-object map) report will stop containing the
>>> stats object which were made obsolete in the spec several years ago due to
>>> the contents of these stats objects having been moved to other stats
>>> objects that are still being returned. Same values, different location. In
>>> other words, the report is being trimmed down by removing duplicate
>>> information. Stats processing code in an application is gated on stats type
>>> for knowing which metrics to look for on an individual stats object which
>>> should make this lower risk compared to other depracations. The motivation
>>> for this is performance optimizations (~40% report size reduction),
>>> technical debt reduction (-1400 LOC) and web compat ("track" does not
>>> exist in Firefox <https://webrtc-stats.callstats.io/verify/>).
>>>
>>> The communication channel used was WebRTC's official google group,
>>> discuss-webrtc <https://groups.google.com/g/discuss-webrtc>. History:
>>>
>>>- July 25, 2022 PSA
>>><https://groups.google.com/g/discuss-webrtc/c/lfkFCY2CFco> announced
>>>the plan to deprecate at a milestone TBD. This was also the time where 
>>> the
>>>"DEPRECATED_" prefix was added to the JavaScript-exposed stats object 
>>> IDs,
>>>which made it into M106. The deprecation prefix is also visible in the
>>>chrome://webrtc-internals/ developer page when a page uses WebRTC.
>>>- There was another PSA on September 6, 2022
>>><https://groups.google.com/g/discuss-webrtc/c/mmudYReualE> about
>>>other stats news with a reminder of the imminent stats deprecation.
>>>- The October 19, 2022 PSA
>>><https://groups.google.com/g/discuss-webrtc/c/R7Mcux9RK6g> announced
>>>"track" stats being removed at 50% Canary.
>>>- The follow-up October 27, 2022 PSA
>>><https://groups.google.com/g/discuss-webrtc/c/9c8ZjberEcI> announced
>>>it would also be removed at 50% Beta (where M109 Beta was released on
>>>December 1st). This PSA also clarifies that "The goal is to continue
>>>ramping it up on Stable when M109 is released".
>>>- Lastly we have yesterday's PSA
>>><https://groups.google.com/g/discuss-webrtc/c/Bxrxr8gw08Y> announcing
>>>that the removal was advanced to 1% Stable which this conversation is a
>>>response to.
>>>
>>>
>>>> On Mon, Jan 9, 2023 at 9:42 PM Alex Russell 
>>>> wrote:
>>>>
>>>>> Thanks for adding blink-dev, Philipp. CC-ing the API OWNERs as this
>>>>> seems related to a pattern of breaking changes without Blink intents that
>>>>> we've been informed of by customers.
>>>>>
>>>>> Do I understand correctly that this deprecation is being managed via
>>>>> Finch for 109 Stable?
>>>>>
>>>>
>>> Yes, as to minimize risk of breakage the deprecation is managed via a
>>> Fin

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Henrik Boström' via blink-dev]

On Tue, Jan 10, 2023 at 8:51 AM Yoav Weiss  wrote:

> +Henrik Boström  - was there an intent sent for this
> removal? Any form of developer communication?
>

There was developer communication dating as far back as July but I admit I
had forgotten to send out a formal blink-dev intent to deprecate!

- I should have done that.

The getStats() API in question is not being deprecated, but the
RTCStatsReport (an id-to-stats-object map) report will stop containing the
stats object which were made obsolete in the spec several years ago due to
the contents of these stats objects having been moved to other stats
objects that are still being returned. Same values, different location. In
other words, the report is being trimmed down by removing duplicate
information. Stats processing code in an application is gated on stats type
for knowing which metrics to look for on an individual stats object which
should make this lower risk compared to other depracations. The motivation
for this is performance optimizations (~40% report size reduction),
technical debt reduction (-1400 LOC) and web compat ("track" does not exist
in Firefox <https://webrtc-stats.callstats.io/verify/>).

The communication channel used was WebRTC's official google group,
discuss-webrtc <https://groups.google.com/g/discuss-webrtc>. History:

   - July 25, 2022 PSA
   <https://groups.google.com/g/discuss-webrtc/c/lfkFCY2CFco> announced the
   plan to deprecate at a milestone TBD. This was also the time where the
   "DEPRECATED_" prefix was added to the JavaScript-exposed stats object IDs,
   which made it into M106. The deprecation prefix is also visible in the
   chrome://webrtc-internals/ developer page when a page uses WebRTC.
   - There was another PSA on September 6, 2022
   <https://groups.google.com/g/discuss-webrtc/c/mmudYReualE> about other
   stats news with a reminder of the imminent stats deprecation.
   - The October 19, 2022 PSA
   <https://groups.google.com/g/discuss-webrtc/c/R7Mcux9RK6g> announced
   "track" stats being removed at 50% Canary.
   - The follow-up October 27, 2022 PSA
   <https://groups.google.com/g/discuss-webrtc/c/9c8ZjberEcI> announced it
   would also be removed at 50% Beta (where M109 Beta was released on December
   1st). This PSA also clarifies that "The goal is to continue ramping it up
   on Stable when M109 is released".
   - Lastly we have yesterday's PSA
   <https://groups.google.com/g/discuss-webrtc/c/Bxrxr8gw08Y> announcing
   that the removal was advanced to 1% Stable which this conversation is a
   response to.


> On Mon, Jan 9, 2023 at 9:42 PM Alex Russell 
> wrote:
>
>> Thanks for adding blink-dev, Philipp. CC-ing the API OWNERs as this seems
>> related to a pattern of breaking changes without Blink intents that we've
>> been informed of by customers.
>>
>> Do I understand correctly that this deprecation is being managed via
>> Finch for 109 Stable?
>>
>
Yes, as to minimize risk of breakage the deprecation is managed via a Finch
flag, which is currently 1% Stable + 50% Canary/Beta.
To my knowledge, no issues have been reported since the rollout started in
Canary in November, 2022 or "DEPRECATED_" prefix was added in July, 2022.
This, combined with the fact that apps usually gate on type, is why I
thought it would be safe to gently roll out further to Stable.


>
>> Best,
>>
>> Alex
>>
>>
On Tue, Jan 10, 2023 at 12:34 AM 'Aaron Boushley' via blink-dev <
blink-dev@chromium.org> wrote:

> Can you help me understand exactly which objects are being removed here?
> We rely on `RTCPeerConnection.getStats()` although we pass in a stream
> selector. We then iterate over the returned stats reports looking for ones
> containing the values we need.
>

The selector (be it an RTCRtpSender, RTCRtpReceiver or MediaStreamTrack)
continues to work, it's just that the report no longer contains the removed
stats objects.


>
> Is this a removal of the stats objects that have the fixed ID of "track"
> and "stream"?
>

It is the removal of the stats objects where .type == "track" or .type ==
"stream".
In the spec this refers to dictionaries RTCMediaStreamTrackStats
<https://w3c.github.io/webrtc-stats/#dom-rtcmediastreamtrackstats> and
RTCMediaStreamStats
<https://w3c.github.io/webrtc-stats/#dom-rtcmediastreamstats> which are
part of the "Obsolete" section of the spec. See RTCStatsType
<https://w3c.github.io/webrtc-stats/#rtcstatstype-str*> for complete list
of stats object types.

Regarding the track stats dictionary, the same metrics are still available,
but you have to look at the non-deprecated locations:
RTCOutboundRtpStreamStats
<https://w3c.github.io/webrtc-stats/#outboundrtpstats-dict*> and
RTCInboundRtpStreamStats
<https://w

[blink-dev] Re: Is end date of “Trial for RTCPeerConnection Plan B SDP Semantics” could be postpone?

['Henrik Boström' via blink-dev]

Hi,

See recent conversations over 
at https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/35NFPYdumMs 
for more details but the short answer is that the trial will not be 
extended.

On Thursday, May 12, 2022 at 6:59:38 PM UTC+2 hank...@gmail.com wrote:

> Hi:
>
>  we had an system still use plan B solution, is any chance or solution 
> postpone plan B ?
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c342370-2d06-40e4-bf90-421b6f5f61e3n%40chromium.org.

Re: [blink-dev] Intent to Experiment: Reverse Origin Trial for WebRTC's Plan B SDP semantics

[Henrik Boström]

> Our video system still uses Plan B SDP, and we find that if we use 
chrome(M89), the video still can work normally now
> So, if we don't upgrade the browser, will it be affected after May 25th?

That's correct, in M89 Plan B was always allowed and the Deprecation Trial 
did not exist yet. So even after the trial ends, M89 will still continue to 
support Plan B.
The deprecation/removal of Plan B only affects more recent versions than 
that.

> However, we cannot make it before May 25th. Is there any alternative? 
Thanks!

It's not possible to extend the trial because the M102 stable release 
candidate does not contain the deprecation trial flag anymore. To be clear:
- In M101, attempting to set sdpSemantics to "plan-b" without a trial or 
after the trial has ended *throws an exception*.
- In M102, sdpSemantics is *ignored* and you get "unified-plan" even if you 
ask for "plan-b" (regardless of trial status). M102 stable release is 
scheduled for May 24, rollout happens gradually.

So there will be no way of getting Plan B on recent versions using any API.
Incidentally, you can still change the default SDP semantics (what you get 
when it is not overriden by the sdpSemantics API) using a command line flag 
*if* you're launching Chrome from a command line:
--disable-features=RTCUnifiedPlanByDefault
Obviously this is not something normal web users would do (and it would 
affect all websites) so I'm not sure this helps, but FYI that exists in 
case you're in control of the user's environment.

Also as a side note - the exact removal timeline is a little different on 
CrOS than other platforms due to a bug in a dependency, but CrOS is also 
sensitive to trial ending and the trial not existing in M102. More info at 
https://crbug.com/1327544.

On Thursday, May 19, 2022 at 10:36:56 PM UTC+2 luk19...@gmail.com wrote:

> Hi,
>
> Continue V Chang's Problem.
> Our video system still uses Plan B SDP, and we find that if we use 
> chrome(M89), the video still can work normally now
> So, if we don't upgrade the browser, will it be affected after May 25th? 
> It's very important for us, I am looking forward to your reply, thank you!
>
> V Chang 在 2022年5月13日 星期五上午12:59:28 [UTC+8] 的信中寫道：
>
>> Hi Henrik,
>>
>> Yes. We have an big issue on fixing the problem to run without this 
>> trial, which will cause our end users not be able to make video call to 
>> call center for banking service. 
>> We are still working on fixing the problem. However, we cannot make it 
>> before May 25th. Is there any alternative? Thanks!
>>
>>
>> Henrik Boström 在 2022年5月12日 星期四下午2:26:43 [UTC+8] 的信中寫道：
>>
>>> UMAs show Plan B usage is down to 0.0473% and we already extended 
>>> the deprecation trial by 6 months for those who did not notice the 1 year 
>>> warning/canary exception prior to that. Because of this, support for Plan B 
>>> including the Plan B deprecation trial flag was removed in M102 which is 
>>> currently Beta and soon getting its Stable cut.
>>>
>>> Big issue? Are you not able to migrate in time?
>>>
>>> On Thu, 12 May 2022 at 04:47, V Chang  wrote:
>>>
>>>> [Urgent Support]
>>>> Hi, 
>>>> Is there any possibility to extend the Trial for RTCPeerConnection Plan 
>>>> B SDP Semantics?
>>>> We are helping our client on the call center video solution. However, 
>>>> we have a big issue regarding this trial support end on May 25th 2022.  
>>>> Please advise. Thank you for your support in advance.
>>>>
>>>>
>>>>
>>>> Web Development 在 2021年12月17日 星期五上午12:22:55 [UTC+8] 的信中寫道：
>>>>
>>>>> I registered for  RTCPeerConnection Plan B SDP Semantics   and 
>>>>> everything working fine in windows and android chrome browser.
>>>>> But  in android webView it showing Origin trial "UNKNOWN 
>>>>> ValidTokenNotProvided"
>>>>> Does it support in android system webview?
>>>>>
>>>>> On Friday, July 30, 2021 at 2:25:18 AM UTC+5:30 mike...@chromium.org 
>>>>> wrote:
>>>>>
>>>>>> Hi Abhi,
>>>>>>
>>>>>> Assuming you're looking for the deprecation trial ("reverse origin 
>>>>>> trial") for Plan B SDP semantics, 
>>>>>> https://developer.chrome.com/origintrials/#/view_trial/3892235977954951169
>>>>>>  
>>>>>> should be the right link.
>>>>>>
>>>>>> (there's no visual differentiation between regular and deprecation 
>>>>>> trials in the UI, but maybe that wou

Re: [blink-dev] Re: Intent to Prototype: [WebRTC] Deprecate and Remove mediaConstraint's googIPv6

['Henrik Boström' via blink-dev]

Hey thanks, delay in response due to vacation but I'm back now.

> According to followup to the request, the deprecation message is already 
in 102, possibly without ever having been documented. I don't know if you 
want to mention it in 103 instead.

 The deprecation warning I added in M102 did not mention any specific 
timeline, only that it is deprecated and one should stop using it.
I did sent out a PSA on a webrtc specific google group but this is the 
first I am writing about it on blink-dev, sorry if I skipped a step there.

> I have you down for 108.

Perfect.

> Make sure you you add the removal date to the deprecation message if it's 
not already there.

I will update the message to say M108 as the target.


On Monday, May 16, 2022 at 5:01:34 PM UTC+2 Joe Medley wrote:

> I really can't. That's why I have to be such a nag about when something is 
> going out.
>
> I have you down for 108.
>
> Thanks.
> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Thu, May 12, 2022 at 1:50 PM Daniel Bratell  wrote:
>
>> (not the implementor) According to followup to the request, the 
>> deprecation message is already in 102, possibly without ever having been 
>> documented. I don't know if you want to mention it in 103 instead.
>>
>> The removal we approved is for 108.
>>
>> /Daniel
>>
>>
>> On 2022-05-12 16:59, 'Joe Medley' via blink-dev wrote:
>>
>> Pinging this again. In two weeks I need to write what's in 103 beta on 
>> https://blog.chromium.org (https://blog.chromium.org/search/label/beta). 
>> Will deprecation be in 103?
>>
>> On Tuesday, May 10, 2022 at 12:27:49 PM UTC-7 jmedley via Chromestatus 
>> wrote:
>>
>>> In which version are you hoping to deprecate? remove?
>>>
>> -- 
>> 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 on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6e0f6cd-9e74-4a77-bbf4-3ffdf6c3607bn%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/00a8452a-97f0-47fe-b6d8-bc125195451en%40chromium.org.

Re: [blink-dev] Intent to Experiment: Reverse Origin Trial for WebRTC's Plan B SDP semantics

['Henrik Boström' via blink-dev]

UMAs show Plan B usage is down to 0.0473% and we already extended the
deprecation trial by 6 months for those who did not notice the 1 year
warning/canary exception prior to that. Because of this, support for Plan B
including the Plan B deprecation trial flag was removed in M102 which is
currently Beta and soon getting its Stable cut.

Big issue? Are you not able to migrate in time?

On Thu, 12 May 2022 at 04:47, V Chang  wrote:

> [Urgent Support]
> Hi,
> Is there any possibility to extend the Trial for RTCPeerConnection Plan B
> SDP Semantics?
> We are helping our client on the call center video solution. However, we
> have a big issue regarding this trial support end on May 25th 2022.  Please
> advise. Thank you for your support in advance.
>
>
>
> Web Development 在 2021年12月17日 星期五上午12:22:55 [UTC+8] 的信中寫道：
>
>> I registered for  RTCPeerConnection Plan B SDP Semantics   and everything
>> working fine in windows and android chrome browser.
>> But  in android webView it showing Origin trial "UNKNOWN
>> ValidTokenNotProvided"
>> Does it support in android system webview?
>>
>> On Friday, July 30, 2021 at 2:25:18 AM UTC+5:30 mike...@chromium.org
>> wrote:
>>
>>> Hi Abhi,
>>>
>>> Assuming you're looking for the deprecation trial ("reverse origin
>>> trial") for Plan B SDP semantics,
>>> https://developer.chrome.com/origintrials/#/view_trial/3892235977954951169
>>> should be the right link.
>>>
>>> (there's no visual differentiation between regular and deprecation
>>> trials in the UI, but maybe that would be a nice feature to add)
>>>
>>> later,
>>> Mike
>>>
>>> On 7/29/21 3:44 AM, 'Abhi Shanmu' via blink-dev wrote:
>>>
>>> Hi,
>>>
>>> I am unable to find reverse origin trial listed in this page for me to
>>> register.
>>> https://developer.chrome.com/origintrials/#/trials/active
>>> How can I register my domains for the reverse origin trial?
>>> Thanks,
>>> Abhi
>>> On Thursday, July 8, 2021 at 5:00:06 PM UTC+1 Yash Gogia wrote:
>>>
>>>> Hi,
>>>>
>>>> The guide that talks about origin trials, mentions that there is a
>>>> built-in safeguard that automatically disables an experimental feature
>>>> globally if its usage exceeds 0.5% of all Chrome page loads.
>>>>
>>>> Source:
>>>> https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#3-what-happens-if-a-large-site-such-as-a-google-service-starts-depending-on-an-experimental-feature
>>>>
>>>> I would like to understand if this applies to reverse origin trials as
>>>> well. From chrome status, it looks like the usage is hovering around 0.2%
>>>> already and I am sure many more websites would add the trial as the August
>>>> date for Chrome 93 approaches. A confirmation that this automatic cutoff
>>>> would not apply to the reverse origin trial would give us a lot more
>>>> confidence.
>>>>
>>>> Thanks,
>>>> Yash
>>>> On Friday, 5 March 2021 at 23:18:03 UTC+5:30 Joe Medley wrote:
>>>>
>>>>> Thank you!
>>>>>
>>>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>>>>> 816-678-7195 <(816)%20678-7195>
>>>>> *If an API's not documented it doesn't exist.*
>>>>>
>>>>>
>>>>> On Fri, Mar 5, 2021 at 6:47 AM Henrik Boström 
>>>>> wrote:
>>>>>
>>>>>> OK, I filed https://www.chromestatus.com/feature/5823036655665152
>>>>>>
>>>>>> On Tuesday, March 2, 2021 at 3:45:06 PM UTC+1 Joe Medley wrote:
>>>>>>
>>>>>>> To be clear, Chrome Status isn't extra. It's a tool for creating
>>>>>>> intents and it tries to help you get everything needed for that. The 
>>>>>>> option
>>>>>>> for Feature deprecation contains a stage for a reverse origin trial.
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>>>>>>> 816-678-7195 <(816)%20678-7195>
>>>>>>> *If an API's not documented it doesn't exist.*
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 2, 2021 at 6:40 AM Joe Medley  wrote:
>>>>>>>
>>>>

[blink-dev] Re: Intent to Deprecate: RTCPeerConnection's googIPv6 constraint

[Henrik Boström]

I'm already displaying a deprecation warning when "googIPv6: false" is 
used. The warning was added in M102 (currently Beta).
In terms of deprecation timeline, I'd like to remove this in ~6 months. 
M108 is released on November 29, 2022. I suggest we target that milestone.

On Tuesday, May 10, 2022 at 3:15:32 PM UTC+2 Henrik Boström wrote:

> Primary eng (and PM) emails
> h...@chromium.org, h...@chromium.org
>
> Summary
> WebRTC allows sending and receiving audio, video and arbitrary data 
> between two endpoints using the RTCPeerConnection API.
>
> The googIPv6 constraint was originally added to opt-in to IPv6 support 
> while that was in development, but IPv6 support has subsequently been 
> enabled-by-default for many years. While setting googIPv6 to true is a 
> NO-OP, some users make use of this non-standard API to disable IPv6 by 
> setting it to false.
>
> Motivation
> A spec-compliant WebRTC implementation supports IPv6 and has no way to 
> disable IPv6. Non-chromium browsers does not have an ability to disable 
> IPv6, so this constraint is not good for interop.
>
> We want to remove googIPv6 because a) it's non-standard, and b) it resides 
> in a dictionary argument of the RTCPeerConnection called mediaConstraints 
> that is also non-standard. The existence of googIPv6 prevents us from 
> removing mediaConstraints.
>
> Interoperability and Compatibility Risk
> The other browser vendors have been very supportive of removing 
> non-standard WebRTC APIs in the past, but I have not reached out to any 
> browser vendor specifically about googIPv6.
>
> Alternative implementation suggestion for web developers
> N/A.
>
> Usage information from UseCounter
> The LegacyConstraintGoogIPv6 use counter 
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/mediastream/media_constraints_impl.cc;l=379;drc=66fb5c89fa76a7b89983dd6c08e7f67aed1d0999>
>  suggests 0.000112% 
> of page loads use this feature by setting it to false (setting it to true 
> is a NO-OP and not counted here).
>
> Entry on the feature dashboard
> https://chromestatus.com/feature/5184046454800384
>
>
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ac2ba002-b13a-4c17-b26c-ea38f8ae33b1n%40chromium.org.

[blink-dev] Intent to Deprecate: RTCPeerConnection's googIPv6 constraint

[Henrik Boström]

Primary eng (and PM) emails
h...@chromium.org, h...@chromium.org

Summary
WebRTC allows sending and receiving audio, video and arbitrary data between 
two endpoints using the RTCPeerConnection API.

The googIPv6 constraint was originally added to opt-in to IPv6 support 
while that was in development, but IPv6 support has subsequently been 
enabled-by-default for many years. While setting googIPv6 to true is a 
NO-OP, some users make use of this non-standard API to disable IPv6 by 
setting it to false.

Motivation
A spec-compliant WebRTC implementation supports IPv6 and has no way to 
disable IPv6. Non-chromium browsers does not have an ability to disable 
IPv6, so this constraint is not good for interop.

We want to remove googIPv6 because a) it's non-standard, and b) it resides 
in a dictionary argument of the RTCPeerConnection called mediaConstraints 
that is also non-standard. The existence of googIPv6 prevents us from 
removing mediaConstraints.

Interoperability and Compatibility Risk
The other browser vendors have been very supportive of removing 
non-standard WebRTC APIs in the past, but I have not reached out to any 
browser vendor specifically about googIPv6.

Alternative implementation suggestion for web developers
N/A.

Usage information from UseCounter
The LegacyConstraintGoogIPv6 use counter 

 suggests 0.000112% 
of page loads use this feature by setting it to false (setting it to true 
is a NO-OP and not counted here).

Entry on the feature dashboard
https://chromestatus.com/feature/5184046454800384



-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/620fe211-41ed-4257-ac5b-d36eecb20c94n%40chromium.org.

Re: [blink-dev] Request for (Extending) Deprecation Trial: [WebRTC] Deprecate and Remove Plan B

[Henrik Boström]

On Thursday, November 18, 2021 at 5:27:14 PM UTC+1 Daniel Bratell wrote:

> I'm sure this can be extended, but just a couple of questions.
>
> 1. Do you have a link to the usage counter?
>
Links from Chrome Platform Status:
According to this data, Plan B usage is this 0.23% of overall WebRTC usage, 
(Plan B usage / (Plan B + Unified Plan usage)).

Unified Plan usage: 7.497188%
https://www.chromestatus.com/metrics/feature/popularity#RTCPeerConnectionConstructedWithUnifiedPlan
Plan B usage: 0.01732%
https://www.chromestatus.com/metrics/feature/popularity#RTCPeerConnectionConstructedWithPlanB

Links from UMA pages:
According to this data, Plan B usage is 0.5-0.8% of overall WebRTC usage.

The measure of "complex" SDP, i.e. the type of SDP that has compatibility 
issues between Unified Plan and Plan B, is 0.5% of overall usage according 
to UMA:
https://uma.googleplex.com/p/chrome/timeline_v2?sid=7dcca6fc2206a505d294d751929d13b5

The overall Plan B usage of the sdpSemantics attribute, regardless of SDP 
complexity, is 0.8%:
https://uma.googleplex.com/p/chrome/timeline_v2?sid=1e78b551689e230b00528fe0c621dd7e

>
> 2. What feedback have you had during the deprecation /reverse origin trial 
> so far?
>

Early in the trial I got feedback that file:// URLs needed to be able to 
use Plan B because local files cannot sign up for Deprecation Trial, so we 
made it so that local files can use Plan B during the trial.
In email conversations with affected companies, usually they communicated a 
timeline and they kept to it, providing no feedback, just migrating 
successfully without reporting issues.
In one instance a bug was found and communicated via email, and I fixed a 
couple of bugs filled on crbug before the trial, but I have gotten no 
reports since ~M93.
I was contacted by one company who was unaware of the deprecation recently, 
and extending the Deprecation Trial was the result of that exchange.

/Daniel
> On 2021-11-18 11:57, Henrik Boström wrote:
>
> *Contact emails* 
> h...@chromium.org, h...@chromium.org, h...@chromium.org
>
> *Specification*
> WebRTC is a W3C Recommendation and multiple IETF standards:
> https://www.w3.org/2021/01/pressrelease-webrtc-rec.html.en
>
> *Summary*
> WebRTC is a set of JavaScript API used to send and receive audio, video 
> and data between endpoints. Most Video Conferencing services are built on 
> WebRTC.
>
> In order to set up a connection, the SDP protocol is used. The 
> spec-compliant and cross-browser compatible version of SDP is called 
> "Unified Plan". In contrast, "Plan B" is a non-standard version of SDP only 
> available in Chromium-based browsers using a non-standard API.
>
> "Plan B" was deprecated in M93 Canary but due to high usage, a Deprecation 
> Trial was added, allowing registered websites to make use of "Plan B" until 
> Dec 29, 2021 (a couple of days before the M97 Stable release). See previous 
> intent 
> to experiment/deprecate 
> <https://groups.google.com/u/3/a/chromium.org/g/blink-dev/c/35NFPYdumMs/m/1YqxqH0_BAAJ>
>  for 
> more details.
>
> With this request we would like to have an extended Deprecation Trial 
> until May 24, 2022 (M102 Stable Release date).
>
> *Blink component*
> Blink>WebRTC 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EWebRTC=2>
>
> *Search tags*
> WebRTC SDP Plan B Unified Plan 
> <https://www.chromestatus.com/features#tags:WebRTC%20SDP%20Plan%20B%20Unified%20Plan>
>  
>
> *Interoperability and Compatibility*
> Unified Plan is shipped-by-default in all major browsers. Plan B, the 
> feature which we are deprecating, it is the one that has interoperability 
> and compatibility risks. UP and PB clients can talk to each other, but in 
> "complex" setups that requires non-trivial SDP translation.
>
>
> *Goals for experimentation*
> Reduce risk of breakage. Give websites that still depend on Plan B more 
> time to migrate to Unified Plan without delaying the removal for the rest 
> of the web.
>
>
> *Reason this experiment is being extended*
> When the deprecation announcement was made, "Plan B" was used by the 
> majority of WebRTC Video Conferencing use cases. Today, "Plan B" is used by 
> less than 0.7% of WebRTC use cases. The deprecation is having the desired 
> effect.
>
> However, in order to reduce risk while usage was still high, "Plan B" was 
> only throwing an exception in the Canary release channel as of M93. We are 
> now making "Plan B" throw in Stable for M96, but this has also meant that 
> despite our communication efforts and 1 year time frame, there exists 
> services who discovered the deprecation late and need more time.
>
> By having an 

[blink-dev] Request for (Extending) Deprecation Trial: [WebRTC] Deprecate and Remove Plan B

[Henrik Boström]

*Contact emails*
h...@chromium.org, h...@chromium.org, h...@chromium.org

*Specification*
WebRTC is a W3C Recommendation and multiple IETF standards:
https://www.w3.org/2021/01/pressrelease-webrtc-rec.html.en

*Summary*
WebRTC is a set of JavaScript API used to send and receive audio, video and 
data between endpoints. Most Video Conferencing services are built on 
WebRTC.

In order to set up a connection, the SDP protocol is used. The 
spec-compliant and cross-browser compatible version of SDP is called 
"Unified Plan". In contrast, "Plan B" is a non-standard version of SDP only 
available in Chromium-based browsers using a non-standard API.

"Plan B" was deprecated in M93 Canary but due to high usage, a Deprecation 
Trial was added, allowing registered websites to make use of "Plan B" until 
Dec 29, 2021 (a couple of days before the M97 Stable release). See previous 
intent 
to experiment/deprecate 

 for 
more details.

With this request we would like to have an extended Deprecation Trial until 
May 24, 2022 (M102 Stable Release date).

*Blink component*
Blink>WebRTC 


*Search tags*
WebRTC SDP Plan B Unified Plan 


*Interoperability and Compatibility*
Unified Plan is shipped-by-default in all major browsers. Plan B, the 
feature which we are deprecating, it is the one that has interoperability 
and compatibility risks. UP and PB clients can talk to each other, but in 
"complex" setups that requires non-trivial SDP translation.


*Goals for experimentation*
Reduce risk of breakage. Give websites that still depend on Plan B more 
time to migrate to Unified Plan without delaying the removal for the rest 
of the web.


*Reason this experiment is being extended*
When the deprecation announcement was made, "Plan B" was used by the 
majority of WebRTC Video Conferencing use cases. Today, "Plan B" is used by 
less than 0.7% of WebRTC use cases. The deprecation is having the desired 
effect.

However, in order to reduce risk while usage was still high, "Plan B" was 
only throwing an exception in the Canary release channel as of M93. We are 
now making "Plan B" throw in Stable for M96, but this has also meant that 
despite our communication efforts and 1 year time frame, there exists 
services who discovered the deprecation late and need more time.

By having an extended Deprecation Trial until May 24, 2022, we are 
providing services that started migration late with enough time to migrate 
to Unified Plan safely.

*Link to entry on the Chrome Platform Status*
https://www.chromestatus.com/feature/5823036655665152

*Link to previous Intent to Experiment:*
https://groups.google.com/u/3/a/chromium.org/g/blink-dev/c/35NFPYdumMs/m/1YqxqH0_BAAJ

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9e63fc40-d23a-494b-bf1a-a9693b24c893n%40chromium.org.

[blink-dev] Re: Intent to Deprecate: WebRTC's Plan B SDP semantics

[Henrik Boström]

An update from the Chrome side is that the Deprecation Trial is ramping up 
in M96: https://groups.google.com/u/1/g/discuss-webrtc/c/zRIgxG18D80.

On Monday, January 18, 2021 at 3:42:37 PM UTC+1 Henrik Boström wrote:

> Hi Michael, I believe our PM has reached out to you and other companies 
> today via email, let's follow up there about issues impacting migration.
>
> On Friday, January 15, 2021 at 5:03:00 PM UTC+1 michael@logmein.com 
> wrote:
>
>> From the LogMeIn/GoToMeeting perspective: We're one of the remaining Plan 
>> B users. Primary driver really being reliability. We've tried to switch to 
>> Unified Plan a number of times in the past and have always experienced 
>> issues that stopped the migration efforts (most of these issues were 
>> already in tickets, we did file a few others.) I'm willing to give this 
>> another try.
>>
>> With regards to this proposal: I'm in favour of deprecation and 
>> establishing a reverse origin trial. We'll likely take part in the reverse 
>> origin trial. I'd like to ask, however, that if the third party vendors do 
>> see problems and file tickets with respect to the Unified Plan transition - 
>>  that these tickets are prioritised or extend the duration of the reverse 
>> origin trial until said vendors have fixed their side of things or Google 
>> has fixed the problems in libwebrtc/Chrome.
>>
>> I'll schedule the respective work to pursue the migration to Unified Plan.
>>
>> -- Michael
>> Sr. Manager, RTC Platform Engineering
>> Henrik Boström schrieb am Dienstag, 22. Dezember 2020 um 14:03:21 UTC+1:
>>
>>> Primary eng (and PM) emails
>>>
>>> hb...@chromium.org, h...@chromium.org
>>>
>>> Summary
>>>
>>> WebRTC is a platform for web conferencing and data transmission. The 
>>> platform contains the JavaScript APIs that major websites use to implement 
>>> their web conferencing products, including Zoom, Google Meet, Facebook 
>>> Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.
>>> In order for two WebRTC endpoints to set up a call they need to exchange 
>>> a text-based description of what is to be sent and received (how many video 
>>> feeds, which codecs are supported or preferred, etc). The protocol is 
>>> called SDP (Session Description Protocol) and it is used by any WebRTC 
>>> application that wishes to connect anywhere.
>>>
>>> The spec settled on a dialect of SDP called Unified Plan, which is 
>>> currently the one and only version of SDP that browsers like Firefox and 
>>> Safari implement.
>>>
>>> In Chromium-based browsers (like Chrome and now more recently Edge), 
>>> Unified Plan has been the default SDP dialect for almost two years. 
>>> However, unlike Firefox and Safari, Chrome allows applications to opt-in to 
>>> a legacy SDP dialect called Plan B, which works slightly different than the 
>>> web standard.
>>>
>>> The way to achieve Plan B is to construct the RTCPeerConnection with the 
>>> non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to 
>>> deprecate this attribute, and as a result, make it impossible to have 
>>> modern browsers speak the Plan B dialect of SDP.
>>>
>>> Motivation
>>>
>>> Explain why this feature should be deprecated (and eventually removed).
>>> Unified Plan and Plan B are incompatible in "complex" conferencing 
>>> setups. Complex means if there are multiple m= sections of the same media 
>>> kind (audio/video). To simplify what this means, this roughly translates to 
>>> 1:1 calling working between Plan B and Unified Plan clients (in most 
>>> cases), but group calling breaking due to incompatibilities. Furthermore, 
>>> some APIs that have been implemented in the last two years are only 
>>> available when Unified Plan is used.
>>>
>>> We want to deprecate Plan B in favor of a spec-compliant and 
>>> cross-browser compatible SDP format. We want to increase interoperability 
>>> and compatibility long-term by deprecating a feature that is heavily used 
>>> at present time, but if it was to be deleted today that would cause 
>>> compatibility issues with apps not prepared for Unified Plan. Plan B and 
>>> Unified Plan clients may talk, but SDP format has to be translated between 
>>> them in application-specific ways. Some apps may simply not support 
>>> spec-compliant endpoints.
>>>
>>> There is a risk if people develop and test on Chromium-based b