W3C

TV Control WG call

15 Nov 2016

Agenda

See also: IRC log

Attendees

Present
Francois, Ryan_Davis, Kazuyuki_Ashimura, Chris_Needham
Regrets
Jean-Pierre_Evain
Chair
Chris
Scribe
Francois

Contents


Conference call schedule

Chris: Looking at milestones, we are due to be in CR phase by the end of our charter, end of March 2017, but we're far from it.
... One question we discussed with Francois was the possibility to have more regular calls as we seem to be making more progress during calls.
... Now it's interesting to note that we have had good discussions on our GitHub issue tracker recently.

Steve: If we increase the frequency of calls, would the people join the call?

Chris: True. So I think that, since we're having good discussions on the mailing-list, let's continue like this.

Steve: I agree.

Chris: OK, let's keep the same schedule. I'll contact some group participants offline.

Summary of TAG review feedback

-> TAG issues

Chris: There's some really good feedback here. There are things that we had already identified such as the need to protect parental controls.
... Also more advanced features and whether they should be exposed to Web applications.

-> Application Types

Chris: Francois created a table on the Wiki to discuss whether features need to be exposed to regular Web applications
... What would be useful is for some wider review of this table in the group.
... We can then transpose that information into the specification, either by restricting the list of features it addresses or by creating additional conformance classes.
... Interestingly, the TAG has suggested that we look at a more unified approach to media streams.
... That's issue #22.
... I started to collect links together to other groups and specs.
... I haven't been looking at specs outside of W3C.
... Anything that should be added to the list?
... e.g. work from the Automotive group?

Ryan: I think I need to step up and do a bit better at commenting on the GitHub issue tracker.
... I will add some things in here for discussion.

Kaz: The new Automotive WG charter discussion is ongoing. First deliverable is low-level WebSockets-based specification.
... The second deliverable is a higher-level JS API.
... I think TV Control API fits the higher-level JS API. Also that implies the low-level WebSockets-based interface should also handle media-related information at some point.

Chris: Thinking about other usage of MediaStream, are there other places that I failed to capture?

Francois: MediaStream Recording, raised in another issue, would fit in the list.

Chris: I do not think that we need to go through the feedback in details at this stage. The comment on the REST API needs further thoughts.

Source-centric API model

-> https://github.com/w3c/tvcontrol-api/issues/4 Issue 4

Chris: Follows discussions we had at and since TPAC.
... I'd like group agreement that this is the right direction to pursue.
... One of the comments was on device capabilities, some indication for an application to tell whether it will be able to get what it wants.

-> Device capabilities use case

Chris: I started to write down a brief use case description (perhaps too broad), and derive technical requirements.
... The API must allow apps to obtain information about the number of streams and the quality level. And from there the API must allow apps to specify criteria for the stream.

Steve: I think that captures the problem correctly. In practice, different qualities for the same channel are often done through separate channels.
... How many more HD streams can I decode? How many more SD streams can I decode? Can I decode another HD channel?
... Now, for recording, can I "decode" may not be that relevant, can I "receive" would be better, so we may want to be a bit more careful.

Chris: What I'd like to do is to go back to Igarashi-san to check whether requirements are OK with him.

Francois: 2 points comparing with getUserMedia. 1) criteria may be what the app wants to "require" or "wish for but ok to have a fallback". 2) getUserMedia talks more in terms of width/height/ratio than SD/HD/UHD.

[Some discussions on channel characterics that may change over time, such as a channel that switches to HD, which seems possible in radio at least]

Ryan: How would an app know how to use a tuning knob?
... It may be more for radio, as stations change more frequently.

Steve: Tuning parameters could be one way to tune to a channel. Happens on TV as well.
... The capabilities of a tuner, or a source, is that a separate interface that hangs out of the TVSource interface.

Ryan: I think so.

Steve: Some properties will be valid for some source types, but not others.

Chris: At the moment, you do a separate channel scan and that gives you the channel list.
... For FM radio, you typically have a dial that you can use to go through frequencies. Is that what you have in mind?

Ryan: Yes.
... I think that scan would still be useful. Now, if the user knows where she want to go, tuning to it directly may be preferable not to have to wait for the scanning to complete.

Chris: Right now, the API does not allow an app to augment the list of channels and programs. Is that a desirable capability, perhaps?

Ryan: I think that there are 3 issues: 1/ the possibility to let the app specify tune parameters, 2/ the possibility to let the app create a channel, 3/ adding that to the persistent list that the user sees. Between step 2 and step 3, you can introduce a lot of complexity (reorder channels, hide channels, etc.)
... If we want a web app to permanently affect the list, it's not the same thing as just extending the list for the lifetime of the session.
... Shouldn't a station automatically get added to the list when the user tunes to it and the user agent detects a station?

Steve: The issue exists in TV because there are multiple ways to signal channels. There may be duplicate information and sometimes (example of "switch digital videos") a set of reserved channels may be dynamically allocated although not signaled anywhere.
... The device may fallback on different ways of doing channel scans, depending e.g. on operator settings.

Ryan: Then do we need the list? You mentioned the ability to "tune" to a frequency.

Steve: I would indeed overload "setChannel" with a variant that takes tuning parameters.

Chris: Are there broadcast systems other than FM where this is needed?

Ryan: Yes, AM, FM, DAB, etc.

Francois: So, in that model, a channel is basically just equivalent to a set of tuning parameters and these tuning parameters are used to "constrain" the MediaStream that you get from the source (similar to the TAG comment)

Steve: Yes, to some extent, but there are more complex cases.

Chris: It seems to me that we should capture that in a new GitHub issue.
... One of the concerns I have is around the level of abstraction that we have in the API.
... So far, we have not been exposing too much broadcast-specific information to the application.
... Adding this kind of information does that.
... I do not know whether that is a problem.
... Just more an observation for the time being that we're lowering the level of abstraction that we have.

Steve: I agree with you. I think it's going to be the case that different applications will want to work at different levels of abstraction.
... It probably applies more in the radio world because of the "tuning dial", whereas you don't necessarily have that in the TV world. I do see value in the TV world as well, though.

Ryan: It really exposes the constraints of the source. It makes it more efficient for the web application to choose the right channel. It can still be generic, but it will have to be exposed at some point.

Chris: OK, I'll capture that as an issue and then if you can comment on this, Ryan, that would be great.

Steve: I have a few thoughts in that direction as well.

Chris: Before we move on to the next topic, I'm personally happy with the direction. I'll try to get feedback from people who are not on the call today.
... And then we can continue to look more into the details of the specification.

Application types

-> Application types

Chris: I mentioned the table earlier in this call.
... Some of this has been completed already.

Steve: I put initial thoughts here, but that's certainly not complete.

Chris: Right, we probably don't have time to go into details here but it would be good to do that.
... Schedule recording? Enumerate CI cards? Should these features simply not be exposed to regular web applications? Under permission?
... The main work at the moment is to complete this source-centric design.

Francois: Interestingly, the first row "enumerate tuners" may not mean much in the end given the discussions we've had so far on GitHub around the source-centric re-design.

Chris: Yes, I think that would be enumerating device capabilities

Radio API changes

Chris: Eventually, I had a look at radio changes that Alex initially proposed.
... That led me to look into TextTrack and DataCue mechanisms in HTML.
... That's issue #29
... For dynamic labels, we can expose a TextTrack that contains the dynamic labels. I think the TextTrack has a kind attribute that seems relevant.
... We could add a new kind to the existing list.
... And then there's the question on how we expose images. Through a DataCue? A more specific interface?
... There is some discussion I linked to where Ian Hickson recommends to use a specific interface when you know the type of data instead of exposing that data as a blob or TypedArray.
... More work is needed.
... Do we still need to include information about the "Data component" or application attached to the TVChannel interface?
... My current thought is that maybe you don't need that if things are exposed through TextTracks.

Steve: I'd agree with that. At the moment, the TVChannel interface describes static data, whereas the Application interface is not going to be. It would be misleading to put it there.

Switch to WebIDL contiguous mode

Chris: Francois prepared a PR. Is it ready to be merged?

Francois: Yes, that step is mandatory no matter what. The comment in the PR can be addressed afterwards. It all depends on what our fantastic editor would like to structure the document in the end :)

Steve: Fine with the current structure

Chris: OK, let's merge that

Steve: Will do, probably tomorrow.

Chris: Thank you everybody for your contributions, talk to you in 4 weeks from now!

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/11/15 16:03:37 $