Meeting minutes
Recording: https://
Slideset: https://
Stats for L4S 🎞︎
Youenn: what's the expected usage after the experimentation phase?
Harald: FaceTime published appealing results of difference in delays with and without L4S
… the goal is to reduce delays in regular videoconferencing
Youenn: that's the goal for L4S in general, but what about stats specifically?
Harald: detect what happens; the explainer in the PR has more details (e.g. associating delays in networks with and without L4S support)
Jan-Ivar: the proposal would affect both local and remote stats - is that intended?
Harald: yes - on the remote side, they're set based on RTCP feedback message, on the local side based on what is sent
Henrik: re getStats() - we want to measure what happens in the wild even beyond an experimental phase
SinShun: really excited to see L4S support, we're supportive of the proposal and would be happy to be part of that experimentation
… will that be made available without flags?
HTA: once there has been enough experimentation with a flag, I suspect we will go with an origin trial
Dom: can you confirm apps wouldn't be expected to change their behavior based on these stats, it's only for measurement?
Harald: correct
RESOLUTION: Merge pull request
-> Codec Dictionary Match / getStats 🎞︎
Codec dictionary match, ignoring levels, and AV1 🎞︎
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?
Henrik: this affects setCodecPreferences(), but not alter the information used in setParameters(); AV1 currently throws in setParameters, which doesn't match our expectation
Henrik: we'll leave the bikeshedding to the editors
RTCOutboundRtpStreamStats should be created "early" 🎞︎
Jan-Ivar: how early would this be? when going back to stable?
Henrik: I think so - would want to check what's currently implemented
… it would have to either stable or hasLocalOffer
… the sender should be configured and ready to go
Jan-Ivar: sounds good; would this be for all stats? how would the stats be impacted - zero?
henrik: depends on which stats (counters at zero, others would be undefined)
Jan-Ivar: this wouldn't touch inbound RTP, right - it would still be recommended to wait for unmuted?
henrik: right
RESOLUTION: move forward with "early" proposal as described
Jan-Ivar: this wouldn't affect remoteoutboundrtp?
Henrik: right, that one requires to have received an rtcp report
RTCOutboundRtpStreamStats.simulcastIndex
Henrik: this isn't necessarily when doing SDP munging - RID is optional in the addTransceiver method
Jan-Ivar: but that's something the developer has control over
Henrik: it can help in transitioning from SSRC munging
Jan-Ivar: isn't that instead discouraging transition?
… not sure I'm opposed, but would like to understand the use case better
Henrik: e.g. webrtc-internals shows stats outside of app logic in a random order for lack of available information at the stats level
Harald: RIDs are not sortable either - you can't tell which one are 1st/2nd/...
Henrik: correct, that's app specific
Jan-Ivar: that's exposed in getParameters
Jan-Ivar: can we continue the discussion on github? e.g. would prefer encodingIndex rather than simulcastIndex
RESOLUTION: consensus to move forward pending further discussion with Jan-Ivar on use case
Screen capture pixel ratio 🎞︎
Add physical and logical resolution.
Jan-Ivar: +1; if it is a constraint, it will have to be added to settings, capabilities, and add fitness distance calculation
Youenn: SGTM for window capture; not sure if taking page zoom into account for tab capture is always a good idea
… this may need more experimentation; maybe start with a MAY for integrating page zoom in the calculation
Guido: devicePixelRatio takes pageZoom into account, although it's not mandatory
… we could keep it optional there as well; or expose the two
Youenn: maybe we should piggyback on the definition of devicePixelRatio
… in any case, it feels worth experimenting
Jan-Ivar: given the problem we're trying to solve, it feels a bit odd to take into account pageZoom indeed
Palak: we want to align with what is being shared by the user
Jan-Ivar: I'm not sure we want to trigger a configurationchange event upon a zoom change
Youenn: maybe that points towards a separate property for pageZoom in general
Palak: that sounds reasonable
Youenn: would still want to understand the use case for pageZoom, but we can progress with pixelRatio
RESOLUTION: rough consensus on OS-based pixelRatio, more discussion needed on pageZoom
WPT Interop 🎞︎
Youenn: is there interest/energy to have the WG involved on this?
Jan-Ivar: supportive of this
… we can help with testing infrastructure; how would you see the WG involved e.g. in picking topics?
Dom: support adding this to the WG agenda (at the right point in time); maybe re-use TimP's outreach to WebRTC users
Harald: one issue with Interop last year was that interoperability was blocked by getting consensus on specs (more than by implementations or tests)
Henrik: we had a hackathon some years ago; maybe this could be something we do at our next F2F, focusing on fixing WPT tests
Youenn: we could look at this at next TPAC
Harald: IETF hackathons have been most successful when there is agreement on focusing on a particular feature to prove that it works
… different groups can work on different things
… an interesting idea to discuss
Youenn: e.g. triaging the 600 failing tests would be useful
Jan-Ivar: the WG could be helpful in making progress on subset of specs that have consensus to help with partial progress
Youenn: e.g. private enumerateDevices: we have a spec, but widely different behaviors; it was good that this generated new attention to that divergence
… I'll get in touch with Tim to see if he can with a community survey, maybe with a focus in the failing tests
GC of capture tracks 🎞︎
Jan-Ivar: I believe all implementations already garbage-collect after 10s (?) if there is no strong JS ref
Youenn: the proposal is to make the conditions for GC explicit in the spec (as is done in WebRTC or in WebSockets)
… I don't know what rules implementations currently follow, but hopefully we can converage while leaving enough leeway
Jan-Ivar: that sounds good
Youenn: e.g. Safari only GC'd ended tracks; I have added detection of event listeners recently
Harald: how do you write WPT for GC since it's not observable?
Dom: it's observable in WPT via a Web Driver API
Youenn: we could consider a timer approach
Jan-Ivar: GC is treated mostly as an optimization, so doesn't need to be spec'd in general
… although it's nice if specs can give guidance based on subject-matter expertise
… as long as GC remain non-observable
Youenn: have implementors seen cases where tracks are kept alive after the page lost interest? do you think a console warning would help?
Henrik: we've seen issues with track not stopped leaving the camera light on (which is observable by the user)
… having that behavior common across implementations might be good
Jan-Ivar: usually, GC bugs appear the other way; we have a bug with datachannels being GC'd too agressively
RESOLUTION: move forward with a proposal along those lines
MediaRecorder isTypeSupported deprecation 🎞︎
deprecation
Jan-Ivar: this describes what I think my PR is doing
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)
… returning true may be more Web compatible, by pushing the error to constructing time
Jan-Ivar: if that's the only difference, I'm amenable to changing to returning false
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
Jan-Ivar: (for clarification, my PR does return false for isTypeSupported re earlier discussion)
Youenn: that means we need precise agreement on the list of legacy codecs
Jan-Ivar: my PR intentionally didn't include profile and levels; Firefox doesn't check profiles
… (but we only support VP8 and Opus)
Youenn: I'll file a different issue for this
… re the PR, I think we should have PCM and HEVC (since we've shipped it)
Henrik: we should align
Jan-Ivar: I'm OK with PCM, HEVC is a codec for which obtaining sync info about hardware availability
Youenn: we've shipped this, so this would be a web compat issue
Jan-Ivar: but given that this codec is not interoperable anyway, developers already have to deal with cross browsers
… changing this wouldn't break a web site, it would reduce what gets surfaced as a user choice
Youenn: I'll check internally, but I'm not sure we can change this
… PCM is definitely a compat issue; I'll double check for HEVC
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?
… maybe VP9?
Youenn: FLAC may be a candidate
Harald: +1 to update docs; update WPTs to match
Dom: happy to help wrt MDN re deprecation
… more generally, there was a breakout last year on how to manage deprecation, probably worth checking it out
Youenn: let's file an issue to keep track of that deprecation plan
Deprecation is hard to do and we can do it better! (TPAC 2024 breakout)
Should applyConstraints reject when track is muted? 🎞︎
Henrik: what happens if you open the camera in VGA, mute, applyConstraints in HD?
… unless there are other sources, this would reconfigure the camera; how would you know if the HD would work?
Jan-Ivar: you would already know if it's a valid setting (per getCapabilities)
Youenn: is FF delaying applying the constraints until the device is restarting?
Jan-Ivar: no, constraints are applied to tracks, not devices
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
… this proposal seems like a better approach for developers
Guido: this makes sense for settings for camera tracks
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
Jan-Ivar: that makes sense
Youenn: not delaying should be made clear in the PR
RESOLUTION: proceed with the proposal
Implementations only update getParameters().codecs when negotiation has finished 🎞︎
RESOLUTION: align spec with implementations