IRC log of webrtc on 2022-01-18

Timestamps are in UTC.

15:54:50 [RRSAgent]
RRSAgent has joined #webrtc
15:54:50 [RRSAgent]
logging to https://www.w3.org/2022/01/18-webrtc-irc
15:54:53 [Zakim]
Zakim has joined #webrtc
16:02:33 [dom]
Recording is starting
16:02:56 [dom]
Agenda: https://www.w3.org/2011/04/webrtc/wiki/January_18_2022
16:03:22 [steely_glint]
steely_glint has joined #webrtc
16:04:11 [dom]
Scribe+
16:04:27 [dom]
Slideset: https://lists.w3.org/Archives/Public/www-archive/2022Jan/att-0002/WEBRTCWG-2022-01-18.pdf
16:04:50 [dom]
Topci: Recent CfAs and CfCs
16:04:56 [dom]
[slide 8]
16:05:07 [dom]
s/Topci/Topic/
16:05:24 [dom]
Bernard: Region capture now adopted with repo in w3c org
16:05:25 [dom]
[slide 9]
16:05:56 [dom]
Topic: Agenda review
16:05:58 [dom]
[slide 10]
16:06:15 [dom]
Topic: WebRTC NV Use Cases
16:06:17 [dom]
Repo: https://github.com/w3c/webrtc-nv-use-cases/
16:06:38 [dom]
TimP: PR #73 to update the use cases based on the December discussions, now merged
16:06:49 [dom]
... there may needs new requirements, currently place holders
16:06:55 [dom]
... please look at the PR and comment on it
16:07:22 [dom]
... last time we talked about decentralized messaging and came to the conclusion we needed input from practionner in that space
16:07:43 [dom]
... I've invited Kegan to provide input based on his experience
16:07:55 [dom]
[slide 13]
16:08:18 [dom]
Kegan: I work at Matrix, will start with some context before going into WebRTC & service worker
16:08:49 [dom]
... matrix has voice support which uses WebRTC in the browser, based on matrix signalling
16:09:03 [dom]
Present+ Harald, Youenn, TimP, Bernard, Jan-Ivar, Kegan, Dom
16:09:06 [dom]
[slide 14]
16:09:29 [dom]
Present+ Carine, Guido, Elad, TonyHerre, BenWagner
16:10:06 [dom]
Kegan: because webrtc can't run in a service worker, we rely on web sockets proxy through a central server
16:10:18 [dom]
... in 2021, we developed our own overlay network, Pinecone
16:10:55 [dom]
... limited in which nodes a browser can directly connect to due to limitation of WebRTC in service workers
16:10:58 [dom]
[slide 16]
16:11:28 [dom]
i/... in 2021/[slide 15]
16:12:10 [dom]
[slide 17]
16:12:23 [dom]
Kegan: no need to run long-live process in the background - anti-goal
16:13:00 [dom]
... fetch can't work as an alternative to webrtc due to discovery and comm with local nodes
16:13:02 [dom]
[slide 18]
16:13:24 [dom]
Kegan: any of the 4 listed proposals would work, I'm guessting B or C might be the easiest
16:14:18 [dom]
Bernard: we've had proposals to have datachannels in workers, also peerconnection in workers
16:14:26 [dom]
Kegan: that matches proposals C & D
16:14:35 [dom]
... making new connections would be preferable
16:14:45 [dom]
... might still be messy, but would be tractable
16:14:55 [dom]
Bernard: any additional requirement for ICE?
16:15:02 [dom]
Kegan: think what we have is enough at the moment
16:15:16 [dom]
JIB: did you consider Shared Worker?
16:15:34 [dom]
... They allow to share between multiple tabs without being a Service Worker
16:15:47 [dom]
... I guess they can't outlive the last tab linked to them
16:15:55 [dom]
... but they may help remove some of the concerns with service worker
16:16:01 [dom]
Kegan: sounds appealing indeed
16:16:12 [dom]
... also helps reduce duplicate computation
16:16:20 [dom]
JIB: do you need outliving the last tab?
16:16:37 [dom]
Kegan: not needed; would be useful, but we understand that it may not be reasonable given the lack of user visibility
16:16:42 [dom]
JIB: so useful but not necessary
16:20:25 [dom]
Youenn: you could create a PC in a shared worker, transfer it to a service worker which would intercept the fetches
16:20:29 [dom]
Kegan: that sounds great
16:20:59 [dom]
s/a peerconnection/a data channel/
16:21:33 [dom]
TimP: do we need to special case transfer to SW for datachannel?
16:21:48 [dom]
Youenn: the proposal on the table for datachannel is to make them transferable anywhere
16:22:03 [dom]
... this would add the need to create a peerconnection in any worker
16:22:18 [dom]
JIB: or we could limit creation to shared worker
16:22:40 [dom]
Youenn: a service worker not being a stable context makes it not a great target for long lived objections such as a PC
16:22:46 [dom]
... but there is probably no harm in allowing it
16:23:08 [dom]
JIB: this may create concerns of having PC in service workers with no matching tabs
16:23:25 [dom]
Youenn: this is already possible with fetch, in a very constrained set of situations
16:23:34 [dom]
... probably needs more evaluation
16:24:55 [dom]
TimP: so in this scenario, could a push notif set off a cascade of updates?
16:25:16 [dom]
Youenn: lots of reluctance in doing complex tasks without visible UI in a tab
16:25:38 [dom]
Ben: re datachannels in service workers, is it possible to keep a datachannels for more than one request in a service worker?
16:26:02 [dom]
Youenn: good point - that will depend on each browser re when they might kill a service worker, which is based on UA-dependent heuristics
16:26:09 [dom]
... that might make this tricky indeed
16:26:43 [dom]
JIB: can data channels be transfered anywhere or just dedicatedworker?
16:26:50 [dom]
Harald: we haven't specified it
16:26:56 [dom]
Youenn: we have it in webrtc-extensions
16:27:05 [dom]
Harald: transferability isn't specific to a type of worker AFAIK
16:27:29 [dom]
Youenn: the datachannel interface is exposed in Worker which covers all type of workers
16:27:43 [dom]
TimP: what's a sensible next step then?
16:28:39 [dom]
Youenn: an issue should be raised on webrtc-extensions re creating PC in workers
16:28:52 [dom]
Harald: I think we need an explainer that shows how it all fits together and what it enables
16:29:20 [dom]
... in webrtc-extensions
16:29:45 [dom]
... a mark down file with the a description of an implementation of a P2P use case, that describes the changes needed
16:29:47 [dom]
youenn: +1
16:30:07 [dom]
TimP: what impact on the use case?
16:30:18 [dom]
... currently has no associated requirements
16:30:52 [dom]
Harald: might link to the explainer
16:31:06 [dom]
Bernard: you could make a start based on what we've been talking about
16:31:42 [dom]
JIB: maybe slide 16 can be boiled down to requirements
16:32:15 [dom]
TimP: I can take the shot at the explainer
16:32:39 [dom]
Kegan: will be happy to help
16:32:41 [dom]
Harald: likewise
16:32:49 [dom]
RRSAgent, draft minutes
16:32:49 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
16:32:59 [dom]
Topic: Media Capture Transform
16:33:05 [dom]
Repo: w3c/mediacapture-transform
16:33:16 [dom]
[slide 21]
16:33:37 [dom]
Harald: next step for this document is FPWD - it triggers licensing requirement based on W3C patent policy
16:34:04 [dom]
... in terms of requirements, FPWD doesn't require consensus, no W3C endorsement, but should document oustanding issues
16:34:28 [dom]
[slide 23]
16:34:46 [dom]
... 9 open issues on the spec
16:34:48 [dom]
[slide 24]
16:35:24 [dom]
... proposed dispositions for issue #4 (leave open for later)
16:35:31 [dom]
... #20 (adopt suggested text)
16:35:53 [dom]
... #23 (documented as issue in spec, leave open for later)
16:36:27 [dom]
... #26 - refocused on muted tracks, which the spec now addresses with an attribute suggested by Jan-Ivar - closed issue
16:36:31 [dom]
[slide 25]
16:36:42 [dom]
... #29 documented in spec as issue, left open for alter
16:36:45 [dom]
s/alter/later/
16:37:17 [dom]
... #30 memory locality - leave open, exploratory, not needed prior to FPWD
16:37:51 [dom]
... #34 relationship to WebGPU - also exploratory; WebCodecs has a proposed relationship to WebGPu that may help
16:38:08 [dom]
... #65 - feels like an issue on VideoFrame i.e. for WebCodecs
16:38:12 [dom]
[slide 26]
16:38:28 [dom]
Harald: I don't think we have any blocker to move to FPWD
16:38:43 [dom]
... I would like to propose we start a CfC after this call
16:39:06 [dom]
JIB: +1 to your proposed issue disposition
16:39:35 [dom]
... I've opened issue #71 for an additional clarification remaining on audio processing
16:39:43 [dom]
Harald: indeed a left over
16:40:07 [dom]
Youenn: in the same vein, the use cases include audio, that probably should be updated
16:40:48 [dom]
Harald: +1 on clearing out these pieces of audio remains
16:43:25 [dom]
Youenn: would be good to remove these remains indeed
16:43:38 [dom]
Harald: will make a PR toward that, and then we'll run the CfC
16:43:43 [dom]
[slide 27]
16:44:06 [dom]
Topic: WebRTC Extensions
16:44:11 [dom]
Repo: w3c/webrtc-extensions
16:44:31 [dom]
[slide 30]
16:44:32 [dom]
Bernard: PR #125 add an api to request key frames with 3 end points
16:44:35 [dom]
[slide 31]
16:44:49 [dom]
Bernard: the CfC concluded yesterday, with a concern raised on synchronization
16:45:08 [dom]
... no timestamp returned compared to PR #37
16:45:43 [dom]
... and issue #127 raising the question to sync with key changes (e.g. when someone new joins a call)
16:46:15 [dom]
... any opinion on whether the timestamp from PR #37 matters?
16:46:29 [dom]
Harald: it matters exactly for the described use case
16:46:42 [dom]
Youenn: #127 is only about SFrameTransform not for ScriptTransform
16:46:54 [dom]
... ScriptTransform has access to all encoded frames
16:47:08 [dom]
Harald: you know whether it's a keyframe, but not if it's the one you've asked for
16:47:44 [dom]
Youenn: the only case where it matters is when you actually want to only apply encryption at the 2nd frame, not the 1st one
16:47:57 [dom]
... we don't need a timestamp for that, we can resolve a promise when the next read will be called
16:48:00 [dom]
... that's what in the PR
16:48:09 [dom]
... I don't know if that's enough, but it should be close
16:48:12 [dom]
[slide 32]
16:48:26 [dom]
Bernard: by the time the key frame is returned, it may already have been encrypted
16:48:40 [dom]
... could you promise.all the situation?
16:51:10 [dom]
JIB: may be a footgun with a race condition; do we need the method on the Sender?
16:51:33 [dom]
Youenn: the use case for that wasn't related to encryption, but e.g. a simulcast situation
16:51:42 [dom]
... no timestamp needed for that
16:52:03 [dom]
Bernard: so we're willing to explore Promise.all vs an atomic method that generates a keyframe and set the keys
16:52:31 [dom]
Youenn: for #127, we need to define a behavior for SFrameTransform for sure
16:52:46 [dom]
Bernard: but not necessarily an atomic method?
16:53:43 [dom]
Youenn: to be seen
16:53:57 [dom]
... but that can be done in a later iteration, shouldn't block #125
16:54:06 [dom]
... #127 is needed to ship SFrameTransform though
16:54:14 [dom]
Topic: Capture Handle
16:54:28 [dom]
Repo: https://github.com/WICG/capture-handle
16:54:32 [dom]
[slide 35]
16:56:47 [dom]
[slide 36]
16:57:36 [dom]
Elad: previous proposal in this space assumed coordination between capturer and capturee
16:57:40 [dom]
[slide 37]
16:59:14 [dom]
[slide 38]
16:59:51 [dom]
[slide 39]
17:00:25 [steely_glint]
Scribe +
17:00:47 [dom]
[slide 40]
17:00:57 [steely_glint]
[Slide 40]
17:01:25 [steely_glint]
[Slide 41]
17:02:24 [steely_glint]
New proposal to allow more decoupled apps - not sharing common origin
17:02:33 [steely_glint]
[slide 42]
17:04:21 [steely_glint]
Dom: future is useful. Can it be more useful beyond capture-capturee use case ?
17:04:38 [steely_glint]
Dom: propsal is useful. Can it be more useful beyond capture-capturee use case ?
17:05:06 [dom]
s/future/feature/
17:05:25 [steely_glint]
Dom: cf old 'web intent' proposal
17:05:48 [dom]
-> https://paul.kinlan.me/reinventing-web-intents/ Reinventing Web Intents, Paul Kinlan 2017
17:06:15 [dom]
-> https://en.wikipedia.org/wiki/Web_Intents Web Intents description on wikipedia
17:07:06 [steely_glint]
youenn: MediaSession Handler API does something similar for play/pause
17:07:32 [steely_glint]
Youenn: but the security context is different.
17:08:16 [steely_glint]
https://developer.mozilla.org/en-US/docs/Web/API/MediaSession/setActionHandler
17:09:07 [steely_glint]
Elad: message can be sent by app, not just the user...
17:09:41 [steely_glint]
Elad: The actions are different in this context
17:10:50 [steely_glint]
Youenn: Media session API is not sufficient, but may be a good starting point.
17:11:15 [steely_glint]
Jan-Ivar: NextTrack != NextSlide
17:11:39 [steely_glint]
Jan-Ivar: Better off with separate APIs
17:12:35 [steely_glint]
Jan-Ivar: Simple NextSlide PrevSlide is enough to start with.
17:14:17 [steely_glint]
Harald: This is a more Generic interface - could Media session API be implemented in terms of the user defined actions in this proposal?
17:14:49 [steely_glint]
Elad: Small set of predefined actions need limited collaboration.
17:15:24 [steely_glint]
Elad: userdefined actions require deeper collaboration.
17:17:58 [steely_glint]
Dom: Agree with Harald. Trade off between Generic all purpose API and solving this requirement.
17:18:31 [steely_glint]
Jan-Ivar: No arbitrary Strings please.
17:19:32 [steely_glint]
Elad: Do we agree we need both of these proposals ?
17:20:17 [steely_glint]
Youenn: Both perhaps Different priorities.
17:20:32 [steely_glint]
[Slide 43]
17:22:30 [steely_glint]
Elad: without identification you can't do two way communications
17:24:02 [steely_glint]
Elad: in terms of priorities the identification allows us to do everything so we should do it first.
17:25:11 [steely_glint]
Jan-Ivar: Next-Prev is more friendly for new market entrants
17:25:36 [steely_glint]
Youenn: Next-Prev is easier to deliver.
17:27:25 [steely_glint]
Elad: We have had plenty of time to look at capture handle - it has been in an origin trial.
17:27:37 [steely_glint]
Elad: for 6 months
17:28:58 [steely_glint]
(somewhat lost the thread here)
17:29:07 [steely_glint]
- Anyone chime in ?
17:31:46 [steely_glint]
Harald: would like to decouple the issues so we can attach the concerns to the right parts.
17:32:43 [steely_glint]
Youenn: Identity is a problem (and with origin)
17:32:59 [steely_glint]
Elad: Would like to fast track the discussion
17:34:03 [steely_glint]
Dom: We want to solve the use case - Jan-Ivar wants the narrow use case to drive the process.
17:34:54 [steely_glint]
Dom: do we want to start an adoption process? Or do we want to specify some issues that need to resolve first?
17:36:09 [steely_glint]
Elad: In sprit of compromise we can start with adding Actions
17:36:38 [steely_glint]
Dom: can we start a call for adoption now?
17:37:57 [steely_glint]
Youenn: will work on some GitHub issues.
17:39:00 [steely_glint]
Dom: Call for adoption defines the scope of a document, not the precise content.
17:40:11 [dom]
-> https://github.com/w3c/mediacapture-screen-share/issues/166 Previous discussion in this space
17:42:09 [dom]
RESOLVED: We start a call for adoption of Capture Handle by the WG
17:43:00 [dom]
i/[slice 27]/Resolved: Start a CfC for FPWD of Media Capture Transform after audio bits are removed
17:43:06 [dom]
RRSAgent, draft minutes
17:43:06 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
17:43:17 [dom]
RRSAgent, make log public
17:43:33 [dom]
Meeting: WebRTC January 2022 meeting
17:43:40 [dom]
Chairs: Harald, Bernard, Jan-Ivar
17:43:43 [dom]
RRSAgent, make log public
17:43:45 [dom]
RRSAgent, draft minutes
17:43:45 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
17:44:08 [dom]
i/[slide 27]/Resolved: Start a CfC for FPWD of Media Capture Transform after audio bits are removed
17:44:10 [dom]
RRSAgent, draft minutes
17:44:10 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
17:45:20 [dom]
i/Harald: likewise/RESOLVED: update use case and start explainer in webrtc-extensions for changes needed to make WebRTC usable in decentralized P2P/
17:45:23 [dom]
RRSAgent, draft minutes
17:45:23 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
18:27:09 [Zakim]
Zakim has left #webrtc