13:50:33 RRSAgent has joined #tvapi 13:50:33 logging to http://www.w3.org/2016/12/13-tvapi-irc 13:50:39 RRSAgent, make logs public 13:50:51 Meeting: TV Control WG Call 13:51:51 Agenda: https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0026.html 13:51:55 Chair: Chris 13:55:56 cpn has joined #tvapi 14:00:03 Present+ Francois 14:00:08 Present+ Chris 14:00:14 Present+ AlexE 14:00:27 Present+ Ryan_Davis 14:00:39 Present+ Tatsuya 14:00:53 rdavvis has joined #tvapi 14:03:14 kaz has joined #tvapi 14:04:09 AlexE has joined #tvapi 14:04:21 Scribe: tidoust 14:05:06 Chris: [reviewing agenda] 14:05:11 https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0026.html 14:05:50 Chris: The main thing that I wanted to talk about today is the re-chartering of the group, to discuss the timeline. 14:05:58 Present+ Kaz 14:06:16 Present+ Steve 14:06:54 Chris: I think we need to follow up on liaison with ATSC as part of the re-chartering for instance. 14:07:52 ... Following that, if we have time, I'd like to discuss a bit the source-centric design of the API. I'd like to get agreement on the direction and technical details related to alignment to getUserMedia. 14:08:09 Michael: Any chance to discuss the issues I added recently? 14:08:20 Present+ Michael_Probst 14:08:31 Chris: If time allows, yes. 14:08:46 ... We only have an hour but I'll try to leave some time towards the end. 14:08:51 Topic: Rechartering 14:09:35 Chris: The WG is chartered until the end of March 2017. Because of the time involved in getting approval to continue work beyond March, we really need to discuss and decide the approach we want to take and put together a new charter. 14:10:08 ... The first question is to ask a show of support here that this is something that we want to do collectively. 14:10:39 ... I would possibly suggest that we continue with the rechartering process. If someone feels this is not appropriate, please let us know. 14:11:07 ... What I've been discussing with Francois is that we need a new charter by end of January 2017 for it to be reviewed by W3C Management. 14:11:24 ... I propose we look at the existing charter and review time scale and milestones in particular. 14:11:26 http://www.w3.org/2016/03/tvcontrol.html 14:12:12 ... I'd like to get feedback on the mailing-list on items that you feel should be amended in any way. Items that should no longer be in scope? 14:12:23 ... It may be that we're happy with the scope of the current charter. 14:12:55 ... Unless there's any objection, largely we would go forward with the charter as it stands. I may propose a few adjustments though. 14:13:12 ... Important to get the new charter in right shape for end of January 2017. 14:13:48 ... One thing we could discuss here is time scale. In the current charter, we said we'd reach the Recommendation level Q1 2017. 14:14:02 ... In practice, we haven't made much progress beyond First Public Working Draft. 14:14:31 ... We need to prepare new milestones that will take us to Candidate Recommendation. 14:15:14 ... I do not have a clear view on this. Hopefully, if we get agreement on the source-centric design fast enough, then it should be easier to make progress on remaining issues. 14:15:39 ... Does anyone have comments or feedback on the milestone for Candidate Recommendation? 14:16:08 ... We'll have to ask for a certain period of extension. Do we want to go for 12 months longer? 18 months? 14:17:25 Alex: Given that we're looking at liaisons with other organizations to set the API in a broader context, we're going to need some time. For instance, given the pace of HbbTV meetings, we should aim at a longer period of time to set up the liaison and discuss. 14:17:59 Chris: True. 14:18:52 Chris: One of the issues that came up during TPAC is around recording. One question in my mind is whether this is a feature that we could either separate from the main document in another document or drop from scope. 14:19:15 Ryan: From an automotive perspective, I don't think recording is a feature that we're immediately interested in. 14:20:17 Chris: One other thing is that we need to have a story to tell W3M on industry adoption of the API. 14:20:39 ... We need support from external groups on work that we're doing here. 14:20:49 ... This is an area that will be looked at closely as part of the review process. 14:21:44 ... Initially the charter will go through W3M, and then there will be an AC call for review, and then we need to meet a certain threshold of support among members. 14:23:01 Francois: One thing to add, is depending on how discussion goes with the external groups, if we feel we need more time to get feedback, we could request a 3 month exension 14:23:27 ... W3C management could grant this without asking the AC, but this would depend on the industry feedback 14:23:54 i/Francois: One thing to add/scribe: cpn/ 14:23:58 scribe: tidoust 14:24:21 Chris: Thanks, that brings us to the next topic, the liaison letters that we may want to send. 14:24:41 ... Given our history of exchanges with ATSC, it seems a good idea to send them an update. 14:24:53 ... Jean-Pierre also suggested DVB. HbbTV comes to mind as well. 14:25:03 ... First, do you think that's the right way to go? 14:26:00 Alex: I had a talk with my manager, chairman of HbbTV, and he is looking forward to that exchange. From our point of view, it absolutely makes sense to align the work of both groups. 14:26:16 https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0028.html 14:26:19 Chris: OK, thank you. 14:26:27 rrsagent, make log public 14:26:32 rrsagent, draft minutes 14:26:32 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html kaz 14:26:34 ... For ATSC, I prepared and shared a draft letter. 14:26:48 ... Did you have a chance to review this? 14:27:52 Francois: +1 from me, letter looks good to me 14:28:55 Igarashi-san: I'm OK with the text of that liaison. At this point, I don't see a strong interest to adopt this API in ATSC. 14:29:24 ... ATSC is trying to finalize their spec in the upcoming months, so it's unlikely that they see a huge need for it. 14:29:31 ... But it's a good idea to ask. 14:29:58 Chris: OK, then I think we can move ahead and send this 14:30:21 ... In parallel, I'll draft a new letter that we could send to HbbTV. It would probably be quite similar. 14:31:01 Francois: Which DVB group in particular? 14:31:21 Chris: I had some email exchanges with Jean-Pierre about this. 14:31:31 i/Francois: Which DVB group/scribe: cpn/ 14:32:03 Chris: His suggestion was to go to the DVB coordinator, who will determine which group that should go to. 14:32:14 Francois: Looks good if it's the DVB way of doing things. 14:32:23 Chris: Seems so. Jean-Pierre should be able to help. 14:32:44 ACTION: Chris to propose liaison letters for DVB and HbbTV. 14:32:44 Error creating an ACTION: data field(s) missing from result. Please mail with details about what happened. 14:33:07 Chris: Hopefully, we'll get some feedback that we can provide to W3C Management. 14:33:18 ... Are there other groups that would be worth approaching? 14:33:41 Alex: Yes, probably worth reaching out to RadioDNS as well. There's still the not so active RadioWEB work there. 14:34:11 ... I suggested that they wait and reference our work. 14:34:35 ... I would contact Matthias ?!?, chair of RadioDNS, about that. 14:34:43 Chris: Yes. Is RadioWEB still active? 14:35:21 Alex: Many people registered for it. It's still an issue to do, I posted a first draft but never received significant feedback about it. 14:35:51 ... I suggested not to work on a tuner API if we could re-use work we're doing in the TV Control WG. Making a reference to the specification of the W3C group would be easier. 14:36:06 Chris: I see. Sounds good. Speaking as BBC, I support this. 14:37:17 Francois: We may not need a formal liaison from a W3C perspective to talk to RadioDNS 14:38:06 Chris: OK. This brings two things to mind. One is the scope of the charter to make sure radio is well covered. 14:38:44 ... Second, I'd like to increase the number of participants in this group, but I'm slightly concerned that organizations that are e.g. involved in RadioDNS are not W3C Members. 14:39:00 ... I'll work with you, Alex, on the RadioDNS front. 14:39:16 Topic: Source-centric API model and getUserMedia 14:39:32 i/Chris: I had some email exchanges/scribe: tidoust 14:39:48 Chris: Steve shared some thoughts on the source centric design 14:39:56 https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0010.html 14:40:42 ... I'd like to understand whether the group agrees with that direction. Steve, can you talk us through the 2 related approaches that are on the table? 14:41:08 [Oops, Steve dropped off the call] 14:42:04 Chris: What we're finding is that the TV tuner concept is too tied to the hardware. There's a lot of variation in the wild, and not a clean mapping between the API and what is going on in practice. 14:42:37 ... We discussed a source-centric approach and this is what led us to this new proposal. 14:43:10 ... A source gives you a way to fetch a list of channels, which you can tune the source to. 14:43:49 ... This gives you a "tuner" (same name but different meaning) which you can reuse to switch to another channel. 14:44:17 ... From a source, you can then getMediaSessions to get a list of sessions that are currently running on a source. 14:44:34 ... Resource management is done by the user agent. 14:45:27 Alex: One question regarding the source "tuneTo" method. The tuner optional parameter means that if I don't pass it, the implementation allocates things automatically, right? 14:45:29 Chris: Yes. 14:46:06 ... The parameters allows you to reuse the same resource when you already hold it. 14:46:38 q+ 14:46:41 Alex: If I'm aware that I have only one tuner which I pass around to that function, then I'm signaling my intent to reuse it. 14:47:26 Chris: Then there is the question which we raised at TPAC on how we could provide some indication about the desired characteristics of the channel. 14:48:06 ryan: what I want to do is not only "Tuner" but "Player" 14:48:14 me thanks kaz 14:48:25 s/me thanks kaz// 14:48:35 ... each player may say it has three tuners 14:48:46 ... how those could be set up? 14:49:08 ... we may have multiple "resources" 14:49:28 ... any of the player can access different kind of resources 14:49:58 ... e.g., there are a lot of tuners in automotive 14:50:13 ... taking URLs and play the media 14:50:27 ... "Play this URL for next" 14:50:41 ... there is a list of IDs 14:51:01 ... a player is available and a tuner is available 14:51:19 cpn: how different is this from the API we've been working on 14:51:42 ryan: my problem is that possibly having two different tuners 14:52:04 ... we should abstract the situation 14:52:33 ... look up the ID for some specific resource to play some content 14:52:50 ... playing audio and send it to a speaker is for one player 14:53:10 ... and playing another audio and send it to a headphone is another player 14:53:28 ... and also send data to a recorder 14:53:40 [I note this seems to align somewhat with Media Session: https://wicg.github.io/mediasession/ ] 14:53:56 alex: what do you want here? 14:54:07 ... what to describe semantically? 14:54:39 ... I would rename "Tuner" 14:54:44 ryan: right 14:54:49 ... it should be "Player" 14:55:22 ... you can classify resources to play 14:55:52 cpn: is this just a terminology? 14:56:12 ryan: I don't care what the module is doing (internally) 14:56:31 ... I just send some URL to play 14:56:47 cpn: we don't really have that capability 14:57:06 ryan: channel number, etc., also could be some kind of URL 14:57:51 ... very similar to cloud type mechanism we have for automotive integration 14:58:06 ... lot of features are actually handle on the cloud side 14:58:25 ... and the player plays the content based on URL 14:58:29 q+ 14:58:35 q? 14:58:44 Zakim has joined #tvapi 14:58:50 q+ tidoust 14:58:51 q+ 14:59:11 ryan: have been toying with the spec 14:59:22 cpn: please share it 14:59:51 steve: slightly different terminology 15:00:28 Kaz: I just wanted to mention 2 different topics here: Multiple resources support and resource identification. 15:01:17 ... Ryan approach is using URIs. There has been discussions in the GGIE TF of the Web and TV IG, leading to some IETF work, I think. 15:01:24 Chris: Do you have a pointer to the IETF work? 15:01:42 ... I haven't heard much from the task force recently. 15:01:54 Ryan: Any addressable stream would do in my approach. 15:02:08 rrsagent, draft minutes 15:02:08 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html kaz 15:02:37 i/what I want to do/scribenick: kaz/ 15:02:58 i/I just wanted/scribenick: tidoust/ 15:03:01 rrsagent, draft minutes 15:03:01 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html kaz 15:03:38 Francois: I have drafted a letter to the devices and sensors group regarding the getUserMedia approach. Can I go ahead and send this? 15:03:49 s/Ryan approach/Ryan's approach/ 15:04:01 i/I have drafted/scribe: cpn/ 15:04:31 Topic: Issues from Michael 15:04:31 rrsagent, draft minutes 15:04:31 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html kaz 15:04:59 Michael: I looked at it with my HbbTV experience, and I found a number of issues. 15:05:11 i/looked at/scribenick: tidoust/ 15:05:17 rrsagent, draft minutes 15:05:17 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html kaz 15:05:39 ... One of them around TVTriggerCue for instance: https://github.com/w3c/tvcontrol-api/issues/36 15:06:16 Chris: Right, I see you raised that a long ago. 15:06:55 Michael: Also some question on broadcast events related to the EPG. I was a bit confused as to how this can be mapped onto DVB here. 15:07:09 ... Maybe I'm wrong and I just misunderstood your work. 15:07:21 ... Maybe that can be addressed through liaisons. 15:07:28 q+ 15:07:39 ack k 15:08:16 Chris: I suppose so. I would expect more of these issues to arrise as we go through the exercise of mapping the API onto underlying protocols. 15:08:41 ... That's something we identified as a valuable thing to do, but we're not sure how to do it. How do we capture these mappings? 15:09:10 ... Do we want to define that as a W3C spec? In a less "formal" way? 15:09:47 ... To verify that the API has the right structure and exposes the right information, we do need to look into these mappings, but that may be a separate thing to producing a concrete mapping spec. 15:10:11 ... Initially, taking a less formal approach, e.g. through our Wiki, to capture some of these mappings might be a good starting point. 15:10:39 ... Whether the work to formalize these mappings needs to be done by this group, other groups in other organizations, can be answered later on. 15:11:06 ... If you have the time, it would be helpful to propose specification changes that you think are maybe needed to support some of these. 15:12:17 Michael: OK. I think it probably would be good to try to map the API to broadcast technologies like DVB. This also probably increases the potential adoption by other organizations such as HbbTV. 15:12:27 ... What I don't want is to have to change the API too much. 15:12:35 https://www.w3.org/wiki/TV_Control/Protocol_Mappings 15:13:01 Chris: I just shared a link to our Wiki page that collects a list of pointers. 15:13:29 ... When issues arise, we can capture things on GitHub. 15:13:58 ... We need more active participation in the group to resolve some of these issues. 15:14:21 ... It may well depend on the outcomes of these liaisons. 15:15:47 ... I want to say thank you for the issues that you raised. These issues are very useful to capture. Don't be put off by the limited amount of feedback you got so far. Current focus has been on the source-centric design, but these issues are very very valuable and need to be addressed 15:15:52 RRSAgent, draft minutes 15:15:52 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html tidoust 15:16:20 Chris: I encourage other participants to create more issues and provide feedback. 15:17:07 Alex: Thank you for that. Once we're done with the source-centric issue, there are a lot of questions to go through. I agree they will be easier to deal with once we're done with the architectural issue. 15:17:14 Chris: Right, that is my feeling as well. 15:18:07 ... One question for the mapping specs is whether we identify them as deliverables in the new charter. 15:18:25 ... Current wording leaves some leeway. Same approach might work for the new charter. 15:18:43 ... I would be extremely happy if someone can step up and contribute such mappings. 15:19:04 ... Anything else that we'd like to talk about today? 15:19:42 ... Thanks for your time today! 15:19:47 [Call adjourned] 15:19:53 RRSAgent, draft minutes 15:19:53 I have made the request to generate http://www.w3.org/2016/12/13-tvapi-minutes.html tidoust 17:18:51 Zakim has left #tvapi