04:57:39 RRSAgent has joined #webscreens 04:57:39 logging to https://www.w3.org/2020/10/20-webscreens-irc 04:57:43 Zakim has joined #webscreens 04:57:56 anssik has joined #webscreens 04:58:00 amandy has joined #webscreens 04:59:18 msw_ has joined #webscreens 05:00:54 Meeting: Second Screen F2F - Day 1/2 05:01:52 eric_carlson has joined #webscreens 05:01:58 Agenda: https://github.com/w3c/secondscreen-wg/issues/1 05:01:58 Present+ Anssi_Kostiainen 05:02:04 present+ Chris_Needham 05:02:07 present+ Francois_Daoust 05:02:15 present+ Mike_Wasserman 05:02:16 takumi_fujimoto has joined #webscreens 05:02:23 Chair: Anssi 05:02:25 scribe: tidoust 05:02:25 present+ eric_carlson 05:02:35 darktears has joined #webscreens 05:03:53 mfoltzgoogle has joined #webscreens 05:04:47 Hello anssik, I'm having some trouble with Zoom. It says "Invalid Passcode" 05:05:42 present+ Takumi_Fujimoto 05:05:48 not getting access to zoom for some reason... get stuck on a black screen 05:06:54 present+ Mark_Foltz 05:06:59 I used this Chrome extension: https://chrome.google.com/webstore/detail/zoom/hmbjbjdpkobdjplfobhljndfdfdipjhg?utm_source=chrome-app-launcher-info-dialog 05:07:01 I'm in, the passcode is sswg 05:07:16 present+ Alexis_Menard 05:08:44 present+ Kenneth_Christiansen 05:09:02 present+ Wooglae_Kim 05:09:10 present+ Victor_Costan 05:10:31 present+ Alexandre_Gouaillard 05:10:43 Topic: Agenda bashing 05:11:16 mfoltzgoogle: We may not need a lot of time on Open Screen Protocol. Not a lot of new technical proposals to go through. 05:11:40 ... Most open issues have resolutions from Fukuoka. 05:12:14 s/Topic: Agenda bashing/Topic: Open Screen Protocol 05:12:56 present+ Arno_Mandy 05:13:26 subtopic: Track CFRG PAKE competition outcome #242 05:13:37 -> https://github.com/w3c/openscreenprotocol/issues/242 Issue #242 05:13:40 kimwooglae has joined #webscreens 05:14:15 kimwooglae_ has joined #webscreens 05:14:24 mfoltzgoogle: We need to track a pairing code. Looking at better security for authentication. At the time we drafte the spec, the best candidate for this was PAKE2, which is being used in some Google products 05:14:55 ... At the same time, the IETF cryptographic group have been working on recommendations for which PAKE to use. 05:15:20 ... They wrapped up this work some time ago, and recommended something different. Two protocols: CPACE and OPAQUE. 05:15:43 ... The first one is balanced: two sides share a secret and communicate symmetrically. The second one is for client/server use. 05:15:57 ... My assumption is that the balanced PAKE is more appropriate for our use case. 05:15:58 dlibby_ has joined #webscreens 05:16:17 ... It seems to be relatively new, no IETF RFC for now, but it is being shaped. 05:16:26 ... I wanted to update the group on this. 05:16:49 ... We need to take a deeper dive on the internals of the protocol and report to the group. 05:17:04 ... We may want to support two PAKEs. 05:17:13 anssik: Is it too early to take a recommendation? 05:17:23 s/recommendation/resolution 05:19:49 mfoltzgoogle: Any feedback is welcome. The next time we have an opportunity to meet, we should probably come up with a proposal. 05:20:20 q? 05:20:26 cpn: My colleague Nigel was interested in this aspect. We'll look into it and see if we have any thoughts. 05:20:42 Geunhyung_Kim has joined #webscreens 05:21:11 Subtopic: Add a back pressure signal for media remoting #241 05:21:21 -> https://github.com/w3c/openscreenprotocol/issues/241 Issue #241 05:23:04 mfoltzgoogle: During last TPAC, we spent some point discussing cases where one endpoint would use streaming, e.g. through MSE on the controlling side. We wondered about ways to signal back pressure from the receiver to the remote playback sender. 05:23:32 ... Not sure we want to do that yet, but it makes sense to provide a signal in the protocol. 05:23:51 ... The resolved action item was a little vague. There are a few ways we could add a back pressure signal. 05:24:02 ... I took a stab at a pull request 05:24:44 -> https://github.com/w3c/openscreenprotocol/pull/248 PR #248 05:25:59 mfoltzgoogle: Summary: whenever the receiver gets back to the controller, it can add one of 3 statuses: enough-data, insufficient-data, too-much-data, which the sender can use to adjust the rate of the data it sends. 05:26:10 ... This probably deserves a little bit of discussion. 05:26:41 present+ Kazuhiro_Hoya 05:27:23 present+ Geun-Hyung_Kim 05:27:47 mfoltzgoogle: Please have a look at the PR and provide feedback. 05:28:49 ... The point that was brought up in Fukuoka is that without signal brought back to the sender, the network congestion path from the network to the sender is typically different than the one between the sender and the receiver. 05:29:22 ... There may be differences of memory, e.g. sender with GB of memory whereas an HDMI dongle may have only 128MB 05:29:50 ... The goal with that protocol is to enable senders and receivers to negotiate the rate of data transfer. 05:30:10 ... That may impact the JS API as well if that requires cooperation from the application 05:30:43 cpn: Are these states enough or do you need some buffer size indication? Would numeric measure be useful? 05:31:30 mfoltzgoogle: It could. I'll have to think a bit more. I know that our implementation has a pacing algorithm, and knowing the buffer size could indeed help. 05:32:00 ... Part of the motivation for the state was the way that it could be exposed to scripts. 05:32:17 ... That would provide some insight as to how sites could use it. 05:32:35 ... Folks used to MSE might be able to provide feedback on whether that's useful or not. 05:32:57 anssik: Action on the group: review the PR and provide feedback 05:33:14 subtopic: Codec switching when remoting 05:33:18 mounir has joined #webscreens 05:33:24 -> https://github.com/w3c/openscreenprotocol/issues/223 Issue #223 05:34:00 mfoltzgoogle: This topic generated some discussion in Fukuoka. I wanted to test the group's temperature on whether that is a priority. 05:34:51 ... When we're implementing remoting, the media element can switch to another source at any time. There could be implementations that might want to transcode to another codec. 05:35:21 ... We discussed this in some length in Fukuoka. We could add additional messages to OSP to enable codec switching. 05:35:50 ... If we wanted to expose this to JS, we'll need to sping off the discussion to the Remote Playback API. 05:35:53 present+ Mounir_Lamouri 05:36:26 ... If we wanted to take on the script work, I would want to wait until that discussion progresses. 05:36:45 mfoltzgoogle: It can roughly be framed as Media capabilities for remote playback. 05:36:58 anssik: Feedback from Media WG participants? 05:37:37 ... Relationship with Media Capabilities? Dependency on this API or something different? 05:38:11 mfoltzgoogle: I don't think so. I don't think that the discussion in Fukuoka was sufficiently concrete to go to that level of details. 05:39:13 ... Idea is to provide feedback so that the implementation could decide what sources can be remoted. 05:39:57 mounir: I don't have a lot of context here. I'm aware of this issue from TPAC last year. 05:40:47 eric_carlson: It sounds to me that something like #2 will be required. I don't know whether this will work with Media Capabilities. Somebody needs to do a bit of research. 05:41:39 anssik: I'm hearing that #2 needs research. Is the Media WG aware of that issue? Or is this just our internal thinking at this point? 05:42:14 mfoltzgoogle: I think it depends on whether it is a high priority. 05:43:50 eric_carlson: After taking a quick look at the capabilities spec, I'm confident that it would work as-is. Not certain, but seems fine. Again, somebody needs to do a little bit of research. I don't think it would take much. 05:44:13 mounir: The Media Capabilities API could work for something like this. It's an async API. 05:44:38 ... I'm feeling that the Remote Playback API may need to expose that somehow. 05:44:55 ... We don't expose any device on the Remote Playback API, so I don't know where to expose the info. 05:45:45 anssik: My summary is that someone who understands the issue needs to look at the Media Capabilities spec should look into this. 05:46:37 ... Let's add "needs research" on the issue for #2. 05:47:13 mfoltzgoogle: If there are folks interested in exploring exposing this to scripts, that would be good. 05:47:57 subtopic: Capabilities for HDR rendering and display #194 05:48:03 -> https://github.com/w3c/openscreenprotocol/issues/194 Issue #194 05:49:05 mfoltzgoogle: We want to allow an endpoint that receives media to signal its capabilities to render and display HDR media. 05:49:23 ... We decided for the work on HDR media capabilities in the Media WG to conclude. 05:50:02 ... I propose to align OSP with Media Capabilities issue #118, and maybe wait on #119 if it's still being discussed. 05:51:45 ... There's an open PR for #119 from Vi. 05:52:20 mounir: I thought we were done with this. I believe Vi is no longer on this either. I'll check with Chris. 05:52:50 mfoltzgoogle: It seems #119 is really on display capabilities as opposed to media capabilities. Adding attributes to the screen object. 05:53:12 mounir: OK, got it, then the discussion is still ongoing. Talked about that with the CSS WG. 05:53:35 ... A few competing proposals. I would recommend to wait unless you're in a hurry. 05:54:13 mfoltzgoogle: I'll propose a PR to align OSP with #118 in the meantime. 05:54:40 pwnall has joined #webscreens 05:55:19 present+ Daniel_Libby 05:55:33 subtopic: Refinements to Remote Playback protocol #159 05:55:43 -> https://github.com/w3c/openscreenprotocol/issues/159 Issue #159 05:55:57 mfoltzgoogle: Not worth the group's time. A bunch of todos. 05:56:10 subtopic: Publication as FPWD 05:56:24 anssik: The spec is in good shape. Any objection to publish the spec as FPWD? 05:56:31 mfoltzgoogle: What does that entail? 05:56:49 anssik: It entails that the scope is roughly known 05:57:03 scribenick: cpn 05:57:23 tidoust: FPWD triggers a call for patent exclusions, so you may want to do that as soon as possible 05:57:41 scribe: tidoust 05:57:52 mfoltzgoogle: OK, no objection to that. 05:58:12 ... We may want to do an editorial pass on the spec before publication 05:59:12 PROPOSED RESOLUTION: publish the Open Screen Protocol as First Public Working Draft 05:59:18 [no objections] 05:59:20 RESOLUTION: publish the Open Screen Protocol as First Public Working Draft 05:59:32 [coffee break] 05:59:44 RRSAgent, draft minutes v 05:59:44 I'm logging. I don't understand 'draft minutes v', tidoust. Try /msg RRSAgent help 05:59:45 RRSAgent, draft minutes v2 05:59:45 I have made the request to generate https://www.w3.org/2020/10/20-webscreens-minutes.html tidoust 06:10:47 scribenick: cpn 06:11:32 Topic: Presentation API 06:11:40 Topic: Tab Self Mirroring API 06:12:13 rrsagent, make logs public 06:12:42 Mark: Recently, Chrome launched a feature whereby you could cast the content of a Google meeting to a Chromecast device 06:12:56 ... We implemented this by allowing the site to ask the browser to mirror its own tab 06:13:03 s/Topic: Tab Self Mirroring API/subtopic: Tab Self Mirroring API/ 06:13:31 ... We did this for a number of reasons. It would have been difficult for the video conferencing app to run natively on the cast device, so mirroring was a good solution for sharing on a larger display 06:13:53 ... We've had the capability in Google Slides for a while. This was done in the cast SDK using non-public APIs 06:14:12 ... With these use cases, it would be a good time to explore what a proper API would look like 06:14:24 ... It's early stage, not decided on API shape, but we have a good idea on requirements 06:14:58 ... In the last few years, Chrome has shipped tabs as a source for getDisplayMedia, so there's a precedent for sites to be able to request sharing tabs with another device or application 06:15:22 ... The main difference between this and tab mirroring is that the site wants to customize it in a couple of ways 06:15:22 i|Mark: Recently|-> https://mfoltzgoogle.github.io/tab-self-mirroring/explainer.html Self-mirroring explainer 06:15:45 ... Chrome can control the latency, and for meetings we wanted a low latency experience for better A/V sync 06:16:27 ... Also, if the user is not participating in the conference, so just watching, we want the ability to just route the audio to the target display. So we don't have to worry about echo cancellation in that case. 06:16:44 dlibby_ has joined #webscreens 06:16:47 ... This covers the use cases and requirements we want to achieve. 06:17:20 ... The user would see a cast button in the page, a list of device that can accept the mirrored content. The page doesn't change, it's just mirrored to the TV as well as being shown locally 06:18:11 ... It builds on the Presentation API, with a special URL to indicate that the site requests to present its own tab. A couple of properties on the connection object can be used to adjust the mirroring - for audio, and latency customization 06:18:29 ... Any questions? 06:19:00 Anssi: In the non-goals, you say mirroring to wired displays. 06:19:54 Mark: It's tricky to find an API that would support both. For video conferencing, you don't have the same constraints around latecy and A/V sync 06:20:21 ... If there's a strong use case, it could be addressed by other work in the group. It could be extended to wired displays as well. 06:20:41 q+ 06:21:08 Anssi: People may not have had time to look at this in detail yet. If there's support in the group, are you interested in integrating into the Presentation API? 06:21:49 Mark: We'll seek developer feedback, then use that to decide whether to add to the Presentation API. There's another proposal from Takumi that makes it more like Remote Playback. 06:22:23 ... This could make sense, as the Presentation API is designed for a second device with a connection to it. We need to think about the right API surface for this, taking into account the use cases. 06:23:08 Eric: Any views on the API surface? 06:23:22 s/Eric/Anssi/ 06:23:51 Eric: I haven't thought about this yet. There's an issue against MediaCapture screen share #148, proposing a new API to create a media stream from the current tab. 06:24:12 ... Some interesting discussion, in mailing list and in GitHub on the privacy issues 06:24:32 perhaps https://github.com/w3c/mediacapture-screen-share/issues/149 06:24:36 q? 06:24:39 ack mounir 06:25:01 s/#148/#149 06:25:48 Mounir: About MediaCapture, would the four goals be met by screen capture? Is there an approach where we could compose an API, something between screen capture and Presentation API? 06:26:05 https://github.com/w3c/mediacapture-screen-share/pull/148 06:26:31 Mark: If some of the dynamic settings could be exposed via screen capture, and find a way to compose with Remote Playback or Presentation API to handle device permissions, could be a good way to think about this 06:27:05 Anssi: Please take a look at the explainer. How to give feedback? 06:27:17 Mark: It's in GitHub, so please raise issues, or email me directly 06:27:56 Anssi: Before we adopt this, we need to ensure it's in WG scope. We could open a tracking issue in the Presentation API repo? 06:28:08 Mark: When the time's right, we can figure out how to bring it into the group 06:28:15 q? 06:28:59 Topic: Same screen presentation, issue #476, PR #479 06:29:24 s/Topic: Same screen presentation/Subtopic: Same screen presentation 06:29:30 dlibby: The Powerpoint team has been looking to use the Presentation API. 06:29:44 -> https://github.com/w3c/presentation-api/issues/476 Issue #476 06:29:45 ... For a single screen device they want to enter a slideshow view, for parity with the native app 06:30:05 ... They want some ergonomic improvements, alongside remote presentation, with same API and events etc 06:30:33 ... Looking at the spec, nothing specifically disallowed it. Want group feedback, could modify Presentation API to support this? 06:31:39 Mark: If the Presentation API supports this, and the user chooses their own screen from the list, what behaviour would you want? 06:32:06 dlibby: A full screen secondary window with the requested content, and the user could alt-tab back to the original page. 06:32:42 ... Could window.open that propagates a permission token work? There's benefit to authors to have just one code path for this scenario 06:33:16 Mark: If the application can live in the current constraints of the Presentation API, it's compatible with the scope of the API. I wouldn't mandate browser to support but they could 06:33:44 ... For the PR, would we need to change the availability API to support this? I'm not convinced that's the case yet 06:34:42 dlibby: We wouldn't want to change the availability algorithm, since single screen is always available, running in a separate process to the request itself 06:35:10 Mark: If instead we allowed user activation to create a full screen window, would that also address the use case? 06:35:49 dlibby: From a user scenario point of view, you could build the necessary abstraction over those modes. This is an exploration of whether Presentation API is right way to go for these scenarios 06:36:07 Takio: Would this skip the selection dialog? 06:36:09 Louay_ has joined #webscreens 06:36:19 s/Takio/Takumi 06:36:20 Present+ Louay_Bassbouss 06:36:45 Mark: No, the way a site could create a fullscreen window requires two steps - one to open, then make full screen. The proposal is to do that with a single user gesture 06:37:02 dlibby: Not clear that's a change HTML would be willing to take 06:37:36 Mark: That could be difficult, as there's potential for abuse of fullscreen. We try to ensure users are aware when the go / have gone full screen 06:37:56 ... Making it easier for that to happen (e.g., clickjacking) could be hard to find the balance 06:38:30 ... I would like to hear about the window placement work, does that also address some of the use cases. Are you looking at wired and also wireless displays? 06:39:07 dlibby: The main use case is for wired displays. We're looking into implications of wireless 06:39:23 Anssi: We could look at this in the multi-screen placement discussion tomorrow 06:39:36 ... That spec might address this use case 06:40:01 ... We also need to pay attention to the privacy concerns. Can we learn from the fullscreen API in that regard? 06:41:07 Mike: I think there's merit in considering how the use case can be solved in the Presentation API, but also consider how to solve using multi-screen window placement 06:41:38 Subtopic: Requesting enhancements to the Presentation API, Issue #477 06:41:49 -> https://github.com/w3c/presentation-api/issues/477 Issue #477 06:42:41 Mark: The requester would like to ask the presentation be opened in a new window that shares the same browsing context as the controlling page, as their application has an authentication step to show the presenting page. 06:43:03 ... They want a new document, remote displays aren't a priority for their use case. 06:43:22 ... They also want persistent, so the site remembers their choice. 06:43:53 ... This could be done through the Presentation API, but if the focus is on creating new windows in the same browsing profile, I thought it could be in scope for window placement 06:44:19 Mike: It sounds like it's in scope of multi-screen window placement 06:44:48 Mark: Please add any feedback to the issue 06:44:54 Mike: Will do 06:45:19 q? 06:46:22 Subtopic: Publishing a Presentation API update 06:46:23 Mark: It's been some time since we published a formal update to the Presentation API. Is there a need to publish? We've merged some editorial PRs on the boilerplate 06:46:37 Anssi: Under Process 2020 we can more easily publish updated CRs 06:47:12 Francois: We're not automatically switched to Process 2020. There'll be call for review sent to the AC for a number of WGs. We'll move to P2020 soon, but not yet 06:47:28 ... Previous process doesn't stop us from publishing if we want to 06:47:52 ... It's slightly easier in P2020 06:48:12 Anssi: What are the substantial changes? 06:48:44 Mark: There were some changes to clarify the receiving browsing context. Also some algorithm fixes, mostly clarifications and not new features, I think. 06:49:02 ... So there have been some normative changes, but making the spec more precise. 06:50:08 PROPOSED RESOLUTION: Look into publishing a new CR for the Presentation API 06:50:30 RESOLUTION: Look into publishing a new CR for the Presentation API 06:52:06 Subtopic: Remote Playback State enum can be misleading when changing media source, Issue #125 06:52:39 i/Subtopic:/Topic: Remote Playback API 06:52:44 Mark: This is how we allow the browser and playback device to figure out what source to play when doing remote playback 06:52:55 ... It's more applicable in the flinging case, where you send a URL 06:53:22 ... Discussion to find a way for the playback device to signal to the page that the source is not compatible with remote playback 06:54:00 ... The conclusion was that no API changes were needed, but the page should list all compatible sources and leave it to the protocol to do source selection 06:54:12 ... From a protocol point of view, it's compatible with what we have today 06:54:29 ... The sender can send multiple URLs with metadata, e.g., extended mime type 06:55:11 ... From the spec point of view, it requires a PR to clarify that the sender should send all the sources to the playback device, and that either device could do source selection 06:55:25 ... I created a PR, please review 06:55:27 https://github.com/w3c/remote-playback/pull/141 06:56:01 https://pr-preview.s3.amazonaws.com/w3c/remote-playback/141/b0ecc12...2543a1e.html 06:56:38 Anssi: There's one normative change. 06:56:46 Eric: I'll ask Jer for feedback on this 06:57:17 q? 06:57:24 Anssi: We'll wait for review feedback before landing this. Any other views? 06:58:01 Subtopic: Remote playback API test automation, Issue 92 06:58:37 Anssi: If Honry isn't able to work on this at the moment, how to move it forward? 06:59:09 ... It would block advancing to PR, we need to demonstrate implementability, and test automation is important for that 06:59:20 Mark: Is this web driver API part of the spec? 07:00:00 Anssi: I believe the plan is it should be part of the spec. Some W3C specs put it into the spec proper, e.g., Generic Sensor API 07:00:44 Mounir: For WebXR we have a test API where the intent is to simulate a device. Could be interesting to look at. https://immersive-web.github.io/webxr-test-api/ 07:01:15 DrAlex: In the new WebRTC spec we have a mock capture device that doesn't touch WebDriver at all 07:01:47 Mounir: The WebXR test API is exposed when running WPT 07:02:07 Anssi: Are there similar test APIs for other APIs, or is this the first? 07:02:20 https://w3c.github.io/sensors/#automation 07:02:22 Mounir: Possible things like WebUSB have similar 07:02:54 Anssi: The Generic Sensor API defines mock interfaces 07:03:11 Mounir: Here's the info on Web USB: https://wicg.github.io/webusb/test/ 07:03:47 Louay: I shared yesterday a presentation at the MEIG about extending WPT test runner for embedded devices. It's in the Web Media API CG 07:04:18 ... The extension is now available in the official WPT project. It may help in this case, the aim is to run on embedded devices, we run on Chromecast for example 07:04:28 ... I can share the documentation and links to review 07:04:52 ... There's a new command for starting the test runner to target embedded devices where there's no WebDriver support 07:05:25 Anssi: Thank you. Do you still have a student project ongoing, could this be an option for us? 07:06:05 Louay: I can check if that's possible, for the next semester. Could consider in collaboration with the Web Media API group 07:06:15 https://github.com/w3c/remote-playback/issues/92 07:06:24 Anssi: Please add some info to issue #92 07:07:08 ... We need volunteers to help with test automation 07:07:49 https://github.com/w3c/remote-playback/issues/130 07:07:51 Subtopic: Publish Remote Playback API PR 07:08:05 Anssi: There's a list of things to do to get to PR in #130 07:08:33 ... One is test automation, then issue #125 - we could land that PR soon 07:09:01 ... We decided to publish PR, but we need to clear the blocking issues 07:09:17 Mark: Is the blocker to define the test API, or is it having two implementations? 07:09:42 Anssi: We don't need the test suite if we can demonstrate two independent implementations. It could be manually tested 07:10:01 ... We just need the evidence, but it doesn't need to be automated 07:10:32 Mark: Is it the automation, or having the API that enables automation, that's important? 07:11:15 Francois: There's nothing that requires the group to automate the tests. We can make do with a manual test suite, and don't add test API surface to the spec 07:11:19 Device Platform Tests / Web Platform Tests Slides: https://www.w3.org/2011/webtv/wiki/TPAC_2020_meeting#Device_Platform_Tests_.2F_Web_Platform_Tests_.2820_minutes.29 07:12:02 Anssi: Do we have volunteers to work on test implementation? If not, move forward with manual testing 07:13:40 PROPOSED RESOLUTION: Figure out if we want to move forward with test automation or manual testing 07:14:23 PROPOSED RESOLUTION: To unblock PR publication, figure out if we want to move forward with test automation or manual testing 07:15:58 Action: Louay to figure out if we want to move forward with test automation or manual testing, to unblock PR publication 07:16:37 Anssi: Please update issue #92, when you know more 07:16:58 Subtopic: AOB for today? 07:18:56 (none) 07:19:14 Anssi: Thank you everyone for joining. We're back at the same time tomorrow 07:20:53 rrsagent, draft minutes v2 07:20:53 I have made the request to generate https://www.w3.org/2020/10/20-webscreens-minutes.html cpn 07:21:10 RRSAgent, draft minutes v2 07:21:10 I have made the request to generate https://www.w3.org/2020/10/20-webscreens-minutes.html anssik 09:28:44 Zakim has left #webscreens