Meeting minutes
Recording: https://
Slideset: https://
Transient activation after getDisplayMedia 🎞︎
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
Elad: Chrome is working on aligning its transient activation policy with the spec
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
… I think we can proceed with a PR while we check in parallel with the HTML spec authors that this isn't creating problems
… transient activation remains ill-defined with lots of interop gaps
Elad: this could be a MAY or a SHOULD if that helps
Youenn: let's maybe adjust based on feedback from the HTML editors
Jan-Ivar: I don't think we need MAY given how flexible transient activation is
… Should we add consumption of the activation to the spec?
Elad: I think this was spec'd before that notion of consumption was defined; we could do that as a follow up
Jan-Ivar: +1
RESOLUTION: Proceed with a PR matching the proposal and file an issue on transient activation & focus in HTML repo
getDisplayMedia(): Window audio hint 🎞︎
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
… are there use cases the app would know better?
Johannes: this would be a line with how app can give a hint of what type of content they expect the user to share
… creating situations where the app is getting the wrong kind of audio isn't helpful
Elad: today, the browser only suggests sharing audio if the app requests it
… in most cases, capturing the audio associated with the app owning the window is a reasonable default
… but when they want something different, they already have another path by requesting getDisplayMedia a second time to get system audio
… this new approach would be more efficient and privacy-preserving
[clarification that "application" refers to Web app, and "audio application" refers to the captured application audio]
Jan-Ivar: may be use "window" vs "application"
… This would be a hint right?
Johannes: right
Jan-Ivar: sympathetic to the use case, not sure we would implement, no strong opinion
Youenn: will there be a mechanism for the web app to determine whether they're getting what they expect?
… also, beyond "window", should there be something about capturing tab audio (which is under UA control)?
Johannes: this wouldn't change how tab audio is captured
… in general, tab audio is less problematic - e.g. system audio can generate echo
Elad: this doesn't touch tab audio, nor preclude us to change tab audio later
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
… if the user selects a tab, what does "application" do?
Elad: if the user selects a tab, this hint doesn't apply
Jan-Ivar: what happens if I call gDM with `{video: true, windowAudio: application}`?
[missed]
Dom: will this replace https://
Johannes: yes
Jan-Ivar: would still need to deal with contradictory values
Elad: I have an open issue on how to deal consistently with contradictions; shouldn't be blocking
RESOLUTION: Proceed with PR matching proposal to have "application" (or "window"), "system", "exclude" as windowAudio hint
Should a muted video track be allowed to deliver black frames to its sinks? 🎞︎
[Elad departs]
Jan-Ivar: I'm not sure Firefox is correct in this case given https://
… which suggests "playing"
Youenn: but it says "zero information content" which would imply no size change
Jan-Ivar: but that is qualified as meaning "only black frames"
Youenn: that would simplify the situation MediaRecorder
… MediaStreamTrackProcessor would still receive black frames, which isn't ideal - I would prefer we avoid that
Guido: this is about disabled tracks rather than muted
… this is part of the contradictions we've found with "muted" meaning not sending frames
… Chrome sends a single black frame I think
… I like the idea of not sending black frames, but this needs experimentation
… to ensure this doesn't create compatibility issues
Youenn: the jsfiddle seems to show that this isn't only a single frame fwiw
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
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
Dom: maybe we can have the right behavior with a single black frame that doesn't react to size changes
Youenn: +1
Jan-Ivar: that sounds good to me too
Guido: we'll need to look at the details in a PR
Youenn: and use that as a basis for experimenting in UAs
RESOLUTION: Proceed with a pull request that sends a single black frame without size reaction
Setting tab-wide audio output 🎞︎
Jan-Ivar: this SGTM
… I don't think lots of apps taking advantage of multiple speakers
Youenn: priority use case is distinguishing notifications from media output
Jan-Ivar: if this can help simplify, this would be nice
… if a specific element picks an audio output, it overrides the tab-wide setting, right?
Youenn: yes
[discussion about exposing the "default" audio output as done in Chrome]
Dom: in terms of where, I would suggest whichever group should take ownership of mediacapture-output
… overall, in general +1 to the proposal
Guido: proposal LGTM, but we should be careful with our usage of the word "default" which is already used in different meanings
Jan-Ivar: in Chrome, is there a difference on setSinkId="" and setSinkId="default"?
Guido: no
Jan-Ivar: but there may be with that proposal
Guido: right now it is defined as the OS default in Chrome
Jan-Ivar: right - but setSinkId="" would go back to the tab default vs OS default with setSinkId="default"
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?
Guido: I'll have to think about it and discuss this internally
Youenn: this would help inform whether there needs to be a delegation mechanism to an iframe
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
WebRTC API 🎞︎
Issue #3049 Validate an ICE server url is missing length check for username 🎞︎
Youenn: let's have matching WPT; do you expect any web compat issue?
Jan-Ivar: unlikely
RESOLUTION: proceed with proposal in PR #3050
Issue #3045 Inconsistent initialization of transceiver.receiver.track.getSettings() 🎞︎
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
… Safari is using 0 everywhere as initial setting, except for aspectRatio
… I agree we should converge on that, but think 0 would be a better starting point
Jan-Ivar: the configurationchange event in -extensions is related
Guido: not exposing when no frame has been received SGTM; if we expose something, exposing 0 like Safari
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
Youenn: we could not expose them - that would mean we don't need to fire the configurationchange event
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
… what should we use for aspectRatio?
Youenn: 1?
Guido: NaN?
Jan-Ivar: NaN would be consistent with 0/0
RESOLUTION: use 0-ish values for settings initiatilization
Clarify resizeMode 🎞︎
Guido: no objection; this is what Chrome does and matches what I think people expect
RESOLUTION: Proceed with proposal