- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 18 May 2022 09:20:18 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes and video recording of the WebRTC meeting held yesterday
(May 17) are available from:
https://www.w3.org/2022/05/17-webrtc-minutes.html
and copied as text below.
Dom
WebRTC May 2022 VI
17 May 2022
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/May_17_2022
[3] https://www.w3.org/2022/05/17-webrtc-irc
Attendees
Present
Bernard, Byron_Campen, Carine, Dom, Eero, Elad, Florent,
Jan-Ivar, Patrick, Riju, Tuukka_Toivonen, Youenn
Regrets
Harald
Chair
Bernard, Jan-Ivar
Scribe
dom
Contents
1. [4]Future meetings
2. [5]WebRTC
1. [6]RTP Header Extension Encryption
2. [7]Issue [8]#2735: webrtc-pc does not specify what
level of support is required for RFC 7728 (RTP pause)
3. [9]CaptureController
4. [10]WebRTC Encoded Transform
5. [11]Extensions to Media Capture and Streams
1. [12]PR #61: Add support for background blur and
configuration change event
2. [13]PR #59: Add powerEfficientPixelFormat constraint
6. [14]Dynamic Source for Screensharing
7. [15]WebRTC
1. [16]Simulcast issues
8. [17]Next meeting
[8] https://github.com/w3c/webrtc-pc/issues/2735
[12] https://github.com/w3c/webrtc-pc/pull/61
[13] https://github.com/w3c/webrtc-pc/pull/59
Meeting minutes
Recording: [18]https://www.youtube.com/watch?v=wlwi7491ERo
[18] https://www.youtube.com/watch?v=wlwi7491ERo
IFRAME:
[19]https://www.youtube.com/embed/wlwi7491ERo?enablejsapi=1&rel
=0&modestbranding=1
[19]
https://www.youtube.com/embed/wlwi7491ERo?enablejsapi=1&rel=0&modestbranding=1
Slideset: [20]https://lists.w3.org/Archives/Public/www-archive/
2022May/att-0000/WEBRTCWG-2022-05-17.pdf
[20]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf
Future meetings [21]🎞︎
[21] https://www.youtube.com/watch?v=wlwi7491ERo#t=65
Bernard: OK with moving up our next meeting to June 7th?
[22]WebRTC [23]🎞︎
[22] https://github.com/w3c/webrtc-pc/
[23] https://www.youtube.com/watch?v=wlwi7491ERo#t=240
[24]RTP Header Extension Encryption [25]🎞︎
[24] https://github.com/w3c/webrtc-extensions/issues/47
[25] https://www.youtube.com/watch?v=wlwi7491ERo#t=240
[26]RTP Header Extensions Encryption (cryptex) #106
[26] https://github.com/w3c/webrtc-extensions/pull/106
[27][Slide 12]
[27]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=12
Bernard: cryptex has completed IETF last call, with Sergio
incorporating changes from comments
[slide 13] an API proposal from Sep 2020 meeting
… with RTP headers being encrypted as all or nothing per bundle
… with a policy on whether this encryption is negotiable or
required
[28][Slide 14]
[28]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=14
[29]RTP Header Extensions Encryption (cryptex) #106
[29] https://github.com/w3c/webrtc-extensions/pull/106
Bernard: please review the PR
… that adds this API
… a little complicated since it needs change patching the
webrtc-pc steps
[30][Slide 15]
[30]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=15
Jan-Ivar: any reason it's not a readonly getParameters
Bernard: it is
… it's set per transceiver (although it's really per bundle)
youenn: lgtm
… could we simplify by not doing it per transceiver?
bernard: how would you handle the situation where you receive
an offer with different setting on different bundles?
… bundles don't get surfaced in the API
Byron: it could be a property on the transport, which is what
represents the bundle
Bernard: please review the PR and bring your comments there
Jan-Ivar: what happens if this gets changed with
setConfiguration?
Byron: really a bad idea :)
Bernard: should we prevent that from happening?
Byron: +1
… changing that is really awful, and so would writing tests for
it
… let's keep it simple in absence of a use case for it
Issue [31]#2735: webrtc-pc does not specify what level of support is
required for RFC 7728 (RTP pause) [32]🎞︎
[31] https://github.com/w3c/webrtc-extensions/issues/2735
[32] https://www.youtube.com/watch?v=wlwi7491ERo#t=720
[33][Slide 18]
[33]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=18
Bernard: this is about confusing about RFC 7728 (rtp stream
pause) and the level of required support for it
… this isn't required
Byron: there is one place in the spec that refers to it in the
API spec
… supporting the ~ flag requires support for 7728
… there seems to be support towards instead removing support
for that flag
[34][Slide 19]
[34]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=19
Bernard: not even sure why we would want to support it in the
SDP
Bernard: I think it shouldn't be there; let's make this as
ready for PR and figure out the right pull request to fix this
[35]CaptureController [36]🎞︎
[35]
https://github.com/w3c/mediacapture-handle/issues/12#issuecomment-1051021052
[36] https://www.youtube.com/watch?v=wlwi7491ERo#t=960
[37][Slide 32]
[37]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=32
[38]#190 Conditional Focus [screen-share]
[38] https://github.com/w3c/mediacapture-screen-share/issues/190
[39][Slide 33]
[39]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=33
Jan-Ivar: a proposal that helps addressing 3 issues, starting
with [40]https://github.com/w3c/mediacapture-screen-share/
issues/190
[40] https://github.com/w3c/mediacapture-screen-share/issues/190
[41]#57 .sendCaptureAction() misplaced [capture-handle]
[41] https://github.com/w3c/mediacapture-handle/issues/57
[42][Slide 34]
[42]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=34
[43]#12 .getCaptureHandle() misplaced? [capture-handle]
[43]
https://github.com/w3c/mediacapture-handle/issues/12#issuecomment-1051021052
[44][Slide 35]
[44]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=35
[45][Slide 36]
[45]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=36
Jan-Ivar: similar to Fetch's AbortController
… this can give more leeway on the acceptable time to give
focus
Elad: the controller patterns looks nice
… would you be open to exposing a getter of the controller on
the track?
… if an API returns several streams, would it return several
controllers?
jan-ivar: on the first question, not exposing it on the track
would be a feature
… adding a getter could be easily done by apps any way
elad: makes sense
jan-ivar: I haven't thought about multi-capture yet - happy to
look into it; I would expect one controller per capture
elad: different type of capture (e.g. tab, window, screen) may
require different type of controller
… e.g. focus on a screen doesn't make a lot of sense
jan-ivar: for "monitor", focus() would resolve immediately -
essentially a no-op
elad: with subclassing, we could determine whether there is a
focus() method - screen-subclass or audio-tracks wouldn't have
it
jan-ivar: that's worth discussing - subclassing feels a bit
excessive at this point, but to be discussed
youenn: separating functionality specific to a source from the
track is a good idea
… adding it to track isn't a great model
… I'm less sure about the API surface, but we can iterate on it
… focus() is one thing; supported actions is a different thing
… they may require different objects
… e.g. actions may benefit from being transferable
… whereas focus handling doesn't really make sense
elad: how quickly do we think we can agree on an API shape?
… I wouldn't want this to delay other long-started discussions
e.g. on conditional focus
Jan-Ivar: not big fan of subclassing; making the type of
capture source detectable would be more useful
dom: maybe let's focus on using this pattern for conditional
focus
elad: how do we deal with feature detection?
youenn: through the presence of the interface, as for other
APIs
elad: not necessarily convinced, but +1 if it helps moving
faster
dom: should this be discussed as part of screne-share repo then
jan-ivar: I'll create an issue in screen-share to help discuss
the API shape before we move to a PR
[46]WebRTC Encoded Transform [47]🎞︎
[46] https://github.com/w3c/webrtc-encoded-transform
[47] https://www.youtube.com/watch?v=wlwi7491ERo#t=2174
[48]PR #132
[48] https://github.com/w3c/webrtc-encoded-transform/pull/132
[49][Slide 39]
[49]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=39
youenn: we agreed to add a generateKeyFrame API
… adding the frame timestamp would be a good addition, but this
may result in having to have multiple timestamps when dealing
with multiple RIDs
[50][Slide 40]
[50]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=40
youenn: proposing instead to make the method apply to a single
rid
aboba: lgtm
youenn: ok, so will finalize the PR
[51]Extensions to Media Capture and Streams [52]🎞︎
[51] https://github.com/w3c/mediacapture-extensions/
[52] https://www.youtube.com/watch?v=wlwi7491ERo#t=2369
[53]PR #61: Add support for background blur and configuration change
event [54]🎞︎
[53] https://github.com/w3c/mediacapture-extensions/pull/61
[54] https://www.youtube.com/watch?v=wlwi7491ERo#t=2370
[55][Slide 41]
[55]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=41
youenn: lots of background blur done with canvas and WebGL
today
… OSes are now adding support for background blur
… the intel team has made measurements showing that OS
background blurs gives a 2x power improvement over JS-based
blur
… also, if the OS is already providing it, makes no sense to
add another layer of blurring
[56][Slide 42]
[56]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=42
youenn: proposal is to add a backgroundBlur constraint, a
capability & a setting
… this would be a boolean constraint, as a starting point
… a double [0,1] range may be worth discussing, but I suggest
starting with a boolean approach
… interested in feedback in the approach, and on the boolean vs
double discussion?
jan-ivar: lgtm
riju: would shifting to double later be an option?
youenn: not sure about the migration path; it could be a new
constraint which would work on a clear definition
… hearing support, so we can finalize and merge the PR then
[57][Slide 43]
[57]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=43
youenn: the same [58]PR #61 also includes a configuration
change event
… since the OS setting can change outside of the UA control
[58] https://github.com/w3c/mediacapture-extensions/pull/61
dom: how broadly would this event apply? any constraints? a
subset?
youenn: any track setting
jan-ivar: how would handle "exact" on a backgroundBlur
applyConstraint?
youenn: if set at the OS level, it would reject
jan-ivar: ... but that only applies to "exact" constraint
youenn: right
jan-ivar: a UA could implement this and provides this
per-track?
youenn: good question to discuss
… on iOS if you disable echoCancellation, it can't be disabled
for a single track - so there are precedents
jan-ivar: apps can turn this on & off with applyConstraints -
is that OK?
youenn: the browser could keep control on that within the
constraints framework
florent: which capabilities would trigger configuration change?
… you mentioned OS level ones
… what if a device is open in several browsers and one would
change e.g. the exposure?
youenn: we usually try to hide this - so the configuration
change event will be at the discretion of the UA
… if two pages are capturing, the UA is in control
… but we need to be careful about broadcasting events across
origins
jan-ivar: [on the chat] similar to devicechange we should add
fuzzing
florent: +1 otherwise it could be used as a communication
channel
youenn: florent, could you comment in that direction on the PR?
… hearing consensus in general on [59]PR #61
[59] https://github.com/w3c/mediacapture-extensions/pull/61
jan-ivar: rough agreement at least :)
[60]PR #59: Add powerEfficientPixelFormat constraint [61]🎞︎
[60] https://github.com/w3c/mediacapture-extensions/pull/59
[61] https://www.youtube.com/watch?v=wlwi7491ERo#t=3164
[62][Slide 43]
[62]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=43
youenn: submitted by henrik
… some cameras generation MJPEG video frames, which can have a
negative impact on power consumption
… proposal is to add a new constraint to help
jan-ivar: sounds a good approach
dom: when would you not want this?
youenn: for specific resolution capture, or e.g . for a single
frame capture
… the issue is that it's hard to have a good default with
backwards compat
… there is leeway for the UA to pick an efficient camera
dom: but then shouldn't this be the UA doing the right thing
rather than asking all developers to update their code?
jan-ivar: UAs might have different defaults on desktop vs
mobile
… with exposing the info is getSettings, you can decide to make
different compromise in terms of resolution vs power
consumption
dom: getSettings I understand; device selection feels icky
youenn: it wouldn't be allowed as a required constraint in
getUserMedia
jan-ivar: +1 to that - we don't want to exclusde people that
only have MJPEG cameras
dom: hearing we should be doing this
Dynamic Source for Screensharing [63]🎞︎
[63] https://www.youtube.com/watch?v=wlwi7491ERo#t=3734
[64][Slide 45]
[64]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=45
[65][Slide 46]
[65]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=46
[66][Slide 47]
[66]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=47
[67][Slide 48]
[67]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=48
[68][Slide 49]
[68]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=49
Elad: apps may not expect the content of the source to be
changing under their feet; e.g. in the context of a capture
handle
[69][Slide 50]
[69]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=50
[70][Slide 51]
[70]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=51
[71][Slide 52]
[71]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=52
elad: when the browser provides a feature that apps can't
predict or control, this creates a bad experience for app
developers (and ultimately end users)
[72][Slide 53]
[72]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=53
youenn: I'm a bit surprised by the API surface; I'll need
thinking some more, maybe the UA could do some heuristics
… not sure an app can determine whether it wants to support
this at the time of getDisplayMedia
… have you discussed a more flexible API?
… or is it hyperfocused on purpose?
elad: I'm up for giving more flexibility to apps
… re heuristics, they're not going to serve well all apps
equally
youenn: what would be the default?
elad: I would argue that backwards compat should default to the
existing behavior (not dynamic sources)
… but open to discuss this
jan-ivar: a bit concerned that it would let the application
limit the user choice
… I like the feature in Chrome, dynamic switching is a good
feature
… also questions when source changes whether focus should be
set
… not sure if we shoud allow any app decide whether or not to
allow the user to switch
… how much of the use case is tied to the selfCapture
constraint
… re capture handle, capturing a different tab is not much
different from navigating from a captured tab
elad: re allowing limiting user selection - right now, there is
no choice offered to the user, this would add a new choice
… re focus, with the current Chrome implementation of the UX,
you can only press the button when the tab is focused, so it's
not an issue for us at the moment; may need discussions if that
changes
… re self-capture, you're right that's the clearest use case;
but heuristics would not cater to all needs
jan-ivar: my main comment it would be best to leave this to UA
to experiment in this space before giving control to the app
… maybe with a special case for self-capture
elad: re UA experimenting - inside Google we already have
differing needs from different apps that heuristics cannot
handle
youenn: sourceChangeSupported would only be a hint? it would
only affect browser UI to the UA discretion
elad: open to either
… in Chrome, we would abide by the hint
jan-ivar: would you also want to add an event to report the
change of a source?
elad: not at the moment
youenn: this could be surfaced as configuration change
jan-ivar: I'm not supportive this, but looking at the defaults
for a bit
… I think the constraint should default to allow source change
(thus a preventSourceChange)
elad: works for me
… re not supportive - can you say more?
jan-ivar: not convinced we can't find good cross-apps
heuristics?
… I'm hearing source change is harmful primarily on
self-capture
… it shoudl also not apply to getViewportMedia
youenn: I think a hint would leave room for UAs to experiment,
with a good default
jan-ivar: a hint avoidSourceChange limited to getDisplayMedia?
elad: sounds good to me
jan-ivar: sounds worth iterating on
dom: would be good to get more clarity on non-self-capture use
cases; but the hint may be a good enough compromise
… usage of capture handle could be part of heuristics
elad: I ack that this is mostly interesting for self-capture
youenn: then this could be left to developers to pick
getDisplayMedia vs getViewportmedia
elad: but getDisplayMedia is still a long way before being
available
jan-ivar: but adding features to getDisplayMedia when we know
it's unsafe, which removes incentives to getViewport media
elad: but we can't wait until getViewportMedia shows gaining
adoption
jan-ivar: would be OK with a hint that we could deprecate
… not super excited about it, but won't block it either
elad: rough agreement!
[73]WebRTC [74]🎞︎
[73] https://github.com/w3c/webrtc-pc/
[74] https://www.youtube.com/watch?v=wlwi7491ERo#t=5730
Simulcast issues [75]🎞︎
[75] https://www.youtube.com/watch?v=wlwi7491ERo#t=5738
[76][Slide 20]
[76]
https://lists.w3.org/Archives/Public/www-archive/2022May/att-0000/WEBRTCWG-2022-05-17.pdf#page=20
Byron: ultimately, this cluster of issues boils down to: the
Simulcast IETF spec means we have to allow a remote description
to remove a rid at will
… the spec has a mix of language that seems to disallowing it
and other dealing with it at least for initial answers
… we've got to decide how to handle this discrepancy
… we *have* to allow removal from a remote description; adding
new simulcast encodings - we're not forced to allow this, and I
don't see a reason to allow it
… unless there are concrete use cases to add encodings to the
simulcast envelop after the initial negotiation, I don't think
we should allow it
… does anybody has a concrete use case for it?
bernard: couldn't think of one
byron: the other somewhat harder wrinkle is SDP negotiation can
reorder RID at will
… the meaning that the order has in the simulcast attribute is
related to transmission priority which isn't really something
webrtc-pc deals with
… the simulcast spec is somewhat handwavy on this, with a
SHOULD we could ignore
… but with a reoffer with a different order of RIDs, we kind of
have to re-use the same order in the answer even if it doesn't
impact the [[SendEncodings]] slot
… as discussed in [77]#2723
[77] https://github.com/w3c/webrtc-pc/issues/2723
youenn: could we reject on a different order to simplify? or
are there use cases for this?
byron: with e.g. an invalidmodificationerror?
youenn: yes
byron: that might be acceptable; I don't expect this would
cause too much trouble practically
… this may be a spec violation
… mirroring the order without messing with [[SendEncodings]] is
probably not too hard to specify
Bernard: let's refine the recommendations in the issues
Byron: particularly looking for input on [78]#2723
… to open the path to a PR
[78] https://github.com/w3c/webrtc-pc/issues/2723
Bernard: thanks! Simulcast raises a number of complex issues!
Next meeting [79]🎞︎
[79] https://www.youtube.com/watch?v=wlwi7491ERo#t=6336
Bernard: scheduled on June 7; get in touch if you want to
suggest agenda items
Received on Wednesday, 18 May 2022 07:20:23 UTC