15:03:01 <RRSAgent> RRSAgent has joined #webrtc
15:03:05 <RRSAgent> logging to https://www.w3.org/2025/05/20-webrtc-irc
15:03:05 <Zakim> Zakim has joined #webrtc
15:03:05 <dom> RRSAgent, make log public
15:03:06 <dom> Meeting: WebRTC May 2025 meeting
15:03:06 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/May_20_2025
15:03:06 <dom> Slideset: https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit
15:03:06 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:03:52 <dom> Present+ Dom, Carine, FrederickSolenberg, Guido, Jan-Ivar, JohannesKron, OlgaSharonova, PatrickRockhill, Elad, SameerVijaykar, Youenn
15:05:03 <dom> Recording is starting
15:05:09 <dom> Present+ SunShin
15:07:35 <dom> Topic: Transient activation after getDisplayMedia
15:07:35 <dom> [slide 10]
15:08:49 <dom> [slide 11]
15:09:13 <dom> [slide 12]
15:10:11 <dom> [slide 13]
15:11:09 <dom> [slide 14]
15:12:49 <dom> Jan-Ivar: I like the proposal, it sounds like a good idea; it's important that gDM requires transient activation in the first place to avoid annoying the user and get transient activation as an exploit
15:13:15 <dom> Elad: Chrome is working on aligning its transient activation policy with the spec
15:14:33 <dom> Youenn: the proposal makes sense; the only issue is if the page is in background - not having focus while having transient activation feels weird - this may be worth filing an issue in the HTML spec to ensure we're not missing something with that approach
15:15:15 <dom> ... I think we can proceed with a PR while we check in parallel with the HTML spec authors that this isn't creating problems
15:16:13 <dom> ... transient activation remains ill-defined with lots of interop gaps
15:16:24 <dom> Elad: this could be a MAY or a SHOULD if that helps
15:16:33 <dom> Youenn: let's maybe adjust based on feedback from the HTML editors
15:18:04 <dom> Jan-Ivar: I don't think we need MAY given how flexible transient activation is
15:18:35 <dom> ... Should we add consumption of the activation to the spec?
15:18:55 <dom> Elad: I think this was spec'd before that notion of consumption was defined; we could do that as a follow up
15:18:58 <dom> Jan-Ivar: +1
15:19:46 <dom> RESOLVED: Proceed with a PR matching the proposal and file an issue on transient activation & focus in HTML repo
15:20:14 <dom> Topic: -> https://github.com/w3c/mediacapture-screen-share-extensions/issues/7 getDisplayMedia(): Window audio hint
15:20:14 <dom> [slide 17]
15:21:38 <dom> [slide 18]
15:22:31 <dom> [slide 19]
15:23:38 <dom> [slide 20]
15:25:02 <dom> Jan-Ivar: we already include/exclude options - could this be dealt as a user choice? can you say a bit more about why the web app would know better what the right default is? having the Web app influence the UI defaults may create user surprises
15:25:13 <dom> ... are there use cases the app would know better?
15:26:08 <dom> Johannes: this would be a line with how app can give a hint of what type of content they expect the user to share
15:26:35 <dom> ... creating situations where the app is getting the wrong kind of audio isn't helpful
15:27:34 <dom> Elad: today, the browser only suggests sharing audio if the app requests it
15:28:04 <dom> ... in most cases, capturing the audio associated with the app owning the window is a reasonable default
15:28:28 <dom> ... but when they want something different, they already have another path by requesting getDisplayMedia a second time to get system audio
15:28:44 <dom> ... this new approach would be more efficient and privacy-preserving
15:29:19 <dom> [clarification that "application" refers to Web app, and "audio application" refers to the captured application audio]
15:29:36 <dom> Jan-Ivar: may be use "window" vs "application"
15:29:43 <dom> ... This would be a hint right?
15:29:47 <dom> Johannes: right
15:30:24 <dom> Jan-Ivar: sympathetic to the use case, not sure we would implement, no strong opinion
15:31:01 <dom> Youenn: will there be a mechanism for the web app to determine whether they're getting what they expect?
15:31:23 <dom> ... also, beyond "window", should there be something about capturing tab audio (which is under UA control)?
15:31:33 <dom> Johannes: this wouldn't change how tab audio is captured
15:32:04 <dom> ... in general, tab audio is less problematic - e.g. system audio can generate echo
15:32:22 <dom> Elad: this doesn't touch tab audio, nor preclude us to change tab audio later
15:34:52 <dom> Youenn: so if the user is selecting the window, by default the expectation is that it would come with window audio; there is no API to verify that's the case
15:35:21 <dom> ... if the user selects a tab, what does "application" do?
15:35:31 <dom> Elad: if the user selects a tab, this hint doesn't apply
15:36:51 <dom> Jan-Ivar: what happens if I call gDM with `{video: true, windowAudio: application}`?
15:36:53 <dom> [missed]
15:38:09 <dom> Dom: will this replace https://github.com/w3c/mediacapture-screen-share/pull/283/files ?
15:38:12 <dom> Johannes: yes
15:38:48 <dom> Jan-Ivar: would still need to deal with contradictory values
15:39:15 <dom> Elad: I have an open issue on how to deal consistently with contradictions; shouldn't be blocking
15:39:45 <dom> RESOLVED: Proceed with PR matching proposal to have "application" (or "window"), "system", "exclude" as windowAudio hint
15:40:01 <dom> Topic: -> https://github.com/w3c/mediacapture-main/issues/1011 Should a muted video track be allowed to deliver black frames to its sinks?
15:40:01 <dom> [slide 23]
15:40:13 <dom> [Elad departs]
15:42:19 <dom> [slide 24]
15:44:46 <dom> Jan-Ivar: I'm not sure Firefox is correct in this case given https://w3c.github.io/mediacapture-main/#track-enabled
15:45:21 <dom> ... which suggests "playing"
15:45:46 <dom> Youenn: but it says "zero information content" which would imply no size change
15:45:59 <dom> Jan-Ivar: but that is qualified as meaning "only black frames"
15:46:26 <dom> Youenn: that would simplify the situation MediaRecorder
15:46:58 <dom> ... MediaStreamTrackProcessor would still receive black frames, which isn't ideal - I would prefer we avoid that
15:47:16 <dom> Guido: this is about disabled tracks rather than muted
15:47:36 <dom> ... this is part of the contradictions we've found with "muted" meaning not sending frames
15:47:44 <dom> ... Chrome sends a single black frame I think
15:48:09 <dom> ... I like the idea of not sending black frames, but this needs experimentation
15:49:00 <dom> ... to ensure this doesn't create compatibility issues
15:49:18 <dom> Youenn: the jsfiddle seems to show that this isn't only a single frame fwiw
15:50:22 <dom> Jan-Ivar: the argument for black frames was that enabled and muted were meant to be in control by the user on whether they're seen or not
15:50:55 <dom> Youenn: in Safari, muted and disabled aren't handled the same way; in one case it's at the source level, and in the other it's at the sink level
15:52:20 <dom> Dom: maybe we can have the right behavior with a single black frame that doesn't react to size changes
15:52:26 <dom> Youenn: +1
15:52:36 <dom> Jan-Ivar: that sounds good to me too
15:52:59 <dom> Guido: we'll need to look at the details in a PR
15:53:17 <dom> Youenn: and use that as a basis for experimenting in UAs
15:53:26 <dom> Topic: -> https://github.com/w3c/mediacapture-output/issues/141 Setting tab-wide audio output
15:53:26 <dom> [slide 27]
15:54:14 <dom> i/Topic:/RESOLVED: Proceed with a pull request that sends a single black frame without size reaction
15:55:49 <dom> [slide 28]
15:57:15 <dom> Present+ PeterThatcher
15:58:22 <dom> Jan-Ivar: this SGTM
15:58:53 <dom> ... I don't think lots of apps taking advantage of multiple speakers
15:59:12 <dom> Youenn: priority use case is distinguishing notifications from media output
16:00:03 <dom> Jan-Ivar: if this can help simplify, this would be nice
16:00:39 <dom> ... if a specific element picks an audio output, it overrides the tab-wide setting, right?
16:00:41 <dom> Youenn: yes
16:01:24 <dom> [discussion about exposing the "default" audio output as done in Chrome]
16:02:25 <dom> Dom: in terms of where, I would suggest whichever group should take ownership of mediacapture-output
16:03:11 <dom> ... overall, in general +1 to the proposal
16:03:42 <dom> Guido: proposal LGTM, but we should be careful with our usage of the word "default" which is already used in different meanings
16:04:20 <dom> Jan-Ivar: in Chrome, is there a difference on setSinkId="" and setSinkId="default"?
16:04:22 <dom> Guido: no
16:04:28 <dom> Jan-Ivar: but there may be with that proposal
16:04:41 <dom> Guido: right now it is defined as the OS default in Chrome
16:05:22 <dom> Jan-Ivar: right - but setSinkId="" would go back to the tab default vs OS default with setSinkId="default"
16:06:45 <dom> Youenn: when a VC app is embedded in another page which is also playing audio, what would be the most interesting approach: a single place to switch audio, or different settings in each context?
16:06:57 <dom> Guido: I'll have to think about it and discuss this internally
16:07:54 <dom> Youenn: this would help inform whether there needs to be a delegation mechanism to an iframe
16:09:22 <dom> Youenn: I'm hearing support from the WebRTC WG to proceed with such a proposal, integrated in mediacapture-output maintenance, and expecting feedback on different scopes in the future
16:09:56 <dom> Topic: -> https://github.com/w3c/webrtc-pc/ WebRTC API
16:09:56 <dom> Subtopic: Issue #3049 Validate an ICE server url is missing length check for username
16:09:56 <dom> [slide 32]
16:13:18 <dom> Youenn: let's have matching WPT; do you expect any web compat issue?
16:13:43 <dom> Jan-Ivar: unlikely
16:14:53 <dom> RESOLVED: proceed with proposal in PR #3050
16:15:02 <dom> Subtopic: Issue #3045 Inconsistent initialization of transceiver.receiver.track.getSettings()
16:15:02 <dom> [slide 33]
16:18:41 <dom> Youenn: I don't think the values necessarily make sense: e.g. a track initially receives no frame, so frameRate should be 0 in settings
16:19:01 <dom> ... Safari is using 0 everywhere as initial setting, except for aspectRatio
16:19:23 <dom> ... I agree we should converge on that, but think 0 would be a better starting point
16:20:59 <dom> Jan-Ivar: the configurationchange event in -extensions is related
16:21:49 <dom> Guido: not exposing when no frame has been received SGTM; if we expose something, exposing 0 like Safari
16:23:26 <dom> Jan-Ivar: I'm hearing preference for 0 over 640, with suggestions we might remove them entirely - to me the latter isn't very aligned with the constrainable pattern
16:24:51 <dom> Youenn: we could not expose them - that would mean we don't need to fire the configurationchange event
16:26:12 <dom> Jan-Ivar: if we want to keep the invariant of not changing the list of settings, then we should go with having default values to 0
16:26:33 <dom> ... what should we use for aspectRatio?
16:26:37 <dom> Youenn: 1?
16:26:42 <dom> Guido: NaN?
16:26:51 <dom> Jan-Ivar: NaN would be consistent with 0/0
16:27:08 <dom> RESOLVED: use 0-ish values for settings initiatilization
16:27:20 <dom> Topic: -> https://github.com/w3c/mediacapture-main/issues/1041 Clarify resizeMode
16:27:20 <dom> [slide 34]
16:30:21 <dom> Guido: no objection; this is what Chrome does and matches what I think people expect
16:30:27 <dom> RESOLVED: Proceed with proposal
16:30:33 <dom> RRSAgent, draft minutes
16:30:34 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/20-webrtc-minutes.html dom
18:29:52 <Zakim> Zakim has left #webrtc