TV Control WG Call

Chris: [reviewing agenda]

Chris: The main thing that I wanted to talk about today is the re-chartering of the group, to discuss the timeline.
... I think we need to follow up on liaison with ATSC as part of the re-chartering for instance.
... 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.

Michael: Any chance to discuss the issues I added recently?

Chris: If time allows, yes.
... We only have an hour but I'll try to leave some time towards the end.

Rechartering

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.
... The first question is to ask a show of support here that this is something that we want to do collectively.
... I would possibly suggest that we continue with the rechartering process. If someone feels this is not appropriate, please let us know.
... 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.
... I propose we look at the existing charter and review time scale and milestones in particular.

Chris: 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?
... It may be that we're happy with the scope of the current charter.
... Unless there's any objection, largely we would go forward with the charter as it stands. I may propose a few adjustments though.
... Important to get the new charter in right shape for end of January 2017.
... One thing we could discuss here is time scale. In the current charter, we said we'd reach the Recommendation level Q1 2017.
... In practice, we haven't made much progress beyond First Public Working Draft.
... We need to prepare new milestones that will take us to Candidate Recommendation.
... 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.
... Does anyone have comments or feedback on the milestone for Candidate Recommendation?
... We'll have to ask for a certain period of extension. Do we want to go for 12 months longer? 18 months?

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.

Chris: True.
... 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.

Ryan: From an automotive perspective, I don't think recording is a feature that we're immediately interested in.

Chris: One other thing is that we need to have a story to tell W3M on industry adoption of the API.
... We need support from external groups on work that we're doing here.
... This is an area that will be looked at closely as part of the review process.
... 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.

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 extension
... W3C management could grant this without asking the AC, but we need good arguments e.g. we're still waiting for an answer to our letters

Chris: Thanks, that brings us to the next topic, the liaison letters that we may want to send.
... Given our history of exchanges with ATSC, it seems a good idea to send them an update.
... Jean-Pierre also suggested DVB. HbbTV comes to mind as well.
... First, do you think that's the right way to go?

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.

<cpn> https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0028.html

Chris: OK, thank you.
... For ATSC, I prepared and shared a draft letter.
... Did you have a chance to review this?

Francois: +1 from me, letter looks good to me

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.
... ATSC is trying to finalize their spec in the upcoming months, so it's unlikely that they see a huge need for it.
... But it's a good idea to ask.

Chris: OK, then I think we can move ahead and send this
... In parallel, I'll draft a new letter that we could send to HbbTV. It would probably be quite similar.

<inserted> scribe: cpn

Francois: Which DVB group in particular?

<inserted> scribe: tidoust

Chris: I had some email exchanges with Jean-Pierre about this.
... His suggestion was to go to the DVB coordinator, who will determine which group that should go to.

Francois: Looks good if it's the DVB way of doing things.

Chris: Seems so. Jean-Pierre should be able to help.

<scribe> ACTION: Chris to propose liaison letters for DVB and HbbTV. [recorded in http://www.w3.org/2016/12/13-tvapi-minutes.html#action01]

<trackbot> Error creating an ACTION: data field(s) missing from result. Please mail <sysreq@w3.org> with details about what happened.

Chris: Hopefully, we'll get some feedback that we can provide to W3C Management.
... Are there other groups that would be worth approaching?

Alex: Yes, probably worth reaching out to RadioDNS as well. There's still the not so active RadioWEB work there.
... I suggested that they wait and reference our work.
... I would contact Matthias ?!?, chair of RadioDNS, about that.

Chris: Yes. Is RadioWEB still active?

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.
... 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.

Chris: I see. Sounds good. Speaking as BBC, I support this.

<cpn> Francois: We may not need a formal liaison from a W3C perspective to talk to RadioDNS

Liaison letters

Chris: OK. This brings two things to mind. One is the scope of the charter to make sure radio is well covered.
... 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.
... I'll work with you, Alex, on the RadioDNS front.

Source-centric API model and getUserMedia

Chris: Steve shared some thoughts on the source centric design

Chris: 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?

[Oops, Steve dropped off the call]

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.
... We discussed a source-centric approach and this is what led us to this new proposal.
... A source gives you a way to fetch a list of channels, which you can tune the source to.
... This gives you a "tuner" (same name but different meaning) which you can reuse to switch to another channel.
... From a source, you can then getMediaSessions to get a list of sessions that are currently running on a source.
... Resource management is done by the user agent.

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?

Chris: Yes.
... The parameters allows you to reuse the same resource when you already hold it.

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.

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.

ryan: what I want to do is not only "Tuner" but "Player"
... each player may say it has three tuners
... how those could be set up?
... we may have multiple "resources"
... any of the player can access different kind of resources
... e.g., there are a lot of tuners in automotive
... taking URLs and play the media
... "Play this URL for next"
... there is a list of IDs
... a player is available and a tuner is available

cpn: how different is this from the API we've been working on?

ryan: my problem is that possibly having two different tuners
... we should abstract the situation
... look up the ID for some specific resource to play some content
... playing audio and send it to a speaker is for one player
... and playing another audio and send it to a headphone is another player
... and also send data to a recorder

<tidoust> [I note this could perhaps relate with Media Session: https://wicg.github.io/mediasession/ ]

alex: what do you want here?
... what to describe semantically?
... I would rename "Tuner"

ryan: right
... it should be "Player"
... you can classify resources to play

cpn: is this just a terminology?

ryan: I don't care what the module is doing (internally)
... I just send some URL to play

cpn: we don't really have that capability

ryan: channel number, etc., also could be some kind of URL
... very similar to cloud type mechanism we have for automotive integration
... lot of features are actually handle on the cloud side
... and the player plays the content based on URL
... have been toying with the spec

cpn: please share it

steve: slightly different terminology

Kaz: I just wanted to mention 2 different topics here: Multiple resources support and resource identification.
... Ryan's 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.

Chris: Do you have a pointer to the IETF work?
... I haven't heard much from the task force recently.

Ryan: Any addressable stream would do in my approach.

Francois: I have drafted a letter to the devices and sensors group regarding the getUserMedia approach. Can I go ahead and send this?

Mapping issues

Michael: I looked at it with my HbbTV experience, and I found a number of issues.
... One of them around TVTriggerCue for instance: https://github.com/w3c/tvcontrol-api/issues/36

Chris: Right, I see you raised that a long ago.

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.
... Maybe I'm wrong and I just misunderstood your work.
... Maybe that can be addressed through liaisons.

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.
... 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?
... Do we want to define that as a W3C spec? In a less "formal" way?
... 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.
... Initially, taking a less formal approach, e.g. through our Wiki, to capture some of these mappings might be a good starting point.
... Whether the work to formalize these mappings needs to be done by this group, other groups in other organizations, can be answered later on.
... If you have the time, it would be helpful to propose specification changes that you think are maybe needed to support some of these.

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.
... What I don't want is to have to change the API too much.

Chris: Here is the Wiki page that collects a list of pointers.
... When issues arise, we can capture things on GitHub.
... We need more active participation in the group to resolve some of these issues.
... It may well depend on the outcomes of these liaisons.
... 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
... I encourage other participants to create more issues and provide feedback.

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.

Chris: Right, that is my feeling as well.
... One question for the mapping specs is whether we identify them as deliverables in the new charter.
... Current wording leaves some leeway. Same approach might work for the new charter.
... I would be extremely happy if someone can step up and contribute such mappings.
... Anything else that we'd like to talk about today?
... Thanks for your time today!

[Call adjourned]