14:51:21 <RRSAgent> RRSAgent has joined #webrtc
14:51:26 <RRSAgent> logging to https://www.w3.org/2023/06/27-webrtc-irc
14:51:26 <Zakim> Zakim has joined #webrtc
14:51:27 <dom> Meeting: WebRTC June 2023 meeting
14:51:27 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/June_27_2023
14:51:27 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf
14:51:27 <dom> Chairs: HTA, Jan-Ivar, Bernard
14:51:32 <dom> RRSAgent, make log public
15:01:31 <dom> Present+ Dom, Bernard, Elad, Florent, Harald, PatrickRochill, Fippo, Henrik, AlfredHeggestad, SunShin, ColinRead
15:03:03 <dom> Recording is starting
15:03:15 <dom> Present+ Carine, FredericWang
15:03:24 <dom> Present+ Youenn
15:04:24 <dom> Present+ TimP, Guido
15:04:43 <dom> Present+ Jan-Ivar
15:05:11 <dom> Present+ PeterThatcher
15:06:35 <dom> Topic: -> https://github.com/w3c/mediacapture-screen-share/ Mediacapture-screen-share
15:06:35 <dom> Subtopic: Issue #268 Make CaptureController inherit from EventTarget
15:06:35 <dom> [slide 12]
15:07:07 <dom> Elad: I suggest making capturecontroller an eventTarget help making that object more useful - with a specific use case inspired by the screen capture mouse events
15:07:17 <dom> ... can easily think of more use cases
15:08:09 <dom> [+1 from Harald, Henrik, Youenn]
15:08:15 <dom> JIB: LGTM
15:08:28 <dom> Resolved: merge PR for #268
15:08:32 <dom> Subtopic: Issue #263 Improve upon CaptureStartFocusBehavior.no-focus-change
15:08:32 <dom> [slide 13]
15:09:01 <dom> Elad: this was discussed in the past and we decided to let the app express a preference that the UA is free to take into account or ignore
15:09:44 <dom> ... no-focus-change is ambiguous given Safari's model with MacOS windows picker
15:09:49 <dom> [slide 14]
15:10:34 <dom> Elad: proposed to add a new value "focus-capturing-application" and keep "no-focus-change" to be platform-independent, possibly to be deprecated in the future
15:11:18 <dom> youenn: I like "focus-capturing-application"; maybe we could already add a warning about "no-focus-change" that it will be deprecated (and leave it to implementations to figure out a deprecation schedule)
15:11:38 <dom> Elad: not sure if we want to commit to deprecate right away; will want to look at web compat
15:12:29 <dom> TimP: would support deprecating ASAP
15:12:44 <dom> Elad: right, need to consult data usage before committing
15:12:58 <dom> JIB: for other implementors, knowing whether we implement 2 or 3 values is important
15:13:12 <dom> ... otherwise, we would have to throw on unrecognized values
15:13:56 <dom> Harald: if we have deployed code that uses this, the usual magic is to not break running code which would require some deprecation timeline
15:14:58 <dom> Youenn: would be best to state the direction in the spec clearly, knowing that implementations will need to adjust over time
15:15:22 <dom> Present+ JaredSiskin
15:15:57 <dom> TimP: I wonder if this could be solved by feature detection and ensure that only 2 are ever implemented in a given browser
15:16:06 <dom> JIB: this would be concerning for web compat
15:16:15 <dom> Elad: +1
15:16:56 <dom> ... there may be value for "no-focus-change" in itself, e.g. for accessibility to reduce change
15:17:18 <dom> ... I propose we start by adding "focus-capturing-application" and have a separate conversation on deprecation
15:17:23 <dom> [JIB: +1]
15:17:40 <dom> Youenn: +1, as long as we converge reasonably quickly
15:17:52 <dom> Subtopic: Issue #261 Allow apps to avoid riskier display-surface types
15:17:52 <dom> [slide 15]
15:18:41 <dom> [slide 16]
15:20:59 <dom> [slide 17]
15:23:11 <dom> Youenn: dynamic changes might be tricky to manage - auto-pause might be a solution
15:23:32 <dom> ... combined with the current preference
15:23:58 <dom> Elad: when the user is offered the current screen, they may not understand they shouldn't which can create bad user experience
15:24:07 <dom> ... there isn't any hint to disable that
15:24:28 <dom> ... monitorExclusion would follow the footsteps of selfBrowserSurface
15:24:46 <dom> Youenn: I think a preference would be better than a hard-set requirement
15:25:03 <dom> Elad: the intent is for this to be a hint to the UA that it could ignore
15:25:36 <dom> ... in Chrome's case, it would remove the "monitor" option
15:26:10 <dom> Youenn: in MacOS, the user can dynamically change to the screen  - this wouldn't under the control of the browser UI
15:26:30 <dom> ... which would create inconsistencies
15:26:59 <dom> Elad: this would reduce the number of clicks in the Safari workflow
15:27:47 <dom> ... the OS itself could choose not to expose the monitor with that hint
15:28:05 <dom> TimP: I like this in principle, but think it would be hard to expose it in a non-confusing way to users
15:28:20 <dom> ... this will create unexpected variations for users from one meeting to another
15:28:48 <dom> Elad: this wouldn't be more confusing than shutting down abruptly an ongoing capture
15:29:07 <dom> TimP: still, users will ask "why can't i share my screen when I could on my previous call?"
15:29:36 <dom> Elad: the app doesn't have to use that hint if it finds it too hard to communicate to end users
15:30:20 <dom> JIB: the use case makes a lot of sense; I support this; while I dislike limiting user choice, sharing full screen is risky which makes me supportive
15:30:30 <dom> ... what would be the default?
15:30:35 <dom> Bernard: we're running out of time
15:30:41 <dom> Elad: let's follow up on github
15:30:52 <dom> Topic: -> https://github.com/w3c/webrtc-extensions/pull/167 Requesting keyframes via setParameters (WebRTC Extensions)
15:30:52 <dom> [slide 20]
15:31:50 <dom> Fippo: this proposal would rely on WebCodecs-defined WebIDL - how do we feel about this?
15:32:31 <dom> JIB: I like that proposal direction; not sure about the value of reusing WebCodecs IDL which may evolve in ways  that wouldn't work for us
15:33:01 <dom> Fippo: true - that's already the case since there are codecs-specific fields already which we wouldn't want to import
15:33:19 <dom> Florent: we would still want to keep encoding options in sync with WebCodecs when they make sense
15:34:08 <dom> Youenn: WebCodecs is per frame when setParameters isn't - I prefer a separate dictionary, but keep the definition aligned with WebCodecs
15:34:19 <dom> JIB: if I specify false - what does that mean?
15:34:28 <dom> Fippo: you're not requesting keyframes
15:34:43 <dom> JIB: and setParameters() with no change but keyframe true, I get a keyframe?
15:34:46 <dom> Fippo: yes
15:34:56 <dom> JIB: a bit odd of an API, but it makes sense for synchronicity
15:35:12 <dom> Florent: setParameter is supposed to resolve the promise when all the params have been applied
15:35:31 <dom> ... how would this sequenced with the keyframe?
15:35:54 <dom> Fippo: we can't know when a keyframe would be generated; and it gets more complex with several layers
15:36:08 <dom> ... so we wouldn't wait for the keyframe to resolve the promise
15:36:10 <dom> Florent: SGTM
15:36:41 <dom> Fippo: I'll update the PR in that direction, with a similar but different object than WebCodecs
15:37:18 <dom> RESOLVED: use second parameter with a similar but different dictionary than WebCodecs, clarify promise doesn't wait for the keyframe to resolve
15:37:24 <dom> Topic: -> https://github.com/w3c/webrtc-nv-use-cases/ WebRTC Extended Use Cases
15:37:25 <dom> [slide 23]
15:37:43 <dom> Subtopic: Remove Use Cases That Don’t Add New Req’ts PR #112 PR #113
15:37:43 <dom> [slide 25]
15:39:12 <dom> TimP: when this was raised, it was brought up this could be achieved with a JS library, which WHIP has kind of demonstrated
15:39:25 <dom> ... unless anyone can think of a use case where UA assistance would be needed
15:39:41 <dom> s/WHIP/WHEP/
15:39:50 <dom> ... (although WHEP hasn't been implemented yet)
15:40:12 <dom> Bernard: in future meetings we would discuss streaming which relates to WHIP and WHEP as well
15:40:26 <dom> ... in the meantime, this use case doesn't bring any requirement - any pushback on removing it?
15:40:55 <dom> TimP: the only reason would be to validate this is a valid usage of WebRTC
15:41:29 <dom> Bernard: the fact that WISH took this up kind of validates this (and they don't need our validation)
15:42:05 <dom> JIB: I support our use cases should only drive decisions in our WG
15:43:40 <dom> Dom: I think keeping track of edge usages is interesting, but I'm not sure the WG is equipped for that
15:43:51 <dom> ... and this document should really focus on use cases that generate new requirements
15:44:26 <dom> Harald: not sure; but not strong objection either
15:44:26 <dom> RESOLVED: remove section 3.9
15:44:35 <dom> [slide 26]
15:47:04 <dom> Youenn: related to N22 - we should look at what we're defining in the WG
15:47:21 <dom> ... the only thing we need to define is efficient access to a VideoFrame
15:48:53 <dom> Dom: remaining question for me is whether there are memory-copy reduction requirements the WebRTC WG would need to cover
15:49:01 <dom> Bernard: this is being worked on, but in the Media WG
15:49:24 <dom> TimP: yes, I think this has been overtaken by events (i.e. it is now available)
15:50:04 <dom> ... I don't think there is anything left for us - even though clearly this is something that WebRTC supports
15:50:29 <maximodiaz> maximodiaz has left #webrtc
15:50:35 <dom> ... ensuring proper integration with ML is definitely important, but maybe no longer in our scope
15:50:44 <maximodiaz> maximodiaz has joined #webrtc
15:51:02 <dom> JIB: N22 is a superset requirement that satisfies funny hats & ML
15:51:13 <dom> Bernard: it doesn't really satisfy fully ML
15:51:28 <dom> JIB: I was going to suggest a requirement about "processing" rather than "manipulation"
15:51:44 <dom> Harald: I think the requirement was misguided in tying it to GPU
15:52:02 <dom> ... not all media manipulation needs or benefits GPU
15:52:19 <dom> Bernard: typically audio doesn't go through GPU
15:52:25 <dom> ... so N22 should be revised
15:52:44 <dom> RESOLVED: remove ML use case section 3.7 #PR 113
15:52:54 <dom> Bernard: we'll also update N22 for funny hats
15:53:11 <dom> Subtopic: Process changes
15:53:11 <dom> [slide 31]
15:54:14 <dom> TimP: how do we shape the doc moving forward? seeking guidance on the relationship between explainers and the use case docs? conversely, should we ensure API changes tie back to use cases?
15:56:35 <dom> Dom: a possibility would be to remove use cases & requirements that already have a home in a spec/explainer?
15:57:21 <dom> JIB: an explainer fulfills a different role - having early use cases remain useful
15:57:41 <dom> Dom: right, but they could be still be sequenced
15:57:47 <dom> JIB: maybe
15:59:50 <dom> Bernard: conversely, would we want to require use cases for new API proposals?
16:00:19 <dom> Dom: we already have a goal of having API proposals be accompanied by explainers that have fairly detailed use cases
16:00:41 <dom> TimP: then this document would be a queue of future use cases without backing proposals? This sounds workable
16:02:09 <dom> Harald: it often feels easier to focus on an explainer with a specific proposal than to get consensus on an addition to the use case doc
16:02:26 <dom> ... or we need a lower bar of entry to the document
16:03:00 <dom> TimP: there are a bunch of developer requirements that are impossible to implement without getting implementers on board
16:03:13 <dom> Topic: IceController
16:03:13 <dom> Repo: https://github.com/w3c/webrtc-extensions/
16:03:13 <dom> Subtopic: Issue #166 PR #168 - prevent candidate pair removal
16:03:13 <dom> [slide 34]
16:03:32 <dom> Present+ Sameer
16:03:47 <dom> Sameer: please keep feedback coming on #168
16:03:52 <dom> Subtopic: Issue #170 #171 - candidate pairs management
16:03:52 <dom> [slide 37]
16:04:59 <dom> [slide 38]
16:07:13 <dom> [slide 39]
16:08:42 <dom> JIB: if you use a promise, would there also be an event?
16:08:56 <dom> Sameer: the event already exists, so it would have to be fired as well
16:09:21 <dom> JIB: with pruning and preventDefault, this could get awkward and footgunny
16:09:48 <dom> Sameer: prune() would not fire an event - it prunes it immediately without an event
16:10:15 <dom> JIB: we should be consistent; re promise, can it fail?
16:10:34 <dom> Sameer: in other additions we're considering, there is an event for deletion
16:10:50 <dom> ... the only possible failure I can think of is pruning a candidate pair that doesn't exist
16:11:04 <dom> JIB: I meant fail async - input validation can be done sync
16:11:17 <dom> Sameer: can't think of anything of failure for prune()
16:11:36 <dom> ... for setSelected(), there may be async failure cases depending on the implementation approach
16:12:19 <dom> Youenn: is it fine to prune the currently selected candidate pair? if we don't allow it, it would have to be async
16:12:49 <dom> Sameer: pruning the current selected pair is the equivalent of a pair going away for any other reason (e.g. network interface going down)
16:13:16 <dom> Youenn: but this could lead to situation of pruning the selected candidate pair without realizing it due to race conditions
16:14:28 <dom> ... why does prune() take a sequence? is it for an optimization? (could use variadic arguments)
16:14:41 <dom> Sameer: indeed, that's to optimize it
16:14:49 <dom> TimP: +1 to allow for several apirs
16:14:52 <dom> s/apirs/pairs/
16:15:25 <dom> ... I'm slightly worried that the API isn't taking account the asymetry of control
16:15:48 <dom> Sameer: setSelected fails immediately if called on the controlled side
16:16:22 <dom> TimP: maybe other asymetricalities in the timing of things; maybe to discuss on a specific PR
16:16:59 <dom> Peter: I think we should allow the controlled side to override to set a selected pair, but it should be an explicit call
16:17:31 <dom> Sameer: that might make sense, indeed
16:17:52 <dom> ... any thoughts selection by directly sending media vs doing an exchange?
16:18:22 <dom> JIB: I'm nervous that the ICE Transport is running async and with PC being a huge state machine - there could be a lot of races e.g. when considering ICE restart
16:18:35 <dom> ... would these decisions be reversed by an ICE restart?
16:18:51 <dom> Sameer: I expect ICE restart would be a clean slate
16:19:02 <dom> JIB: I'll need to think more about potential races
16:19:27 <dom> TimP: re ICE round trip, it should happen, to the risk of messing up bandwidth estimation
16:19:51 <dom> RRSAgent, draft minutes
16:19:52 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/27-webrtc-minutes.html dom
16:20:21 <dom> Peter: wrt ICE restart - ICE restart is make-before-break, typically adding candidate pairs
16:20:38 <dom> ... would newly added candidate pairs be able to override already selected pairs?
16:20:44 <dom> ... I'm inclined the app should be in control
16:21:45 <dom> ... There is no reason both sides would need to use the same pairs
16:23:10 <dom> ... I would support sending media right away when selecting a pair; I don't see a good reason to wait for another roundtrip
16:23:27 <dom> Topic: -> https://github.com/w3c/webrtc-encoded-transform/issues/172 Encoded Transform Codec Negotiation
16:23:27 <dom> Repo: https://github.com/w3c/webrtc-encoded-transform
16:23:27 <dom> [slide 42]
16:23:46 <jtsiskin> jtsiskin has joined #webrtc
16:24:30 <dom> [slide 43]
16:25:06 <dom> [slide 44]
16:26:09 <dom> [slide 45]
16:26:51 <dom> Bernard: what does it mean "not to know about it", or "to know about it"?
16:27:11 <dom> Harald: the UA has to know about the packetization mode
16:27:35 <dom> Bernard: so having a WebCodec decoder counts as "known"?
16:27:50 <dom> Harald: no, this is in the context of the WebRTC chain
16:29:57 <dom> [slide 46]
16:30:19 <dom> Harald: I re-use mime types for packetization mode - in most cases, you would want to use a simple packetization mode (not H264)
16:30:24 <dom> [slide 47]
16:30:53 <dom> Harald: note the payload type uses out-of-range SDP payload types
16:31:12 <dom> [slide 48]
16:31:14 <dom> [slide 49]
16:31:29 <dom> Harald: have filed PR #186
16:31:54 <dom> [youenn on the chat: My main question is on which IETF work would be needed here. payloadType setter on a frame seems fine, I am less sure about the other API.]
16:32:19 <dom> Harald: I don't think any IETF work is needed, as long as we recognize we would be using non-standardized mime type
16:32:28 <dom> ... for packetization
16:33:14 <dom> JIB: this makes sense; I see there are pre-negotiation methods, then a negotiation would happen where the other side may reject a payload type
16:33:34 <dom> ... would we need new APIs to set codecs?
16:33:43 <dom> Harald: I think we should align with what Florent is proposing
16:33:45 <dom> JIB: +1
16:34:09 <dom> TimP: much to my chagrin, I see the need to involve SDP in this
16:34:27 <dom> ... how will we deal with scope rules of SDP, RTX, etc?
16:34:40 <dom> Harald: I haven't figured that out yet
16:35:06 <dom> ... at the moment, we have a very imprecise surface for deciding what kind of protection features we want to turn on
16:35:14 <dom> ... that's done through SDP munging, which is sad
16:35:23 <dom> ... we should figure that out, and apply it to this case as well
16:35:36 <dom> ... (deferring to a previously unsolved problem in other words)
16:36:00 <dom> JIB: there are only methods to add things, not remove; maybe this could be part of setConfiguration?
16:36:32 <dom> Harald: I thought about adding/removing - we're able to turn off codecs by removing them with setCodecs
16:36:57 <dom> ... I prefer to focus on well-known needs, and small-scoped APIs rather than extending setConfiguration
16:37:21 <dom> Harald: any sentiment on whether we should adopt this?
16:37:23 <dom> [JIB: +1]
16:37:44 <dom> [Jared, Bernard, Guido: +1]
16:37:58 <dom> RESOLVED: Adopt PR #186 with details to be discussed in the PR
16:38:38 <dom> JIB: Youenn's comment on IETF?
16:38:56 <dom> Bernard: there is a proposed work item in front of the IESG in this space (SKIP?)
16:39:41 <dom> RRSAgent, draft minutes
16:39:43 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/27-webrtc-minutes.html dom
16:46:11 <jtsiskin_> jtsiskin_ has joined #webrtc
18:18:49 <Zakim> Zakim has left #webrtc