See also: IRC log
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.
-> 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.
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.
-> 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.
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
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.
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!