- From: Francois Daoust <fd@w3.org>
- Date: Tue, 15 Nov 2016 17:07:15 +0100
- To: <public-tvcontrol@w3.org>
Hi all,
The minutes of today's call are available at:
https://www.w3.org/2016/11/15-tvapi-minutes.html
... and copied as raw text below.
Thanks,
Francois.
----
TV Control WG call
15 Nov 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Nov/0028.html
See also: [3]IRC log
[3] http://www.w3.org/2016/11/15-tvapi-irc
Attendees
Present
Francois, Ryan_Davis, Kazuyuki_Ashimura, Chris_Needham
Regrets
Jean-Pierre_Evain
Chair
Chris
Scribe
Francois
Contents
* [4]Topics
1. [5]Conference call schedule
2. [6]Summary of TAG review feedback
3. [7]Source-centric API model
4. [8]Application types
5. [9]Radio API changes
6. [10]Switch to WebIDL contiguous mode
__________________________________________________________
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
-> [11]TAG issues
[11] https://github.com/w3c/tvcontrol-api/issues?q=is:issue+is:open+label:TAG
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.
-> [12]Application Types
[12] https://www.w3.org/wiki/TV_Control/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
-> [13]https://github.com/w3c/tvcontrol-api/issues/4 Issue 4
[13] https://github.com/w3c/tvcontrol-api/issues/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.
-> [14]Device capabilities use case
[14] https://www.w3.org/wiki/TV_Control/Use_Cases#Device_capabilities
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
-> [15]Application types
[15] https://www.w3.org/wiki/TV_Control/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 [16]scribe.perl version
1.148 ([17]CVS log)
$Date: 2016/11/15 16:03:37 $
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 15 November 2016 16:07:28 UTC