20:03:10 <RRSAgent> RRSAgent has joined #immersive-web
20:03:10 <RRSAgent> logging to https://www.w3.org/2021/11/16-immersive-web-irc
20:03:18 <cwilso> present+
20:04:04 <yonet> agenda: https://github.com/immersive-web/administrivia/blob/main/meetings/wg/2021-11-16-Immersive_Web_Working_Group_Teleconference-agenda.md
20:04:57 <cabanier> present+
20:05:58 <cabanier> scribenick: cabanier
20:06:05 <bialpio> bialpio has joined #immersive-web
20:06:06 <yonet> scribe: cabanier
20:06:20 <cabanier> topic: proposals#68 XRCapture Moduler
20:06:24 <laford> laford has joined #immersive-web
20:06:25 <yonet> agendum: https://github.com/immersive-web/proposals/issues/68
20:06:36 <cabanier> alcooper: we discussed the capture module during tpac
20:06:48 <Nick-8thWall> Nick-8thWall has joined #immersive-web
20:06:48 <cabanier> ... we continued discussion on the proposal
20:07:03 <cabanier> ... most people seemed in favor but cabanier seemed opposed
20:07:36 <cabanier> ... Nick-8thWall wanted to get media stream
20:07:39 <Nick-8thWall> q+
20:07:45 <cabanier> q+
20:07:57 <yonet> ack Nick-8thWall
20:08:20 <cabanier> Nick-8thWall: for us the goal is to uniform capabilities across multiple surfaces
20:08:30 <cabanier> ... ie getusermedia where that makes sense
20:08:39 <cabanier> ... uniformity makes sense
20:08:48 <cabanier> ... so not create special and different things
20:09:02 <cabanier> ... we current can't support recording this on webxr
20:09:08 <alcooper> q+
20:09:15 <cabanier> ... I want to see a mediastream type of approach
20:09:28 <cabanier> ... so we can see the same thing across form factors
20:09:31 <yonet> ack cabanier
20:10:23 <bialpio> q+
20:10:53 <Nick-8thWall> q+
20:11:08 <yonet> ack alcooper
20:11:09 <cabanier> cabanier: I don't have objection to the API jsut want to make sure that there's an option to use the system UI for platforms that support it
20:11:36 <cabanier> alcooper: I''m not opposed to that but I want to give authors to get their own type of experience
20:12:06 <cabanier> ... the biggest concern from pulling up the native ui is that it might start recording instead of taking a picture
20:13:15 <cabanier> ... as for Nick-8thWall 's point, I've been looking at this for quite a while now and every time I look at implementing stream, there's such a high bar that we have to meet wrt security and privacy, it requires a lot of interaction from the user
20:13:36 <cabanier> ... which makes it a lot harder to make it seamless
20:14:05 <cabanier> ... and it would no longer be a low friction entry point
20:14:14 <yonet> ack bialpio
20:14:22 <cabanier> bialpio: if we were to go with the system UI route, how would this work in android
20:14:36 <cabanier> ... android can record what is happening on the screen
20:14:46 <cabanier> ... and I though we were trying to avoid that
20:15:01 <cabanier> ... the system UI would record everything
20:15:39 <cabanier> ... my impression is that this proposal would only record what is happening in the WebXR session.
20:15:56 <cabanier> ... Would we have to trim the video? Not sure about what would happen
20:16:20 <yonet> ack Nick-8thWall
20:16:24 <cabanier> alcooper: I would leave it up to the UA. My main issue is that it would allow you to switch the recording type
20:16:38 <cabanier> Nick-8thWall: I had a technical question and a set of comment
20:16:57 <cabanier> ... regarding the intent that you hold a button and it starts recording
20:17:11 <cabanier> ... this is exactly how media recording works.
20:17:34 <cabanier> ... it's just a permission prompt that users understand
20:17:58 <cabanier> ... this notion that granting permission is problematic not something we find
20:18:19 <cabanier> ... I think trying to prohibit this at all cost should not be the goal
20:18:31 <cabanier> ... do we have a media recording today?
20:18:58 <cabanier> ... could you draw to the canvas concurrent to the framebuffer? and then get a mediastream from that?
20:19:09 <bialpio> q+
20:19:17 <cabanier> ... could we draw the camera feed to the canvas
20:19:34 <cabanier> ... this would give us a fully functional pipeline
20:19:56 <cabanier> alcooper: yes, with raw camera access, you would have everything you need
20:20:07 <bialpio> q-
20:20:18 <cabanier> ... the hightened privacy/security issue is showing dom content
20:20:33 <bialpio> (Alex already mentioned DOM overlay so no need for me to q)
20:20:35 <cabanier> Nick-8thWall: what if it was just the canvas?
20:20:56 <cabanier> alcooper: there's another API but it requires site isolation
20:21:05 <cabanier> Nick-8thWall: today we're able to do that already
20:21:23 <cabanier> ... it's playing in existing security frameworks
20:21:37 <cabanier> alcooper: what you're capturing, is not dom overlay
20:21:46 <cabanier> Nick-8thWall: so what if we don't record that?
20:22:01 <cabanier> ... would that change the security story?
20:22:09 <cabanier> alcooper: we want to capture the DOM content
20:22:26 <cabanier> ... getdisplaymedia is not on android
20:22:39 <cabanier> Nick-8thWall: true. it only records canvas
20:22:49 <cabanier> ... that's the product that we want to bring to webxr
20:23:01 <cabanier> alcooper: with media stream, you're already there
20:23:14 <cabanier> ... but to capture the dom content, you need a special new API
20:23:29 <cabanier> ... we want to create a privacy preserving API
20:23:53 <cabanier> Nick-8thWall: is this a feasible thing to draw to a canvas and capturing that as a media stream source?
20:24:59 <cabanier> cabanier: that would be hard to achieve at acceptable performance level in the browser
20:25:48 <cabanier> alcooper: to assure Nick-8thWall , I'm not opposed to the  getdisplaymedia API
20:26:04 <cabanier> ... I want a low friction API that just works for the user
20:26:41 <cabanier> Nick-8thWall: from our point of view, our desire is for things to be uniform between webxr and non-webxr session
20:27:15 <cabanier> ... we want to things to function the same way in webxr and non-webxr
20:27:27 <cabanier> alcooper: I had considered that originally
20:27:37 <bialpio> q+
20:27:41 <cabanier> ... nobody was asking for a broader perspective
20:27:57 <cabanier> ... there was no clear path to have this for non-xr session
20:28:17 <yonet> ack bialpio
20:29:07 <cabanier> bialpio: I'd like to point out that immersive sessions might run on a different screen
20:29:29 <cabanier> ... on android we're kinda a tab but that is not the case everywhere
20:30:19 <yonet> agendum: https://github.com/immersive-web/layers/issues/272
20:30:50 <alcooper> scribenick:alcooper
20:31:07 <alcooper> cabanier: Oculus announced new type of projection layer running at half framerate
20:31:19 <alcooper> ... this is part of OpenXR as well, even if Oculus is currently the only implementer
20:31:48 <alcooper> ... In addition to a color/depth buffer you also supply a motion detector to supply pixel speed, which allows inventing frames on the fly
20:32:10 <alcooper> ... only works for a couple of frames, but enough to allow you to skip frames, can allow for improvement in webxr content on mobile headsets which are more constrained
20:32:40 <alcooper> ... any objections to adding to layers spec? PR is currently out
20:34:42 <yonet> https://www.8thwall.com/blog/post/59297774102/introducing-reality-engine-8th-wall-webar-moves-beyond-the-smartphone
21:00:48 <laford> q+
21:08:25 <yonet> RRSAgent, make minutes
21:08:25 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/16-immersive-web-minutes.html yonet
21:08:44 <yonet> RRSagent, make log public
21:10:43 <Nick-8thWall> https://drive.google.com/file/d/1C2KmukHl3Plk4SQ6fYBUG7naQq-Be7hP/view?usp=sharing
23:59:59 <scribe> i|agendum: https://github.com/immersive-web/layers/issues/272|topic: Add support for space warp|
23:59:59 <scribe> meeting: Immersive Web WG call
23:59:59 <scribe> previous meeting: https://www.w3.org/2021/11/02-immersive-web-minutes.html