- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 21 May 2025 14:48:35 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of our call yesterday are available at:
https://www.w3.org/2025/05/20-webrtc-minutes.html
and copied as text below.
Dom
WebRTC May 2025 meeting
20 May 2025
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/May_20_2025
[3] https://www.w3.org/2025/05/20-webrtc-irc
Attendees
Present
Carine, Dom, Elad, FrederickSolenberg, Guido, Jan-Ivar,
JohannesKron, OlgaSharonova, PatrickRockhill,
PeterThatcher, SameerVijaykar, SunShin, Youenn
Regrets
-
Chair
Guido, Jan-Ivar, Youenn
Scribe
dom
Contents
1. [4]Transient activation after getDisplayMedia
2. [5]getDisplayMedia(): Window audio hint
3. [6]Should a muted video track be allowed to deliver black
frames to its sinks?
4. [7]Setting tab-wide audio output
5. [8]WebRTC API
1. [9]Issue #3049 Validate an ICE server url is missing
length check for username
2. [10]Issue #3045 Inconsistent initialization of
transceiver.receiver.track.getSettings()
6. [11]Clarify resizeMode
7. [12]Summary of resolutions
Meeting minutes
Slideset: [13]https://docs.google.com/presentation/d/
1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit and
[14]archived PDF copy
[13]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit
Transient activation after getDisplayMedia
[15][Slide 10]
[15]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#10
[16][Slide 11]
[16]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#11
[17][Slide 12]
[17]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#12
[18][Slide 13]
[18]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#13
[19][Slide 14]
[19]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#14
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
[20]getDisplayMedia(): Window audio hint
[20]
https://github.com/w3c/mediacapture-screen-share-extensions/issues/7
[21][Slide 17]
[21]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#17
[22][Slide 18]
[22]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#18
[23][Slide 19]
[23]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#19
[24][Slide 20]
[24]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#20
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 [25]https://github.com/w3c/
mediacapture-screen-share/pull/283/files ?
[25] https://github.com/w3c/mediacapture-screen-share/pull/283/files
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
[26]Should a muted video track be allowed to deliver black frames to
its sinks?
[26] https://github.com/w3c/mediacapture-main/issues/1011
[27][Slide 23]
[27]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#23
[Elad departs]
[28][Slide 24]
[28]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#24
Jan-Ivar: I'm not sure Firefox is correct in this case given
[29]https://w3c.github.io/mediacapture-main/#track-enabled
… which suggests "playing"
[29] https://w3c.github.io/mediacapture-main/#track-enabled
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
[30]Setting tab-wide audio output
[30] https://github.com/w3c/mediacapture-output/issues/141
[31][Slide 27]
[31]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#27
[32][Slide 28]
[32]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#28
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
[33]WebRTC API
[33] https://github.com/w3c/webrtc-pc/
Issue [34]#3049 Validate an ICE server url is missing length check
for username
[34] https://github.com/w3c/webrtc-pc/issues/3049
[35][Slide 32]
[35]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#32
Youenn: let's have matching WPT; do you expect any web compat
issue?
Jan-Ivar: unlikely
RESOLUTION: proceed with proposal in PR [36]#3050
[36] https://github.com/w3c/webrtc-pc/issues/3050
Issue [37]#3045 Inconsistent initialization of
transceiver.receiver.track.getSettings()
[37] https://github.com/w3c/webrtc-pc/issues/3045
[38][Slide 33]
[38]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#33
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
[39]Clarify resizeMode
[39] https://github.com/w3c/mediacapture-main/issues/1041
[40][Slide 34]
[40]
https://docs.google.com/presentation/d/1QZ95RV7XDIaRsQUyNdwtTiYYw4_AVCP5DqAx96ZM770/edit#34
Guido: no objection; this is what Chrome does and matches what
I think people expect
RESOLUTION: Proceed with proposal
Summary of resolutions
1. [41]Proceed with a PR matching the proposal and file an
issue on transient activation & focus in HTML repo
2. [42]Proceed with PR matching proposal to have "application"
(or "window"), "system", "exclude" as windowAudio hint
3. [43]Proceed with a pull request that sends a single black
frame without size reaction
4. [44]proceed with proposal in PR #3050
5. [45]use 0-ish values for settings initiatilization
6. [46]Proceed with proposal
Received on Wednesday, 21 May 2025 12:48:37 UTC