TV Control CG/WG call

31 May 2016


See also: IRC log


Youngsun_Ryu, Chris_Needham, Francois_Daoust, Alex_Erk, Kaz_Ashimura, Tatsuya_Igarashi, Steve_Morris, Bill_Rose


Chris: Welcome to this joint call between the TV Control CG and WG.
... [going through the agenda]
... Any other topic to add to the agenda?

[none heard]

Spec status

Chris: Thanks Francois for organizing our GitHub repository.
... This follows from the discussion we had on the mailing-list.
... The consensus there was that the WG should have a new repository for the TV Control API spec to keep it separate from the CG.

<cpn> https://github.com/w3c/tvcontrol-api

Chris: with a note in the CG repo to redirect users towards the WG.
... Please check the new repository.
... I started to record some issues on the specification, the first one being on the need to write an introduction.
... I think we should do that before we go to FPWD.
... Anyone interested to provide text for that should feel free to draft a pull request.
... A comment which was made last time by Youngsun was that the spec needs a much wider review.
... Please everyone take time to review the specification.
... Does it need your needs? Any missing functionality?
... I'd like to build a list of things we feel need to change, or to be added.
... And then we can decide on which of them need to be addressed before publication of the FPWD, and which can be deferred until later on.
... In the CG, there was some feedback from Sangwhan from Opera about the spec, e.g. control of non-TV input sources (e.g. HDMI inputs).
... This is something that I don't think that we discussed in depth.
... Any particular view as to whether this should be included?

Alex: Andreas already had an extensive look at the spec and we made a prototype application in an Android application that contains the necessary code to attach a DVB-T tuner.
... The only difference to the actual implementation right now is that there is no TV MediaStream.
... The feedback from Andreas is that it's quite fine. It addresses our needs.
... Some clarifications on the notion of channel and source might be warranted.
... One question on radio use cases.
... How can we proceed with that?
... Main difference is the EPG metadata of DAB is quite different from TV one.

Igarashi: I remember some discussions about HDMI and radio use cases. Looking at the charter, video is of course in scope. Regarding sources and audio, additional specifications may be considered.
... So it's in scope of the Working Group.

Chris: I agree.
... What I'd like to do is to identify the nature of the changes that you'd like to make to the specification to include this thing.

Alex: The radio use case, most of it, could be added as a new type of tuner.
... Which would deliver audio-only streams. It should pretty straightforward.
... The main question is around handling of the metadata.

Chris: Do you have anything written down already?

Alex: Yes, I can share what we did in RadioWEB and we can start from there.
... It contains a list of use cases.

Chris: That's a very good point. I'd like to gather radio use cases in the Wiki.

-> https://www.w3.org/wiki/TV_Control TV Control WG wiki

<kaz> CG wiki

Chris: I'll work with Francois to structure the WG wiki and we'll create a page that can then be populated.

Alex: Excellent. I'll link our RadioWeb spec from there as well.

Chris: On the subject of radio, what I should mention is that there is radio-based work going on in the Automotive Business Group.

<kaz> IVI radio use wiki

Kaz: I just pasted the URL of the Genevi radio use cases.
... IVI stands for In-Vehicle Information.
... Ryan Davis, not here today, has been working on this.
... As Alex mentioned, IRT and other broadcasters interested in radio and TV side are welcome to exchange with the Automotive Business Group.

Chris: What's the best way for us to proceed to explore the commonalities?

Kaz: Ryan is quite busy at this moment. It may difficult for him to join this call regularly.

<scribe> ACTION: Chris to update the TV Control WG wiki to collect use cases [recorded in http://www.w3.org/2016/05/31-tvapi-minutes.html#action01]

<scribe> ACTION: Alex to provide radio use cases in the Wiki page, once created [recorded in http://www.w3.org/2016/05/31-tvapi-minutes.html#action02]

<scribe> ACTION: Kaz to handle liaison with Automotive Business Group regarding radio use cases [recorded in http://www.w3.org/2016/05/31-tvapi-minutes.html#action03]

Chris: I guess my question to the group is, now that we have more activity regarding radio use cases, how does that affect our work towards publication as FPWD?
... Should we address this before publication, or can this wait until after publication?
... The charter says that FPWD is due Q2 2016.

Kaz: FPWD is just a draft, it can be published at any time.

Francois: Right, it triggers a call for exclusion, so it's good to get the scope right, but discussion here suggests that the API won't change much (on top of metadata-related properties)

<igarashi> +q

Youngsun: Our development team are reviewing the spec, but they still need some time, probably a couple of weeks.
... Before publication as FPWD, I'd like to give them some time to review the spec.

Chris: OK, so maybe we could set a deadline for next call in four weeks.

Igarashi: I do not understand the problem around EPG. Is that about radio EPG or TV EPG?

Alex: I'm talking about radio EPG. The radio EPG currently has some structure that is not supported by DVB EPG.
... For instance, there is a second level, offline content, etc.
... It supports much more features than a regular DVB EPG.
... The main issue is whether we can make the EPG metadata exposed by the spec flexible enough.

Igarashi: Right, my concern about the EPG is that it's really messy.
... Each one supporting their own metadata.

<kaz> HTML version of the github draft

Igarashi: In case of radio, is it possible to get some common vocabulary? The best we can do is probably to define a minimal set of metadata and let people extend it.

Alex: Yes, that sounds like a very good approach.
... Maybe it's much easier for developers to have a simple API to access basic metadata and leave it up to developers to access more extended metadata.
... I'm not pushing for a particular solution, just pointing out that we'll need to get it more thoughts to include radio use cases.

<cpn> http://blog.schema.org/2013/12/schemaorg-for-tv-and-radio-markup.html

Chris: At this point, I think I should point out the work done at schema.org to define a vocabulary for TV/radio programs.
... It would be interesting to see whether that mapping could work for us.

Igarashi: does schema.org also cover radio metadata?

<cpn> https://schema.org/RadioEpisode

Alex: If it tries to align stuff with existing vocabularies, it probably covers some of what I need.

Chris: There are specific classes about radio. Alex, that would be useful if you can take a look.
... and see how useful it could be for us.

Alex: OK, I'll have a look.

Chris: All of this reminds me that we still have the editor's position that is open.
... Anyone interested would be very welcome to do so. It's an important role. Without an editor, we would struggle to keep the momentum and update the specification.

Francois: Should I setup the notification tool so that the mailing-list gets notified when activity happens on the GitHub repository?

Chris: Yes, I think that is a good idea.
... Otherwise people would have to subscribe to the GitHub repository.

JS API vs. network resource approach

Chris: There's been some discussion on the mailing-list regarding the TAG feedback.
... I wonder, at what stage of the process should we invite a review from the TAG?

<igarashi> +q

Francois: Since they already reviewed our work, I would just wait until publication as FPWD.
... On the topic itself, my takeaway is that there is no "best solution", there are good arguments to choose API or network-resource approach.

Chris: Yes, Colin has made some good arguments on the mailing-list on the network-resource approach.

<kaz> automotive issue

Kaz: I may have mentioned this the other day as well, but the Automotive WG has the same problem and the conclusion from the Paris F2F is that they will continue the API direction that they have already published.
... They are looking at network approach in parallel.
... The basic understanding is that there are several levels of interfaces.
... The highest application level interfaces should be JS APIs for developers.
... Some middleware developers might prefer a Websockets interface.
... That could be applied Web browser vendors, theoretically.
... Then some Web runtime vendors might want to define some lower level interface.
... JS API and middleware have use cases for developers.

Igarashi: In my understanding, the issue is whether we need an extension of the browsers or not. In case of JS API, we need support from browser vendors. In case of network interface, we can use browsers as they are and simply use WebSockets to communicate with the tuner.
... The Automotive discussion is going towards requiring an extension.

Kaz: The group has discussed the issue for about a year :) If you would like to use browsers as-is, that amounts to build a specific runtime for TV-related activities.
... There are use cases in the Automotive WG that need JS APIs.

Igarashi: I understand the conclusion, but I'm not sure Websockets are not enough in their case.

Kaz: Developers want to use JS APIs.

Igarashi: That is not a technical reason. More business reason.
... TAG will review the spec and wonder whether WebSocket approach is not enough technically.

Kaz: I don't think so.
... The thing is there is no "best solution" as Francois mentioned, so TAG is unlikely going to take a strong stance on this.
... The WG is the one who decides.

Igarashi: If we ask the TAG, we should ask for technology aspects.

Kaz: I'm not suggesting we should ignore TAG proposals :)

Francois: One thing that could be interesting is to understand how a network approach would affect the API. It does not seem easy in our case, e.g. because of the need to expose the MediaStream

<kaz> chris: +1

<kaz> kaz: +1

<Youngsun_Ryu> +1

Youngsun: Regarding this issue, I think there are pros and cons both ways.
... Not every TV device supports WebSockets for instance.

Igarashi: Our TV Control is not only about controlling a channel. The output of the tuner is also rendered in an HTML5 object. If we use a WebSocket, we also need HTTP to render the output. It's obvious that there is overhead.

Chris: I agree.

Igarashi: In case of audio/video, it may be easier to separate. Audio may not be integrated with HTML content as such.
... [comments on Automotive WG]

Kaz: That level of discussion depends on the technical architecture, so we need to talk about the technical architecture. WebSockets is not the mandated solution, it can be TCP/UDP connections. We cannot discuss which solution is better without discussion the technical architecture.

Igarashi: Yes, that we agree with.

Chris: Maybe we should add some notes on the architecture in the specification. My assumption is that all of the TV APIs are essentially part of the same runtime environment that pages are using.
... This leans on security and privacy discussions that we've raised before. Do we want to expose metadata, preferences and so on.
... That is something that we need to analyse a bit more. Maybe we need a different runtime environment, one for Web pages that you can view on the device, another for control of the tuner and rendering of its output.
... I think that is something we should do more analysis on.

<Zakim> kaz, you wanted to point out that depends on the architecture of the system

Igarashi: Is it possible to ask the TAG to review our current working draft?
... They have not reviewed the community draft, right?

Chris: No, it's up for us to invite them to review the spec when we think it's ready.

Igarashi: OK, I think they may miss the fact that we're integrating the tuner output with media elements in HTML5, as in WebRTC.

Chris: Possibly.

Igarashi: So outcome is publish FPWD, then go to the TAG and ask for feedback?

Francois: Yes, that sounds good.

<kaz> TAG minutes March 30

Chris: We're running over time now, so wrapping the call would be good.

Kaz: FYI, the TAG recognizes that they should review the TV Control API spec.

Next call

Chris: Now that the work has transitioned to the Working Group, I don't think that there's any separate work going on in the CG right now, so my suggestion is to have WG-only calls from now on.
... Is it ok with anyone?

[no objection heard]

Chris: OK, thanks very much for joining and for the discussion.
... Let's work towards publication of our FPWD.
... Please create issues on the issue tracker if you have feedback on the spec!

[Call adjourned]

Summary of Action Items

[NEW] ACTION: Alex to provide radio use cases in the Wiki page, once created [recorded in http://www.w3.org/2016/05/31-tvapi-minutes.html#action02]
[NEW] ACTION: Chris to update the TV Control WG wiki to collect use cases [recorded in http://www.w3.org/2016/05/31-tvapi-minutes.html#action01]
[NEW] ACTION: Kaz to handle liaison with Automotive Business Group regarding radio use cases [recorded in http://www.w3.org/2016/05/31-tvapi-minutes.html#action03]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/31 14:36:39 $