Re: [blink-dev] Intent to Ship: [WebRTC getStats] Align implementations on when RTP stats should be created

th inbound missing until packet reception due to Firefox shipping this years ago. On Monday, March 31, 2025 at 10:12:25 PM UTC+2 philipp...@googlemail.com wrote: > Am Mo., 31. März 2025 um 01:05 Uhr schrieb Henrik Boström < > h...@chromium.org>: > >> That's correct, but getS

Re: [blink-dev] Intent to Ship: [WebRTC getStats] Align implementations on when RTP stats should be created

>> https://wpt.fyi/results/webrtc/simplecall-no-ssrcs.https.html?label=experimental&label=master&aligned >> >> which is all green. >> >> >>> The various WGs have discussed SSRC signaling many times, and always >>> came down on rejecting it. I ev

Re: [blink-dev] Intent to Ship: [WebRTC getStats] Align implementations on when RTP stats should be created

y, March 28, 2025 at 4:03:11 PM UTC+1 philipp...@googlemail.com wrote: > > 4 > Am Fr., 28. März 2025 um 05:47 Uhr schrieb Henrik Boström < > h...@chromium.org>: > >> Contact emails >> h...@chromium.org, h...@chromium.org >> >> ExplainerNone >>

[blink-dev] Intent to Ship: [WebRTC getStats] Align implementations on when RTP stats should be created

Contact emails h...@chromium.org, h...@chromium.org ExplainerNone Specification https://w3c.github.io/webrtc-stats/#the-rtp-statistics-hierarchy Summary RTP stats objects, of type "outbound-rtp" or "inbound-rtp" in this case, represents a WebRTC stream. The identifier of this stream is the SSR

Re: [blink-dev] Re: Intent to Ship: H265 (HEVC) codec support in WebRTC

the Chromium > position a bit more than the very brief statement cited in > > https://groups.google.com/a/chromium.org/g/blink-dev/c/YJ1QijNiHeM/m/3EhMjMVwAgAJ > > Am Di., 4. März 2025 um 02:34 Uhr schrieb Henrik Boström < > h...@chromium.org>: > >> AV1 is gre

Re: [External] Re: [blink-dev] Re: Intent to Ship: H26x Codec support updates for MediaRecorder

For reference, I had some hardware availability numbers over in the I2S thread for H265 in WebRTC . On Tuesday, March 4, 2025 at 3:12:33 PM UTC+1 朱思达 wrote: > Given your example, it

[blink-dev] Re: Intent to Ship: H265 (HEVC) codec support in WebRTC

>> for patent encumbered codecs when we have AV1. Apple continues to use its >> hardware to push closed solutions in this space, and I understand the >> instinct, but I'd like to see quantified benefits. >> >> Best, >> >> Alex >> >>

[blink-dev] Intent to Ship: H265 (HEVC) codec support in WebRTC

Contact emails h...@chromium.org, jianlin@intel.com, e...@chromium.org Specification WebRTC: https://w3c.github.io/webrtc-pc But there are no new API surfaces, just a new mime type addition exposed in existing APIs - the new mime type ("video/H265") is queryable via MediaCapabilities API: h

[blink-dev] Re: Intent to Ship: [WebRTC] RTCRtpEncodingParameters.scaleResolutionDownTo

Forgot to link but here are the notes + recordings from the virtual interim: https://www.w3.org/2024/08/27-webrtc-minutes.html#t06 On Monday, September 16, 2024 at 2:21:43 PM UTC+2 Henrik Boström wrote: > Contact emails > h...@chromium.org > > Specification > > https://w3

[blink-dev] Intent to Ship: [WebRTC] RTCRtpEncodingParameters.scaleResolutionDownTo

Contact emails h...@chromium.org Specification https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto Summary An API that configures WebRTC encoders to scale input frames if they are greater than the specified maxWidth and maxHeight. This API is similar to

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

>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.)

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

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

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

[*] 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 tha

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

re <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, D

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

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

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

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 al

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

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

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

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 (get

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

n 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:*

[blink-dev] Intent to Ship: MediaStreamTrack Stats

*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,

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

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.

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

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 imp

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

; 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 th

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

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 deprec

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

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

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

rk 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 onl

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

*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.* *

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

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

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

uld 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

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

he 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 Bos

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

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

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

n, 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 p

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

n 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&#

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

f 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

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

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 ta

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

; > 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. > > O

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

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 schrie

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

*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 <

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

reathe. 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 feed

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

ic 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 th

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

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

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

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 stil

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

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 alternativ

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

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 no

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

e 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 gi

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

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. >

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

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 developmen

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

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...

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

*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 da

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

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 compan