- From: Francois Daoust <fd@w3.org>
- Date: Tue, 13 Dec 2016 16:59:32 +0100
- To: <public-tvcontrol@w3.org>
Hello TV Control WG,
The minutes of today's meeting are available at:
http://www.w3.org/2016/12/13-tvapi-minutes.html
... and copied as raw text below.
Topics that were discussed:
- WG rechartering: idea is to get a new charter ready by end of January 2017
- Liaison letters: we'll send the letter Chris prepared to ATSC. Chris will draft letters for DVB and HbbTV as well. Alex will reach out to RadioDNS.
- Source centric API model: more discussions on the design. Ryan shared thoughts on a "player" centric approach. Francois will send the email he prepared to getUserMedia folks to initiate discussions with them.
- Mapping issues: Michael wondered about the status of these issues. They are very valuable and need to be addressed once architectural issues have been fixed. Idea is to collect mappings in a Wiki page. How and where to specify these mappings afterwards depends on available resources to work on it.
Thanks,
Francois.
-----
TV Control WG Call
13 Dec 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0026.html
See also: [3]IRC log
[3] http://www.w3.org/2016/12/13-tvapi-irc
Attendees
Present
Francois_Daoust, Chris_Needham, Alexander_Erk,
Ryan_Davis, Tatsuya_Igarashi, Kazuyuki_Ashimura,
Steve_Morris, Michael_Probst
Chair
Chris
Scribe
Francois, Chris, Kaz
Contents
* [4]Topics
1. [5]Rechartering
2. [6]Liaison letters
3. [7]Source-centric API model and getUserMedia
4. [8]Mapping issues
* [9]Summary of Action Items
__________________________________________________________
Chris: [reviewing [10]agenda]
[10] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0026.html
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 [11]existing charter and review
time scale and milestones in particular.
[11] http://www.w3.org/2016/03/tvcontrol.html
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>
[12]https://lists.w3.org/Archives/Public/public-tvcontrol/2016D
ec/0028.html
[12] 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
[13]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 [14]thoughts on the source centric
design
[14] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0010.html
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:
[15]https://wicg.github.io/mediasession/ ]
[15] 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:
[16]https://github.com/w3c/tvcontrol-api/issues/36
[16] 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 [17]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.
[17] https://www.w3.org/wiki/TV_Control/Protocol_Mappings
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]
Summary of Action Items
[NEW] ACTION: Chris to propose liaison letters for DVB and
HbbTV. [recorded in
[18]http://www.w3.org/2016/12/13-tvapi-minutes.html#action01]
[End of minutes]
Received on Tuesday, 13 December 2016 15:59:46 UTC