Meeting minutes
proposals#68 XRCapture Moduler
<yonet> agendum: https://
alcooper: we discussed the capture module during tpac
… we continued discussion on the proposal
… most people seemed in favor but cabanier seemed opposed
… Nick-8thWall wanted to get media stream
Nick-8thWall: for us the goal is to uniform capabilities across multiple surfaces
… ie getusermedia where that makes sense
… uniformity makes sense
… so not create special and different things
… we current can't support recording this on webxr
… I want to see a mediastream type of approach
… so we can see the same thing across form factors
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
alcooper: I''m not opposed to that but I want to give authors to get their own type of experience
… the biggest concern from pulling up the native ui is that it might start recording instead of taking a picture
… 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
… which makes it a lot harder to make it seamless
… and it would no longer be a low friction entry point
bialpio: if we were to go with the system UI route, how would this work in android
… android can record what is happening on the screen
… and I though we were trying to avoid that
… the system UI would record everything
… my impression is that this proposal would only record what is happening in the WebXR session.
… Would we have to trim the video? Not sure about what would happen
alcooper: I would leave it up to the UA. My main issue is that it would allow you to switch the recording type
Nick-8thWall: I had a technical question and a set of comment
… regarding the intent that you hold a button and it starts recording
… this is exactly how media recording works.
… it's just a permission prompt that users understand
… this notion that granting permission is problematic not something we find
… I think trying to prohibit this at all cost should not be the goal
… do we have a media recording today?
… could you draw to the canvas concurrent to the framebuffer? and then get a mediastream from that?
… could we draw the camera feed to the canvas
… this would give us a fully functional pipeline
alcooper: yes, with raw camera access, you would have everything you need
… the hightened privacy/security issue is showing dom content
<bialpio> (Alex already mentioned DOM overlay so no need for me to q)
Nick-8thWall: what if it was just the canvas?
alcooper: there's another API but it requires site isolation
Nick-8thWall: today we're able to do that already
… it's playing in existing security frameworks
alcooper: what you're capturing, is not dom overlay
Nick-8thWall: so what if we don't record that?
… would that change the security story?
alcooper: we want to capture the DOM content
… getdisplaymedia is not on android
Nick-8thWall: true. it only records canvas
… that's the product that we want to bring to webxr
alcooper: with media stream, you're already there
… but to capture the dom content, you need a special new API
… we want to create a privacy preserving API
Nick-8thWall: is this a feasible thing to draw to a canvas and capturing that as a media stream source?
cabanier: that would be hard to achieve at acceptable performance level in the browser
alcooper: to assure Nick-8thWall , I'm not opposed to the getdisplaymedia API
… I want a low friction API that just works for the user
Nick-8thWall: from our point of view, our desire is for things to be uniform between webxr and non-webxr session
… we want to things to function the same way in webxr and non-webxr
alcooper: I had considered that originally
… nobody was asking for a broader perspective
… there was no clear path to have this for non-xr session
bialpio: I'd like to point out that immersive sessions might run on a different screen
… on android we're kinda a tab but that is not the case everywhere
Add support for space warp
<yonet> agendum: https://
cabanier: Oculus announced new type of projection layer running at half framerate
… this is part of OpenXR as well, even if Oculus is currently the only implementer
… In addition to a color/depth buffer you also supply a motion detector to supply pixel speed, which allows inventing frames on the fly
… 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
… any objections to adding to layers spec? PR is currently out
<Nick-8thWall> https://