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