- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 18 Feb 2015 09:41:25 +0900
- To: "public-tvapi@w3.org" <public-tvapi@w3.org>
- Message-ID: <CAJ8iq9XvYUGaf=57nUoLWqiP2k80zG=ZSMneyrKxfGBRQyQQ=w@mail.gmail.com>
available at:
http://www.w3.org/2015/02/17-tvapi-minutes.html
also as text below.
Thanks a lot for taking these minutes, Chris!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TV Control API CG
17 Feb 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvapi/2015Feb/0000.html
See also: [3]IRC log
[3] http://www.w3.org/2015/02/17-tvapi-irc
Attendees
Present
Kaz, Paul, Chris, Bin, Daniel, Sung-Hei, Alex
Regrets
Chair
Bin
Scribe
Chris
Contents
* [4]Topics
1. [5]actions
2. [6]Progress measurement of the draft of technical
specification
* [7]Summary of Action Items
__________________________________________________________
actions
<kaz> action-22?
<trackbot> action-22 -- Daniel Davis to And kaz to add a column
to the mapping table to measure the progress of our
specification. -- due 2015-01-27 -- OPEN
<trackbot>
[8]http://www.w3.org/community/tvapi/track/actions/22
[8] http://www.w3.org/community/tvapi/track/actions/22
<kaz> close action-22
<trackbot> Closed action-22.
<cpn> Scribe: Chris
<kaz> scribenick: cpn
Progress measurement of the draft of technical specification
<ddavis>
[9]https://www.w3.org/community/tvapi/wiki/Main_Page/Requiremen
ts_Mapping -> Requirements Mapping table
[9] https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping
<Paul_Higgs> cannot hear daniel
<ddavis> :-(
Daniel: The draft API is largely the same as the Mozilla TV API
... one difference regards the tuner notifications, which were
supported in a previous version, but not in the current draft
... Under general program requirements, we have program data
detail, there's a comment saying the requirement is unclear
<Paul_Higgs> "[program.data.detail] Other detailed information
of the channel/program with TV stream. "
Bin: My understanding is this could be a general object
allowing for other information, which could be extended by the
implementation
Daniel: In terms of progress, we have some requirements
supported and some not
... Some sections are blank, such as time shifting and
recording
... Should we focus on completing the partially supported
sections first?
Bin: Who has a plan to work on the partially
supported/unsupported sections?
Paul: For the specific APIs just mentioned, should we pass our
requirements to the Media Stream recording API?
<inserted> [10]Media Capture and Streams
[10] http://www.w3.org/TR/2015/WD-mediacapture-streams-20150212/
Bin: So we should do a gap analysis on the Media Stream
Recording API to see how well it supports our requirements
Paul: The requirement for series recording implies there's a
cron-type scheduler running
Alex: This is meant to allow recording of an entire series
containing an episode. This could be done through the EPG
Paul: I think it could be done within the API or it could be at
the application-level
... the requirement implies we can give an identifier to the
system e.g., a TV-Anytime series id and have it automatically
record
Alex: I would prefer to see this at the application level
Paul: In that case we could remove the recording.series
requirement
... Could we modify the requirement, to split it between
application and system level
<inserted> scribenick: ddavis
cpn: If one of our feature goals is feature parity with OIPF
then that's where it's come from.
... If we can make it from the application layer that would be
good.
... Complete but minimal would be good in my API - we don't
need to bake all these features into the API itself.
<inserted> scribenick: cpn
Bin: I suggest asking this question on the mailing list, and
take a decision on this requirement on the next call
<scribe> ACTION: Alex to email the mailing list regarding the
recording.series requirement and proposed solutions [recorded
in
[11]http://www.w3.org/2015/02/17-tvapi-minutes.html#action01]
<trackbot> Created ACTION-23 - Email the mailing list regarding
the recording.series requirement and proposed solutions [on
Alexander Futász - due 2015-02-24].
<scribe> ACTION: Paul to look at the Media Capture and Streams
API and compare against our recording and timeshifting
requirements [recorded in
[12]http://www.w3.org/2015/02/17-tvapi-minutes.html#action02]
<trackbot> Created ACTION-24 - Look at the media capture and
streams api and compare against our recording and timeshifting
requirements [on Paul Higgs - due 2015-02-24].
<kaz> action-24 due march 10
<trackbot> Set action-24 Look at the media capture and streams
api and compare against our recording and timeshifting
requirements due date to 2015-03-10.
Paul: It may be that the time shifting requirements could be
handled by the HTML video element
... I'll just look at the recording aspect, and leave
timeshifting for now
<kaz> action-24 due april 14
<trackbot> Set action-24 Look at the media capture and streams
api and compare against our recording and timeshifting
requirements due date to 2015-04-14.
<scribe> ACTION: Chris to look at the timeshifting requirements
and the HTML video element [recorded in
[13]http://www.w3.org/2015/02/17-tvapi-minutes.html#action03]
<trackbot> Created ACTION-25 - Look at the timeshifting
requirements and the html video element [on Chris Needham - due
2015-02-24].
<kaz> action-25 due march 17
<trackbot> Set action-25 Look at the timeshifting requirements
and the html video element due date to 2015-03-17.
Bin: Regarding the emergency alert requirements, are these
supported?
Daniel: There's an isEmergency flag on the Channel object
Alex: The API doesn't cover the notification requirement we
have
Paul: The channel emergency flag likely means the user can't
tune to the channel
... There are different ways of handling alerts in different
countries
Bin: In the Mozilla case, the end user can't choose the
emergency channel, but whenever content is available there it
should be surfaced to the user
Paul: This requires a dedicated tuner, in case something
appears
Bin: So the emergency alert is only partially supported
<kaz> [14]emergency requirements
[14] http://www.w3.org/community/websignage/wiki/Web-based_Signage_Player_Emergency_Profile
Kaz: The Web Signage group has created a requirements document
on emergency use cases
Sung-Hei: This work isn't active at the moment. For major
emergencies we would use the whole signage system
<Paul_Higgs> in the US:
[15]https://www.fema.gov/emergency-alert-system
[15] https://www.fema.gov/emergency-alert-system
Bin: We should revise the specification
<scribe> ACTION: Bin to contact Sean and add emergency alert
requirements to the spec [recorded in
[16]http://www.w3.org/2015/02/17-tvapi-minutes.html#action04]
<trackbot> Created ACTION-26 - Contact sean and add emergency
alert requirements to the spec [on Bin Hu - due 2015-02-24].
Kaz: We should also consider if we need a server push
mechanism, because in that case we need to think about security
as well
Bin: The Web Apps group has defined a server push API
<ddavis> [17]http://www.w3.org/TR/push-api/ -> Push API
[17] http://www.w3.org/TR/push-api/
Paul: We'll need to see whether an IP based emergency
notification is permitted
Bin: I think the focus for us is to surface the notifications
from the platform. We're not defining the entire alerting
platform here
... Each country has its own regulations for emergency systems
Paul: So we define how to surface the notifications to the
application layer, but not specify how even should be handled
at that level
Bin: Yes, i agree
... Next requirement to look at is the Conditional Access
System
Daniel: This is unsupported at present. Should we leave these
and come back to them later?
Bin: If we don't have anyone to work on these, they can be
left, possibly for a future revision of the API
<kaz> ACTION: bin to work on triggered interactive overlay
requirements [recorded in
[18]http://www.w3.org/2015/02/17-tvapi-minutes.html#action05]
<trackbot> Created ACTION-27 - Work on triggered interactive
overlay requirements [on Bin Hu - due 2015-02-24].
Bin: We should aim to complete the API requirements by June.
Then we can decide whether to defer anything remaining to a
future revision
Kaz: Is there a face to face meeting of the TV API CG planned?
Bin: I would only be able to attend if its in the Bay Area
... we could have our next meeting colocated with the next Web
and TV group meeting
Kaz: I'll let the group know when we have more details
<Paul_Higgs> sorry - have to drop off
<kaz> [ adjourned ]
Summary of Action Items
[NEW] ACTION: Alex to email the mailing list regarding the
recording.series requirement and proposed solutions [recorded
in
[19]http://www.w3.org/2015/02/17-tvapi-minutes.html#action01]
[NEW] ACTION: Bin to contact Sean and add emergency alert
requirements to the spec [recorded in
[20]http://www.w3.org/2015/02/17-tvapi-minutes.html#action04]
[NEW] ACTION: bin to work on triggered interactive overlay
requirements [recorded in
[21]http://www.w3.org/2015/02/17-tvapi-minutes.html#action05]
[NEW] ACTION: Chris to look at the timeshifting requirements
and the HTML video element [recorded in
[22]http://www.w3.org/2015/02/17-tvapi-minutes.html#action03]
[NEW] ACTION: Paul to look at the Media Capture and Streams API
and compare against our recording and timeshifting requirements
[recorded in
[23]http://www.w3.org/2015/02/17-tvapi-minutes.html#action02]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [24]scribe.perl version
1.140 ([25]CVS log)
$Date: 2015-02-18 00:35:51 $
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] http://dev.w3.org/cvsweb/2002/scribe/
--
Kaz Ashimura, W3C Staff Contact for TV, MMI, Voice, Geo, NFC and Auto
Tel: +81 3 3516 2504
Received on Wednesday, 18 February 2015 00:42:41 UTC