07:41:06 RRSAgent has joined #webscreens 07:41:06 logging to http://www.w3.org/2016/09/22-webscreens-irc 07:41:12 RRSAgent, make logs public 07:41:32 Meeting: Second Screen WG F2F - Day 1/2 07:41:35 Chair: Anssi 07:42:16 Agenda: https://www.w3.org/wiki/Second_Screen/Meetings/Sep_2016_F2F#Agenda 07:43:16 Present+ Anton_Vayvod(Google), Mark_Foltz(Google), Anssi_Kostiainen(Intel), Shih-Chiang_Chien(Mozilla), Mounir_Lamouri(Google) 07:44:39 Present+ Eric_Carlson(Apple), Mark_Watson(Netflix), Louay_Bassbouss(Fraunhofer), Francois_Daoust(W3C), Hyojin_Song(LGE) 07:47:27 Present+ Kenneth_Christiansen(Intel), Hiroki_Endo(NHK), Ingar_Arntzen(MotionCorporation) 07:53:25 Present+ Tomoyuki_Shimizu(KDDI) 07:53:35 Present+ Chris_Needham(BBC) 07:53:44 RRSAgent, draft minutes 07:53:44 I have made the request to generate http://www.w3.org/2016/09/22-webscreens-minutes.html tidoust 07:55:18 mfoltzgoogle has joined #webscreens 07:55:35 ericc has joined #webscreens 07:55:36 Tomoyuki has joined #webscreens 07:56:32 RRSAgent, draft minutes 07:56:32 I have made the request to generate http://www.w3.org/2016/09/22-webscreens-minutes.html tidoust 07:56:37 antonvayvodgoogle has joined #webscreens 07:56:39 cpn has joined #webscreens 07:57:23 Hiroki has joined #webscreens 07:58:19 wonsuk has joined #webscreens 07:58:41 scribe: Francois 07:58:44 scribenick: tidoust 08:01:07 Anssi: Welcome to the Second Screen WG 2016 TPAC F2F meeting! 08:01:19 Hiroki__ has joined #webscreens 08:02:09 ... [agenda review] 08:03:00 ... v1 issues for the Presentation API are the ones we want to fix right away to move the Presentation API to REC. v2 issues would be for a possible second version of the specification. 08:03:13 https://www.w3.org/standards/history/presentation-api 08:03:42 ... The Presentation API spec got published as a Candidate Recommendation in July 2016. 08:04:45 mfoltzgoogle_ has joined #webscreens 08:05:03 ... We'll shuffle the agenda a bit to discuss everything related to v1 first, then talk about v2. 08:05:13 kenneth_ has joined #webscreens 08:05:26 present+ Kenneth_Christiansen 08:06:04 ... We may also compact the agenda a bit to spend more time on CG discussions around protocols. 08:08:09 takeshi has joined #webscreens 08:08:46 Present+ Kasar_Masood(Viacom) 08:08:52 [quick round of introductions] 08:10:10 present+ Mark_Foltz(Google) 08:13:00 Topic: Presentation API issues 08:13:15 https://github.com/w3c/presentation-api/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20-label%3Av1%20-label%3Av2%20 08:13:16 Francois: Note some recent issues are not labeled as v1 or v2. 08:13:24 Anssi: Let's go through them 08:14:04 -> https://github.com/w3c/presentation-api/issues/346 Clarify presentation ID generation requirements 08:15:12 Mark: We "recommend" to use UUID, We'd better use "SHOULD" to clarify that this is a normative statement. 08:16:43 Francois: Why is that not a MUST? Do we anticipate good reasons to create other types of UUID? 08:17:37 Mark: I think it can be a MUST. I think I can take an action to research what other specs are doing. 08:18:55 Shih-Chiang: Just checked MediaStreams spec, they use SHOULD. 08:19:30 ACTION: @mfoltzgoogle to check how other specs reference UUID generation and adjust the spec accordingly with SHOULD or MUST. 08:20:04 -> https://github.com/w3c/presentation-api/issues/345 Introduction could use some copy editing 08:20:21 Mark: Purely editorial. 08:21:01 -> https://github.com/w3c/presentation-api/issues/344 Spec for PresentationConnectionCloseEvent conflicts with note 08:23:23 Mark: The examples in the note do not include the reason why the error occurred, whereas we recommend that. 08:23:29 ... We should update the examples in the note. 08:24:07 -> https://github.com/w3c/presentation-api/issues/343 Establishing a presentation connection steps do not handle failures 08:27:02 Mark: I'm suggesting moving the error handling part from the start connection algorithm into the establish a connection algorithm so that the reconnect algorithm also benefits from it. 08:27:56 ... Also, the note in 6.5.1 is not explicit about which steps can be automatically retried. 08:28:27 Anssi: Are there cases where implementations may not want to retry? 08:28:31 Mark: That's a good question 08:29:05 ... It depends on whether we want the developer to be fully responsible for error handling. 08:30:03 Anssi: I think good general principle is that the developer should always expect things to fail. Do we have implementation feedback? 08:30:59 kasar has joined #webscreens 08:31:26 Mark: I don't think the connection will ever go from an error state to a connected state without the developer having to do something about it. 08:31:41 Anssi: OK, so that's per spec. The note is more an implementation guideline. 08:32:56 ... My mental model says that it's more intuitive to expose the error right away to the developer. That would suggest dropping the note. 08:33:12 Mark: I think I agree. I need to check whether that matches implementation. 08:33:34 Anssi: Similar to a discussion we had in the Device and Sensors WG around transient states. 08:34:29 ... Anyone has concerns with dropping the note? 08:35:20 RESOLUTION: For #343, remove the note in 6.5.1 about retrying connection establishment. 08:36:18 -> https://github.com/w3c/presentation-api/issues/342 Presentation display availability is not clearly defined 08:37:00 Mark: I wonder whether that's an idiom we need to define, or is it just a reference to the object that we need. 08:37:33 Anssi: I think that's just a way to have an English name. This seems like a style issue. I would leave it to the editor. 08:37:50 Mark: We may need some idiom to say exactly what this means. 08:39:53 Francois: Personally, I agree it would be better to have a proper definition. I don't think there's a clear guideline across Web specs on this. 08:40:25 Mark: I do want to check that there is some proper definition of what availability means. 08:41:27 -> https://github.com/w3c/presentation-api/issues/341 navigator.presentation is marked optional in WebIDL 08:43:25 Mark: I think that's an IDL bug, the presentation attribute cannot be null in practice. 08:45:34 RESOLUTION: For #342, make "navigator.presentation" attribute mandatory to align with the normative prose. 08:46:08 -> https://github.com/w3c/presentation-api/issues/340 Examples 5.6 does not need onconnect handler 08:47:02 Anssi: Editorial, needs fixing. 08:47:25 -> https://github.com/w3c/presentation-api/issues/339 setConnection in example 5.5 may put UI in an inconsistent state 08:50:41 ACTION: Kenneth to review and fix the example in 5.5 08:51:17 -> https://github.com/w3c/presentation-api/issues/337 PresentationConnectionList is not required for receiving user agents 08:51:45 Mark: The Conformance section lists mandatory interfaces, but PresentationConnectionList fell through the cracks. 08:52:40 RESOLUTION: For #337, add PresentationConnectionList to the list of interfaces to be supported by receiving user agents. 08:53:21 Anssi: Moving on to older v1 issues 08:53:46 -> https://github.com/w3c/presentation-api/issues/336 PresentationRequest constructor uses entry settings object 08:54:09 Anssi: Basically, things changed in HTML, and we should align. 08:56:17 [looking at another spec which fixed this, seems to use "incumbent object"] 08:56:18 https://github.com/whatwg/html/issues/1431 08:56:41 Anssi: We need to look at how other specs have been refactored and follow that practice. 08:57:35 Francois: We could add ourselves to the list of specs tracked to reduce the use of "entry settings object" and ping Domenic about that. 08:58:09 -> https://github.com/w3c/presentation-api/issues/335 define the behavior for consecutive calls to getAvailability 09:00:01 Shih-Chiang: The availability object will be created during the first call. Different unclear behavior. When are promises resolved when consecutive calls to getAvailability are issued? 09:00:15 Anssi: In the battery context, multiple calls will yield the same Promise. 09:01:33 https://w3c.github.io/battery/#dfn-battery-promise 09:01:36 Mounir: I think we should add a new step after step 6 to reuse an existing Promise if there's one. 09:01:44 Anssi: that would be a one-liner fix 09:04:27 Francois: About the first bullet, my understanding is that the problem is that different contexts cannot return the same JS object. 09:05:16 Mark: Yes, they would have to be different JS objects. I think we need to be clear about when we refer to script objects or internal objects. 09:07:52 ... I'll check our implementation but indeed, different calls to getAvailability from different contexts will return different script objects that are in the same internal state. 09:09:41 ... I think we should check when we say promise or availability object whether we refer to a script object or an internal state, and make that consistent throughout the spec. 09:10:51 ... The IDL has [SameObject], so enforces the fact that the same script object gets returned in a given browsing context. 09:12:20 ... Actually the [SameObject] attribute is not there, so we need to be explicit about that. 09:13:41 Francois: Also, note that for bullet 2, we're missing "in parallel" in step 9. 09:16:16 RESOLUTION: For #335, check algorithms around availability objects and make sure they all refer to "script object" or "internal object". For bullet 2, add "in parallel" in step 9. For bullet 3, make sure getAvailability returns the same Promise object. 09:17:25 -> https://github.com/w3c/presentation-api/issues/303 Define that "TV" should appear as token for UA-string 09:17:41 Anssi: Jonas is not around for the time being. 09:18:01 ... Do we have new information? 09:19:43 Mark: I'm fine either way, provided we understand what TV means. There seems to be a set of features, e.g. overscan, input, resolution, etc. 09:20:15 Kenneth: It's not recommended to do UA sniffing at well. 09:20:35 ... Reality is that people have to do sniffing from time to time. 09:21:33 Anton: In the receiving context, the "receiver" attribute will be set, so the application knows it is a presentation. 09:21:43 Francois: Right, that's what I raised in the GitHub issue as well. 09:22:03 Anssi: I see, so that seems functionally equivalent. 09:25:15 ... An app can do feature detection through that attribute and react based on this. Additional specific CSS media queries could be useful in the future. 09:27:04 RESOLUTION: For #303, add a note about feature detection through the "receiver" attribute, no guideline on the UA string. 09:31:57 -> https://github.com/w3c/presentation-api/issues/295 Check references category and stability 09:34:22 Francois: Basic rule is that a PR/REC cannot reference anything else than a PR or a REC. In practice, there are exceptions to the rule. We'll switch to HTML5.1, have a slight problem with NotAllowedError in WebIDL, mixed content and permissions, as well as a couple of specs references in the "Creating a receiving browsing context" algorithm, but we're only referencing high-level concepts there, no deep integration. 09:34:51 ... We just need to keep track of those, and ensure we highlight exceptions we need when we request transition to PR. 09:34:56 RRSAgent, draft minutes. 09:34:56 I'm logging. I don't understand 'draft minutes.', tidoust. Try /msg RRSAgent help 09:35:23 kumanan has joined #webscreens 09:45:26 wonsuk has joined #webscreens 10:04:02 Louay has joined #webscreens 10:04:03 kinjim has joined #webscreens 10:04:40 mfoltzgoogle has joined #webscreens 10:04:53 takeshi has joined #webscreens 10:05:28 ACTION: For #342, Mark to check that there is a proper definition of "availability." 10:08:18 ACTION: For #344, Mark to update close message examples to conform to spec. 10:09:02 RESOLUTION: For #336, examine how other specs have been updated to use the settings object and update our spec to match. 10:09:24 s/RESOLUTION/PROPOSED RESOLUTION/ 10:12:06 present+ Louay_Bassbouss 10:12:15 antonvayvodgoogle has joined #webscreens 10:12:51 RRSAgent, draft minutes 10:12:51 I have made the request to generate http://www.w3.org/2016/09/22-webscreens-minutes.html tidoust 10:13:37 Present+ Kumanan_Yogaratnam(Espial) 10:14:21 Topic: Presentation API testing 10:14:29 ericc has joined #webscreens 10:14:41 Anssi: We need to demonstrate interop to go to PR, and for that we need to create a test suite. 10:15:04 ... We should look at the current state and see what needs to be done. 10:15:54 ... Louay is test facilitator. Some contributions from students, WG participants, Francois prepared a human-readable test coverage document. 10:16:50 https://tidoust.github.io/presentation-api-testcoverage/#plan 10:17:00 ...Proposed action plan for how to proceed with testing. Three milestones to complete tests. 10:17:22 https://github.com/w3c/web-platform-tests/labels/presentation-api 10:17:29 ...End of October, work on existing tests and fix open issues. Four minor issues. 10:18:18 ...For each missing test, create an issue in web-platform-tests/presentation-api. Assign issues to test writers. 10:19:23 ...If there is a normative change, editor should ping Louay and the test author that tests need to be updated. 10:20:24 ...Need to move Chromecast app ids to a config file to avoid duplication. 10:20:49 ...Two web pages are registered with Fraunhofer accounts. Not allowed to publish with our account. 10:21:55 ...Need account to maintain published apps. 10:22:50 wonsuk has joined #webscreens 10:25:16 ...W3C can create account to publish. 10:25:34 ACTION: Francois to investigate creation of Cast developer account to publish test app. 10:31:07 kinjim has joined #webscreens 10:35:51 cpn has joined #webscreens 10:45:24 Louay: How to test different implementations (1-UA and 2-UA) in the same user agent and present a consolidated report. 10:45:33 Anssi: What is the status of 1UA? 10:45:50 https://tidoust.github.io/presentation-api-testcoverage/#table 10:45:52 Mark: The bread of the sandwich is done. The yummy parts in the middle are in progress. 10:46:12 Anssi: How to forward JSON test results from receiver? 10:46:34 Anssi/Mark: Cleaner to POST these to a separate service than to use the presentation connection. 10:46:52 Mark_Watson: Test harness spawns windows, may not work in a single-window environment. 10:47:10 Louay: Controller runs test on receiver, so don't need to spawn windows. 10:47:49 Francois/Louay review test coverage report. Goal is to prepare implementation report by the end of the December. 10:48:34 Anssi: Move coverage report to w3c repo? 10:48:44 Francois: Not part of test suite. Anssi: Leave as-is. 10:51:24 [FYI, iframe tests use a stash.py file to store test results on the server, see: https://github.com/w3c/web-platform-tests/blob/master/html/semantics/embedded-content/the-iframe-element/stash.py ] 10:53:22 Louay: Can check scripts to stash results. Or use WebSockets to exchange test results. 10:54:55 kumanan has joined #webscreens 11:00:19 Anton: Would a test receiver help that opens a window? Mark: Mocks out the receiver, could be useful for testing controller. 11:00:57 Louay: Call for test contributors. Tomoyuki: Offers to help. 11:01:30 cpn_ has joined #webscreens 11:03:30 i/...Proposed action plan for how to proceed with testing/scribenick: mfoltzgoogle/ 11:03:44 s/...Proposed action plan for how to proceed with testing/Anssi: Proposed action plan for how to proceed with testing/ 11:03:52 scribenick: tidoust 11:03:58 RRSAgent, draft minutes 11:03:58 I have made the request to generate http://www.w3.org/2016/09/22-webscreens-minutes.html tidoust 11:04:32 antonvayvodgoogle has joined #webscreens 11:06:05 Topic: Implementation status 11:07:25 Mark presents Google Cast for Education, intended for class rooms. Could be used for 1-UA mode as well as for 2-UA mode 11:09:44 Virtual screen access control goes through cloud. Mark gives access to Anton, who shares images. Implementation is a proof of concept not a full 2-UA implementation, it does not support multiple controllers for instance. The receiving API needs to be implemented. 11:11:54 The spec was not an obstacle to implement this. There's a little bit of work to do around security. 11:14:46 The device runs Chrome OS. The stack is different from the stack in Chromecast. The receiver part is a Chrome app. Being a Chrome app helps leveraging some useful features such as user login. 11:20:51 Mark mentioned the fact that Chrome shipped support for the Cast API which is built on top of the Presentation API under the hood. 11:22:37 The only plan for native implementation of receiver mode is 1-UA mode for Google. 11:24:05 Shih-Chiang shows a demo of Mozilla's implementation of the Presentation API using a Firefox OS TV simulator. 11:26:24 Device selection part is currently missing from the implementation. The TV simulator gets told to open the Web page. It exposes the receiving API to the Web page that gets loaded. 11:27:31 [FYI: Simulating Firefox OS for TV on your desktop (MDN) https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS_for_TV/Simulating_Firefox_OS_for_TV ] 11:27:37 Louay wonders whether the TV simulator can be used for testing the receiving side. The TV simulator is not publicly available. 11:29:19 Tomoyuki sees a public simulator, but it is an old version of the simulator. 11:32:11 Kumanan wonders about underlying protocols. Proprietary protocols are used. Topic will be discussed in the Second Screen CG tomorrow. Mark points out that Google Cast for Education does not really use the Cast protocol despite the name, but a cloud-based protocol. 11:32:32 Topic: Moving beyond CR 11:32:56 Anssi reviews the requirements to transition beyond CR. 11:39:04 A discussion around re-chartering milestones follows. Is Q1 2017 too optimistic? If the group needs to publish a new CR, it only has until mid-January 2017. 11:41:33 Shih-Chiang mentions Q1 2017 as implementation target for 1-UA mode. Mark says he targets end of the year for 1-UA mode as well. 2-UA mode is not going to be until Q1 2017. 11:43:45 2-UA mode is part of our CR exit criteria. It is work in progress in Firefox OS for TV, with no clear ETA for shipping at this stage. 11:45:05 Participants agree that Q2 2017 seems a better target for completion. 11:46:33 [lunch break] 11:46:36 RRSAgent, draft minutes 11:46:36 I have made the request to generate http://www.w3.org/2016/09/22-webscreens-minutes.html tidoust 11:48:33 ericc has joined #webscreens 12:12:34 Tomoyuki has joined #webscreens 12:25:00 Hiroki has joined #webscreens 12:33:09 takeshi has joined #webscreens 12:36:25 kinjim has joined #webscreens 12:43:02 kinjim has joined #webscreens 12:47:40 wonsuk has joined #webscreens 13:01:10 tidoust has joined #webscreens 13:03:36 mfoltzgoogle has joined #webscreens 13:04:02 ericc has joined #webscreens 13:04:47 kumanan has joined #webscreens 13:07:52 Topic: Presentation API v2 13:08:18 Anssi: Goal is to take version 1, fork it and start baking in new features. 13:09:01 kumanan has joined #webscreens 13:09:39 ... Let's look at v2 issues and see whether that triggers "excitment". 13:10:31 -> https://github.com/w3c/presentation-api/issues/61 Cloud paired screens as presentation targets 13:10:52 Mark: I think flashing out the requirements to do that would be useful. 13:13:06 Shih-Chiang: All of our envisioned developments so far target the local network. It would be useful to let the user decide on whether it allows a cloud-based screen that the app can interact with instead of trying to agree on a mechanism to achieve that. 13:14:33 ... WebRTC already has a mechanism for pairing two devices, maybe it would be easier for us to leverage this. 13:15:13 ... i.e. reuse the signaling channel. 13:16:26 Mark: Also, it could be useful to repurpose an RTCDataChannel for use in the Presentation API not for developers to change it. 13:16:52 ... Worth investigating 13:17:10 -> https://github.com/w3c/presentation-api/issues/61 Forced 1-UA mode for documents or frames 13:18:25 Mark: In some cases, the controller may be the powerful end, and power may be needed. Or low-latency is needed (e.g. in gaming) 13:20:33 ... Two possible options: 1/ a possibility to require 1-UA mode, 2/ a new API to present an offscreen frame or canvas (being able to access and control the remote DOM tree) 13:21:29 s|issues/61|issues/347 13:23:40 ... The second part could be similar to requestFullscreen. A kind of requestOffscreen. It's like a simpler use case for the Presentation API. 13:24:31 ... There's already some work being done in Chrome at least to turn a canvas into a MediaStream, so the first part could build on it. 13:24:43 https://wiki.whatwg.org/wiki/OffscreenCanvas 13:25:17 Anssi: That reminds me of the Offscreen canvas proposal discussed in WHAT WG. 13:25:47 -> https://github.com/w3c/presentation-api/issues/32 Allowing a page to turn itseld in a presentation session 13:26:01 kumanan has joined #webscreens 13:26:39 Mark: I think this use case is interesting. A device could pass by and become a controlling user agent for a presentation initially started on its own. 13:26:49 Anssi: How would you bootstrap this? NFC tapping? 13:27:13 Mark: It depends on context. For public devices, restrictions are obviously needed. 13:30:55 -> https://github.com/w3c/presentation-api/issues/338 Can the same browsing context act as a controller and a receiver? 13:31:39 Mark: Problem is around the restrictions the spec places on a receiving browsing context. 13:33:40 ... The spec does not prevent that case, but we may need to check the implications carefully. 13:34:06 ... Also, you may need a way to delegate permissions if the receiving user agent does not support user input as such. 13:34:25 cpn_ has joined #webscreens 13:36:26 Francois: The use case is somewhat different from a controlling page willing to spawn a presentation on "as many screens as possible". 13:36:52 Mark: Somewhat related though. The first presentation could spawn another presentation. There are pros and cons to both approaches. 13:37:18 Louay: The video wall use case comes to mind. 13:37:50 Ingar: Sync in this use case is typically within the scope of the Multi-Device Timing CG. That does not solve the bootstrapping problem. 13:39:50 -> https://github.com/w3c/presentation-api/issues/67 Compatibility with HbbTV 13:39:53 Francois: Part of CG discussions now. 13:41:04 -> https://github.com/w3c/presentation-api/issues/202 Presentations without communication channel 13:41:22 Francois: Some overlap with the "offscreen" idea. 13:41:55 Media capture from canvas: https://www.w3.org/TR/mediacapture-fromelement/#html-canvas-element-media-capture-extensions 13:44:40 Francois: This could allow for some bootstrapping scenarios, e.g. where the user uses NFC tapping to pass the URL. No communication channel can be established, but both ends can go through the backend to communicate. 13:45:18 -> https://github.com/w3c/presentation-api/issues/348 Presentation display capability detection 13:46:06 Mark: There may be different categories such as physical attributes, media capabilities, support for specific APIs (MSE, EME) or codecs, etc. 13:47:04 Anssi: HTMLMediaElement, getUserMedia come to mind for capabilities detection. 13:47:57 Mark: Higher priority should be around features that are independent of the content, so I/O characteristics typically. 13:48:28 ... It might be expressed preferences. Controller could say "I would work better if I had this or that capability". Usability enhancement. 13:49:29 Mounir: Having that as preferences has issues. You may want to ensure that you don't get some of the remote devices show up in the list. 13:52:56 kinjim has joined #webscreens 13:53:32 wonsuk has joined #webscreens 13:53:35 Mounir and Mark discuss preferences vs. constraints. 13:54:56 One issue is that this would leak more information to the app through "getAvailability". 13:58:32 Anssi: A good approach would be to look at concrete use cases. Keeping it simple is much better. "Input", etc. 13:59:00 Chris: When I discussed this internally, the discussion quickly turned into codecs. 13:59:14 Mounir: It's more an issue for the Remote Playback API. 13:59:50 Anssi: Looking at the streams API now. 14:00:08 Mark: Domenic and I look at it as streams evolve. No concrete action so far. 14:00:39 Anssi: Concluding this discussion, there seems to be valid use cases for v2. None of this should make its way to v1. 14:00:46 ... Our new draft charter would allow us to work on this. 14:01:00 Topic: Remote Playback API 14:01:36 Anssi: Looking at post-FPWD issues. 14:01:54 FYI: .captureStream() has shipped in Chrome. https://www.chromestatus.com/features/4817998447640576 14:02:34 -> https://github.com/w3c/remote-playback/issues/48 Implementation guidance for browsers that a media element with controls is remoted 14:03:10 Anton: Some suggestion to convey that remoting is happening and that some poster image should be displayed. 14:03:41 Anssi: I think different implementations convey things differently. We can add a note. 14:04:04 Mark: From a privacy point of view, it seems important to ensure the user is aware that something is happening remotely. 14:06:42 tidoust2 has joined #webscreens 14:06:59 Chris: Or would you have an event about remoting changes of state? 14:07:09 i/Chris: Or would you have an event about remoting changes of state?/scribenick: tidoust2/ 14:07:19 Anton: You will get events. 14:07:50 Anssi: The user should always be notified about what is happening. 14:08:17 ... Generally, it is a bad idea to specify anything specific to UI in a spec. 14:09:35 Anton: The spec does not say whether the local playback should be paused. 14:11:36 Anssi: I would not force the local playback to pause. That can be useful in some cases. 14:12:28 Francois: It seems important to ensure that the app developer knows whether the local playback is still running or not. 14:13:13 ... Also, you probably do not want the local audio rendering to continue, because synchronization will be very hard to achieve. 14:13:45 Anton: Except in the case where you want to watch a video in two different rooms, you probably want to pause local playback. 14:15:07 Anssi: So should we expose a way to know whether the local playback is still running? 14:15:30 Mounir: I think the spec should be explicit that local playback needs to be paused. 14:16:04 Francois: Yes, if the developer wants to continue playback, he can create another media element and handle the synchronization on his own. 14:16:09 Anssi: OK. 14:16:25 Anton: From the point of view of the page, the media will still be playing. 14:17:08 -> https://github.com/w3c/remote-playback/issues/10 Define the relation with Media Session spec 14:17:19 kinjim has joined #webscreens 14:17:23 Anton: We're waiting on media session to move forward. 14:19:46 Mounir: We re-scoped this effort and transitioned to WICG. 14:20:02 Anton: So only action is to wait until the spec matures and revisits. 14:21:56 -> https://github.com/w3c/remote-playback/issues/41 Guidance for HTMLMediaElement 14:22:40 Anton: The issue is that media element is like a big interface. What should work and what should not work in the remote state? 14:22:58 ... I've started to list what needs or does not need to be supported. 14:24:53 Francois: Interesting, because it looks like a "profile" of the HTMLMediaElement interface, which makes perfect sense, but may not please some people. 14:26:00 Kumanan: Feature detection is already used to detect whether some of these features are supported in the simple local case. 14:26:25 ... You may not be able to seek for instance, and you cannot ask more than what the remote device can achieve. 14:27:42 ... In the set-top box case, there may be legal restrictions for some of these features. 14:27:52 Anton: OK, so we should be careful for some of these MUST. 14:29:19 Anssi: OK, we'll get to details tomorrow. 14:31:18 i/Mounir: We re-scoped this effort and transitioned to WICG./scribenick: tidoust/ 14:31:24 RRSAgent, draft minutes 14:31:24 I have made the request to generate http://www.w3.org/2016/09/22-webscreens-minutes.html tidoust 14:38:38 tidoust2 has joined #webscreens 14:38:54 ericc has joined #webscreens 14:39:38 kumanan has joined #webscreens 14:42:59 Tomoyuki has joined #webscreens 14:43:52 Hiroki has joined #webscreens 14:58:52 wonsuk has joined #webscreens 15:00:29 kumanan has joined #webscreens 15:24:52 kinjim has joined #webscreens 15:29:58 schuki has joined #webscreens 15:32:52 kumanan has joined #webscreens 15:36:46 Tomoyuki has left #webscreens 15:53:53 Tomoyuki has joined #webscreens 15:53:55 Tomoyuki has left #webscreens 15:54:53 wonsuk has joined #webscreens 16:30:29 wonsuk has joined #webscreens 16:30:40 wonsuk_ has joined #webscreens 16:31:28 kinjim has left #webscreens 16:34:47 tidoust has joined #webscreens 16:40:13 ericc has joined #webscreens 16:53:24 ericc has joined #webscreens 17:02:49 Hiroki has joined #webscreens 18:02:30 ericc has joined #webscreens 18:53:31 ericc has joined #webscreens 22:30:10 ericc has joined #webscreens 22:49:12 Hiroki has joined #webscreens 22:51:57 Hiroki_ has joined #webscreens 23:34:58 ericc has joined #webscreens