15:00:34 <RRSAgent> RRSAgent has joined #webrtc
15:00:38 <RRSAgent> logging to https://www.w3.org/2025/03/25-webrtc-irc
15:00:38 <Zakim> Zakim has joined #webrtc
15:00:38 <dom> RRSAgent, make log public
15:00:39 <dom> Meeting: WebRTC March 2025 meeting
15:00:39 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/March_25_2025
15:00:39 <dom> Slideset: https://docs.google.com/presentation/d/1XOyWSPufsvDpK18GXZvq_j1rF3gs34QvPlOWWyB0CjU/
15:00:39 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:01:28 <dom> Present+ Harald, Jan-Ivar, Youenn, Dom, Sameer, Henrik, SunShin
15:02:46 <dom> Present+ Guido
15:03:51 <dom> Recording is starting
15:05:07 <dom> Scribe: Dom
15:05:10 <dom> Present+ Carine
15:05:51 <dom> Topic: -> https://github.com/w3c/webrtc-stats/pull/792 Stats for L4S
15:05:51 <dom> [slide 10]
15:07:42 <dom> [slide 11]
15:09:18 <dom> [slide 12]
15:09:46 <dom> [slide 13]
15:11:47 <dom> [slide 14]
15:13:09 <dom> Youenn: what's the expected usage after the experimentation phase?
15:13:34 <dom> Harald: FaceTime published appealing results of difference in delays with and without L4S
15:13:57 <dom> ... the goal is to reduce delays in regular videoconferencing
15:14:17 <dom> Youenn: that's the goal for L4S in general, but what about stats specifically?
15:15:10 <dom> Harald: detect what happens; the explainer in the PR has more details (e.g. associating delays in networks with and without L4S support)
15:16:05 <dom> Jan-Ivar: the proposal would affect both local and remote stats - is that intended?
15:16:49 <dom> Harald: yes - on the remote side, they're set based on RTCP feedback message, on the local side based on what is sent
15:18:13 <dom> Henrik: re getStats() - we want to measure what happens in the wild even beyond an experimental phase
15:19:19 <dom> SinShun: really excited to see L4S support, we're supportive of the proposal and would be happy to be part of that experimentation
15:20:02 <dom> ... will that be made available without flags?
15:20:20 <dom> HTA: once there has been enough experimentation with a flag, I suspect we will go with an origin trial
15:21:48 <dom> Dom: can you confirm apps wouldn't be expected to change their behavior based on these stats, it's only for measurement?
15:21:51 <dom> Harald: correct
15:22:14 <dom> Resolved: Merge pull request
15:22:26 <dom> Topic: -> Codec Dictionary Match / getStats
15:22:26 <dom> Subtopic: -> https://github.com/w3c/webrtc-pc/issues/3037 Codec dictionary match, ignoring levels, and AV1
15:22:26 <dom> [slide 16]
15:25:07 <dom> [slide 17]
15:26:50 <dom> Jan-Ivar: the codec dictionary match algorithm affects the API ability to discern several codecs as separate (conversely, that we can't tell them apart otherwise) - is that correct?
15:28:24 <dom> Henrik: this affects setCodecPreferences(), but not alter the information used in setParameters(); AV1 currently throws in setParameters, which doesn't match our expectation
15:28:27 <dom> [slide 18]
15:29:13 <dom> RRSAgent, draft minutes
15:29:14 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/25-webrtc-minutes.html dom
15:29:55 <dom> Present+ JasperHugo, PatrickRockhill
15:30:03 <dom> Henrik: we'll leave the bikeshedding to the editors
15:30:12 <dom> [slide 19]
15:30:29 <dom> Present+ ShridharMajali
15:30:43 <dom> Present+ FrederikSolenberg
15:31:49 <dom> [slide 20]
15:34:06 <dom> [slide 21]
15:35:02 <dom> Jan-Ivar: how early would this be? when going back to stable?
15:35:17 <dom> Henrik: I think so - would want to check what's currently implemented
15:35:25 <vr000m> vr000m has joined #webrtc
15:35:27 <dom> ... it would have to either stable or hasLocalOffer
15:35:35 <dom> ... the sender should be configured and ready to go
15:36:06 <dom> Jan-Ivar: sounds good; would this be for all stats? how would the stats be impacted - zero?
15:36:19 <dom> henrik: depends on which stats (counter at zero, others would be undefined)
15:36:25 <dom> s/counter/counters/
15:37:11 <dom> Jan-Ivar: this wouldn't touch inbound RTP, right - it would still be recommended to wait for unmuted?
15:37:22 <dom> henrik: right
15:38:05 <dom> RESOLVED: move forward with "early" proposal as described
15:38:25 <dom> Jan-Ivar: this wouldn't affect remoteoutboundrtp?
15:38:38 <dom> Henrik: right, that one requires to have received an rtcp report
15:38:47 <dom> [slide 22]
15:41:43 <dom> Henrik: this isn't necessarily when doing SDP munging - RID is optional in the addTransceiver method
15:41:53 <dom> Jan-Ivar: but that's something the developer has control over
15:43:13 <dom> Henrik: it can help in transitioning from SSRC munging
15:43:43 <dom> Jan-Ivar: isn't that instead discouraging transition?
15:43:54 <dom> ... not sure I'm opposed, but would like to understand the use case better
15:45:09 <dom> Henrik: e.g. webrtc-internals shows stats outside of app logic in a random order for lack of available information at the stats level
15:45:31 <dom> Harald: RIDs are not sortable either - you can't tell which one are 1st/2nd/...
15:45:44 <dom> Henrik: correct, that's app specific
15:45:53 <dom> Jan-Ivar: that's exposed in getParameters
15:47:30 <dom> Jan-Ivar: can we continue the discussion on github? e.g. would prefer encodingIndex rather than simulcastIndex
15:47:46 <dom> RESOLVED: consensus to move forward pending further discussion with Jan-Ivar on use case
15:47:58 <dom> Topic: -> https://github.com/w3c/mediacapture-screen-share/issues/316 Screen capture pixel ratio
15:47:58 <dom> -> https://github.com/w3c/mediacapture-screen-share/pull/315 Add physical and logical resolution.
15:47:58 <dom> [slide 25]
15:48:13 <dom> i|[slide 22]|Subtopic: -> https://github.com/w3c/webrtc-stats/issues/801 RTCOutboundRtpStreamStats.simulcastIndex
15:48:43 <dom> Present+ TimPanton
15:49:13 <dom> Present+ Palak
15:49:40 <dom> [slide 26]
15:50:01 <dom> [slide 27]
15:50:38 <dom> [slide 28]
15:50:59 <dom> [slide 29]
15:51:22 <dom> [slide 30]
15:52:12 <dom> [slide 31]
15:52:37 <dom> [slide 32]
15:54:04 <dom> Jan-Ivar: +1; if it is a constraint, it will have to be added to settings, capabilities, and add fitness distance calculation
15:54:40 <dom> Youenn: SGTM for window capture; not sure  if taking page zoom into account for tab capture is always a good idea
15:55:24 <dom> ... this may need more experimentation; maybe start with a MAY for integrating page zoom in the calculation
15:56:01 <dom> Guido: devicePixelRatio takes pageZoom into account, although it's not mandatory
15:56:16 <dom> ... we could keep it optional there as well; or expose the two
15:56:38 <dom> Youenn: maybe we should piggyback on the definition of devicePixelRatio
15:56:47 <dom> ... in any case, it feels worth experimenting
15:57:06 <dom> Jan-Ivar: given the problem we're trying to solve, it feels a bit odd to take into account pageZoom indeed
15:57:59 <dom> Palak: we want to align with what is being shared by the user
15:58:17 <dom> Jan-Ivar: I'm not sure we want to trigger a configurationchange event upon a zoom change
15:58:35 <dom> Youenn: maybe that points towards a separate property for pageZoom in general
15:58:41 <dom> Palak: that sounds reasonable
15:59:06 <dom> Youenn: would still want to understand the use case for pageZoom, but we can progress with pixelRatio
15:59:24 <dom> RESOLVED: rough consensus on OS-based pixelRatio, more discussion needed on pageZoom
15:59:38 <dom> Topic: WPT Interop
15:59:38 <dom> [slide 35]
16:00:53 <dom> Present+ Varun
16:01:05 <dom> [slide 36]
16:01:39 <dom> [slide 37]
16:03:05 <dom> [slide 38]
16:04:58 <dom> Youenn: is there interest/energy to have the WG involved on this?
16:05:34 <dom> Jan-Ivar: supportive of this
16:06:00 <dom> ... we can help with testing infrastructure; how would you see the WG involved e.g. in picking topics?
16:08:41 <dom> Dom: support adding this to the WG agenda (at the right point in time); maybe re-use TimP's outreach to WebRTC users
16:09:14 <dom> Harald: one issue with Interop last year was that interoperability was blocked by getting consensus on specs (more than by implementations or tests)
16:09:47 <dom> Henrik: we had a hackathon some years ago; maybe this could be something we do at our next F2F, focusing on fixing WPT tests
16:10:10 <dom> Youenn: we could look at this at next TPAC
16:10:37 <dom> Harald: IETF hackathons have been most successful when there is agreement on focusing on a particular feature to prove that it works
16:10:56 <dom> ... different groups can work on different things
16:11:13 <dom> ... an interesting idea to discuss
16:11:28 <dom> Youenn: e.g. triaging the 600 failing tests would be useful
16:12:05 <dom> Jan-Ivar: the WG could be helpful in making progress on subset of specs that have consensus to help with partial progress
16:12:44 <dom> Youenn: e.g. private enumerateDevices: we have a spec, but widely different behaviors; it was good that this generated new attention to that divergence
16:13:28 <dom> ... I'll get in touch with Tim to see if he can with a community survey, maybe with a focus in the failing tests
16:13:48 <dom> Topic: -> https://github.com/w3c/mediacapture-main/issues/910 GC of capture tracks
16:13:48 <dom> [slide 41]
16:14:50 <dom> [slide 42]
16:16:38 <dom> [slide 43]
16:18:25 <dom> Jan-Ivar: I believe all implementations already garbage-collect after 10s (?) if there is no strong JS ref
16:18:50 <dom> Youenn: the proposal is to make the conditions for GC explicit in the spec (as is done in WebRTC or in WebSockets)
16:19:24 <dom> ... I don't know what rules implementations currently follow, but hopefully we can converage while leaving enough leeway
16:19:46 <dom> Jan-Ivar: that sounds good
16:20:12 <dom> Youenn: e.g. Safari only GC'd ended tracks; I have added detection of event listeners recently
16:20:27 <dom> Harald: how do you write WPT for GC since it's not observable?
16:20:54 <dom> Dom: it's observable in WPT via a Web Driver API
16:22:34 <dom> -> https://github.com/web-platform-tests/wpt/blob/master/common/gc.js WPT Garbage Collector Helper
16:23:56 <dom> Youenn: we could consider a timer approach
16:24:21 <dom> Jan-Ivar: GC is treated mostly as an optimization, so doesn't need to be spec'd in general
16:24:43 <dom> ... although it's nice if specs can give guidance based on subject-matter expertise
16:24:50 <dom> ... as long as GC remain non-observable
16:25:20 <dom> Youenn: have implementors seen cases where tracks are kept alive after the page lost interest? do you think a console warning would help?
16:25:47 <dom> Henrik: we've seen issues with track not stopped leaving the camera light on (which is observable by the user)
16:26:09 <dom> ... having that behavior common across implementations might be good
16:26:50 <dom> Jan-Ivar: usually, GC bugs appear the other way; we have a bug with datachannels being GC'd too agressively
16:27:05 <dom> RESOLVED: move forward with a proposal along those lines
16:27:20 <dom> Topic: -> https://github.com/w3c/mediacapture-record/issues/202 MediaRecorder isTypeSupported deprecation
16:27:20 <dom> [slide 45]
16:27:53 <dom> Topic: -> https://github.com/w3c/mediacapture-record/issues/202 MediaRecorder isTypeSupported deprecation
16:27:53 <dom> [slide 46]
16:28:35 <dom> s/45/44
16:28:38 <dom> s/46/45
16:30:08 <dom> s|Topic: -> https://github.com/w3c/mediacapture-record/issues/202 MediaRecorder isTypeSupported||
16:32:12 <dom> [slide 46]
16:33:25 <dom> Jan-Ivar: this describes what I think my PR is doing
16:34:40 <dom> Youenn: imagine we have AV2 in the future; my understanding is that the PR identifies a list of legacy codecs, and for codecs not in that list, it would always return true (rather than false as I suggest in my slide)
16:35:02 <dom> ... returning true may be more Web compatible, by pushing the error to constructing time
16:35:17 <dom> Jan-Ivar: if that's the only difference, I'm amenable to changing to returning false
16:35:22 <dom> [slide 47]
16:38:21 <dom> Henrik: in WebRTC, when we query media capabilities, we get all the information including the profiles; I would find it surprising if we didn't fetch the profile - but for clarity, I'm not sure what our mediarecorder implementation does
16:39:07 <dom> Jan-Ivar: (for clarification, my PR does return false for isTypeSupported re earlier discussion)
16:39:23 <dom> Youenn: that means we need precise agreement on the list of legacy codecs
16:40:35 <dom> Jan-Ivar: my PR intentionally didn't include profile and levels; Firefox doesn't check profiles
16:40:42 <dom> ... (but we only support VP8 and Opus)
16:40:52 <dom> Youenn: I'll file a different issue for this
16:41:07 <dom> ... re the PR, I think we should have PCM and HEVC (since we've shipped it)
16:41:31 <dom> Henrik: we should align
16:42:10 <dom> Jan-Ivar: I'm OK with PCM, HEVC is a codec for which obtaining sync info about hardware availability
16:42:25 <dom> Youenn: we've shipped this, so this would be a web compat issue
16:43:08 <dom> Jan-Ivar: but given that this codec is not interoperable anyway, developers already have to deal with cross browsers
16:43:28 <dom> ... changing this wouldn't break a web site, it would reduce what gets surfaced as a user choice
16:43:45 <dom> Youenn: I'll check internally, but I'm not sure we can change this
16:44:01 <dom> ... PCM is definitely a compat issue; I'll double check for HEVC
16:44:20 <dom> [slide 48]
16:45:41 <dom> Harald: re WPT, to fully test this API, we need to have an implemented codec not in the codec list - is there such a thing?
16:45:48 <dom> ... maybe VP9?
16:46:01 <dom> Youenn: FLAC may be a candidate
16:46:48 <dom> Harald: +1 to update docs; update WPTs to match
16:47:44 <dom> Dom: happy to help wrt MDN re deprecation
16:48:01 <dom> ... more generally, there was a breakout last year on how to manage deprecation, probably worth checking it out
16:48:15 <dom> Youenn: let's file an issue to keep track of that deprecation plan
16:48:50 <dom> -> https://www.w3.org/2024/09/breakouts/minutes-20.html Deprecation is hard to do and we can do it better! (TPAC 2024 breakout)
16:49:02 <dom> Topic: -> https://github.com/w3c/mediacapture-main/issues/1029 Should applyConstraints reject when track is muted?
16:49:02 <dom> [slide 50]
16:51:41 <dom> Henrik: what happens if you open the camera in VGA, mute, applyConstraints in HD?
16:52:23 <dom> ... unless there are other sources, this would reconfigure the camera; how would you know if the HD would work?
16:52:40 <dom> Jan-Ivar: you would already know if it's a valid setting (per getCapabilities)
16:54:32 <dom> Youenn: is FF delaying applying the constraints until the device is restarting?
16:54:52 <dom> Jan-Ivar: no, constraints are applied to tracks, not devices
16:55:33 <dom> Youenn: fine with the proposal, but will need to change Safari's behavior - I don't want a muted tab to change the hardware camera settings of an unmuted tab
16:56:06 <dom> ... this proposal seems like a better approach for developers
16:57:00 <dom> Guido: this makes sense for settings for camera tracks
16:57:39 <dom> Youenn: in some cases, it might be hard to implement the behavior; my approach may to be applySettings, and if it couldn't be applied, trigger a later configurationchange event
16:57:56 <dom> Jan-Ivar: that makes sense
16:58:51 <dom> Youenn: not delaying should be made clear in the PR
16:58:56 <dom> RESOLVED: proceed with the proposal
16:59:01 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/2967 Implementations only update getParameters().codecs when negotiation has finished
16:59:01 <dom> [slide 51]
16:59:43 <dom> RESOLVED: align spec with implementations
16:59:58 <dom> RRSAgent, draft minutes
17:00:00 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/25-webrtc-minutes.html dom
18:25:36 <Zakim> Zakim has left #webrtc