14:06:55 RRSAgent has joined #tvapi 14:06:55 logging to http://www.w3.org/2017/02/07-tvapi-irc 14:07:02 RRSAgent, make logs public 14:07:12 Meeting: TV Control WG Call 14:07:18 Chair: Chris 14:07:20 Present+ Francois 14:07:22 Present+ Chris 14:07:26 Present+ Jean-Pierre 14:07:29 Present+ Steve 14:07:37 Topic: Group re-chartering 14:07:47 Chris: I sent an email to the group with the current plan. 14:08:06 ... Current plan is to request a 18 month extension. 14:08:23 ... I got some offline feedback from IRT to say that they are fine with the plan. 14:08:32 ... Jean-Pierre is ok with the plan as well. 14:08:45 ... We need to attract more participation from other people in the industry. 14:09:09 ... DVB will be meeting in the next few weeks, and the TV Control WG is on their agenda. 14:09:20 ... I do not want what ATSC and HbbTV views are 14:09:36 ... At some point, I guess we can go back to them 14:09:48 i/Meeting: TV Control WG call/scribenick: tidoust/ 14:10:05 Chris: Next process steps? 14:10:22 ... No change to the charter envisioned so far. 14:11:13 Francois: I agree not to change the scope, so I'll draft a new charter with updated milestones and end date, and some boilerplate. 14:11:27 ... I'll do this when I'm back from vacation and send it to W3C management for review 14:12:02 Agenda: http://lists.w3.org/Archives/Public/public-tvcontrol/2017Feb/0013.html 14:12:11 Topic: Liaisons 14:12:41 Chris: Just a brief recap. 3 letters sent to ATSC, DVB, HbbTV. Reply from DVB should come soon. 14:13:25 ... DVB asked for a little bit of clarification, which I provided: raise awareness about this work among W3C membership and see if some DVB members could join W3C to help us with this work. 14:13:46 ... Also some indication about what they think of the work, regardless of whether they can participate in it. 14:13:59 ... Its potential for adoption and future use in devices and so on. 14:14:27 Topic: Recent API changes 14:14:51 Chris: My initial thoughts for the call was to ask Steve to take us through the changes he made to the specification. 14:15:35 ... But I guess that, since it's only the 4 of us, it may be more valuable to go through Francois' comments and discuss how to address them. 14:15:58 Steve: Right. Thanks for the comments, I went through them and started to update my local copy of the draft. 14:16:40 ... Starting with the first one, dropping the TVTuner, links back to a recent comment from Paul on GitHub 14:17:18 ... The question on detecting the addition/removal of a tuner is a good one. I'm leaning towards adding a new event to report change of capability. 14:17:49 ... That should only happen in the PC world where you may add a USB cable tuner for instance. 14:18:09 ... There are corner cases where things can go fairly complicated, I'm not sure I want to get into. 14:18:30 ... That is, I'm not sure there's any sensible way of handling it. 14:19:32 ... You either have your capabilities change silently or you have a change in the set of sources you support. I was sort of looking at this and wondering, despite Paul's comment, whether exposing a tuner interface actually gives us anything. 14:19:46 ... I'm not convinced it does help us do anything. 14:21:00 Chris: I can see the case where you add DVB-S to a device, effectively adding a new source type. If you add a DVB-T tuner to a device that already has a DVB-T tuner, the number of simultaneous streams that you can get will effectively change. 14:21:27 Steve: Not exposed in the current version. So adding the tuner is really silent. 14:21:45 ... How much do we want to complicate the API? 14:22:29 Chris: It might be useful to compile the list of use cases. 14:22:34 Steve: Will do it in the Wiki. 14:22:41 Chris: Thank you. 14:23:56 Francois: Is adding or removing tuners something that will happen often? We could already consider adding USB tuners as a corner case 14:24:39 ... I would not complicate the API too much. An API to notify of changes in hardware can be useful but maybe we don't need too much detail 14:25:13 Steve: I agree. 14:26:02 Chris: Another question: what are the application level use cases (type 1, 2, or 3) who would want to respond to a change of underlying hardware capabilities. 14:26:22 ... For a Type 1 application, I see the need to trigger channel scanning again for instance. 14:26:38 ... For type 2 applications (broadcast related apps), I'm not clear that's needed. 14:27:47 Steve: It really comes down to at what level you expose capabilities. 14:28:15 ... Your MediaStream may suddenly stop delivering data if the hardware changes. That's a fact of life. 14:28:55 Chris: OK. 14:29:02 ... Other points to look at? 14:29:49 Steve: There's the editorial issue with definitions, that I'll pick up with Francois 14:30:22 -> https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-277255940 Francois' comments 14:30:32 [going through the list of comments one by one] 14:31:42 Steve: About TVSourceCapabilities, my reading is that you have 4 sets: The set of constraints where you say whether you support the constraint or not, booleans. Then there's the capabilities, which is where you specify what the device can do. 14:32:11 ... When you request a video source in media capture, you can specify a set of constraints on it. 14:32:29 ... Potentially, you can set only that as constraints and be happy about what you get back. 14:32:45 ... My understanding about settings is that it tells you what you get back. 14:33:06 ... For instance, you may say "I want forward-facing camera". That's the constraint. 14:33:25 ... The settings tell you "It's a forward-facing camera with that resolution and frame rate, etc". 14:34:11 ... For us, you might choose to ask a DVB-T source. You may get back back a source that supports both DVB-T and DVB-C. 14:35:01 Steve: I'm folllowing the media capture spec: https://www.w3.org/TR/mediacapture-streams/ 14:35:57 ... i.e., the Constrainable pattern 14:37:12 s/folllowing/following/ 14:37:44 Francois: If there's getConstraints and getSettings in media capture, then let's do the same thing, no problem whatsoever 14:37:58 Steve: Right, I may have missed something, but that's what I wanted to do. 14:38:10 ... Last commen on TVManager, I do not have strong feelings about it. 14:38:52 Francois: Right, it's a minor point, I believe it is good practice to restrict the API surface, and prefer enumerations to adding new variations of the same method, but that's a minor point. 14:39:25 Chris: OK, I'll try to follow up with other participants in the group. 14:39:48 ... Sony, and also with Paul given how much he was engaged in the group early on. 14:40:53 ... I'll read the Constrainable pattern again as well to check details, but what you did looks good. 14:41:41 ... About getTVManager, getRadioManager, do you really need to return different managers? 14:42:16 Steve: I suspect the case where this may matter is when you have a device that supports both TV and radio, and a unified channel list at the manager level. 14:42:27 ... If it is at the source level, I agree it may not be needed. 14:46:08 Chris: I would think that between all active participants in the group, we should be able to get to an agreement regarding the API. It's taken a few iterations to get us where we are now, but it's very good progress. Many thanks Steve for the effort you invested in this! 14:47:00 Chris: I see a couple of new issues, 44 about dropping the -ed suffix for event names. 14:47:24 ... And 45 about renaming section headings to avoid using "interface" for "dictionary". 14:47:28 Steve: Both done locally. 14:48:12 Chris: Excellent. Then, there's issue 41 about timestamps. 14:48:23 ... There's the question of seconds vs. milliseconds 14:48:38 Steve: Right, my gut feeling tells me that milliseconds gives you a false level of precision. 14:48:50 Chris: It may useful to look at other specs, DVB. 14:49:33 Steve: I would incline to say go with whatever natural unit DOMTimestamp goes with, just noting that you will never really have millisecond precision. 14:50:42 [further discussion on timestamps] 14:51:11 Chris: Which also raises the question of the "establish the media timeline" algorithm, defined in HTML5. 14:51:37 ... I'm just thinking about all the work that DVB has done recently about second screen capabilities and stream synchronizations. 14:52:04 Steve: I was actually looking at chasing down references in HbbTV and OIPF to see what it says there. 14:53:16 ... I'm inclined to take the view that if someone else already solves it, we should just follow his lead. 14:53:45 Chris: OK, I think we just need to get back to it once we're ready for it, no need to look into it right now. 14:54:56 Chris: Are there other topics we should discuss today? 14:55:19 ... Michael from IRT sent regrets, he is still looking at mapping. Nothing to report so far. 14:56:46 ... I would have hoped to get more participation in the call today and get more feedback about the API re-design. 14:57:25 ... Next call in 4 weeks as usual. 7th of March. 14:57:36 ... We'll continue the work on the mailing-list anyway. 14:57:55 ... Thank you all for joining us today, see you in 4 weeks! 14:58:13 RRSAgent, draft minutes 14:58:13 I have made the request to generate http://www.w3.org/2017/02/07-tvapi-minutes.html tidoust 15:18:52 i/Francois: I agree not to change the scope/scribenick: cpn/ 15:19:04 i/Topic: Liaisons/scribenick: tidoust 15:19:17 i/Francois: Is adding or removing tuners/scribenick: cpn/ 15:19:30 i/Steve: I agree./scribenick: tidoust/ 15:19:47 i/Steve: I'm folllowing the media capture spe/scribenick: cpn/ 15:19:58 i/Francois: If there's getConstraints and getSettings/scribenick: tidoust/ 15:20:04 RRSAgent, draft minutes 15:20:04 I have made the request to generate http://www.w3.org/2017/02/07-tvapi-minutes.html tidoust 15:20:47 i/Topic: Group re-chartering/scribenick: tidoust/ 15:20:51 RRSAgent, draft minutes 15:20:51 I have made the request to generate http://www.w3.org/2017/02/07-tvapi-minutes.html tidoust 15:28:12 RRSAgent, bye 15:28:12 I see no action items