14:04:14 RRSAgent has joined #tvapi 14:04:14 logging to http://www.w3.org/2015/02/17-tvapi-irc 14:04:26 Meeting: TV Control API CG 14:06:13 zakim, this is tv 14:06:20 Zakim has joined #tvapi 14:06:21 zakim, this is tv 14:06:21 kaz, WEBT_TVAPICG()9:00AM is already associated with an irc channel; use 'move tv to here' if you mean to reassociate the channel 14:06:30 whyun has joined #tvapi 14:06:31 zakim, move tv to here 14:06:32 ok, kaz; that matches WEBT_TVAPICG()9:00AM 14:06:32 +[IPcaller] 14:06:42 zakim, IPcaller is skim13 14:06:42 +skim13; got it 14:07:16 ddavis has joined #tvapi 14:07:16 skim13 has joined #tvapi 14:07:30 zakim, who is here? 14:07:30 On the phone I see Kazuyuki, Paul_Higgs, Chris, Bin_Hu, ddavis (muted), skim13 14:07:32 On IRC I see skim13, ddavis, whyun, Zakim, RRSAgent, kaz, cpn, Bin_Hu, Paul_Higgs, jcverdie, ted, trackbot 14:08:17 Present: Kaz, Paul, Chris, Bin, Daniel, Sung-Hei 14:09:05 agenda: https://lists.w3.org/Archives/Public/public-tvapi/2015Feb/0000.html 14:09:11 topic: actions 14:09:21 action-22? 14:09:21 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 14:09:21 http://www.w3.org/community/tvapi/track/actions/22 14:09:33 close action-22 14:09:33 Closed action-22. 14:10:01 Scribe: Chris 14:10:05 scribenick: cpn 14:10:23 +??P22 14:10:41 zakim, ??P22 is alex 14:10:41 +alex; got it 14:11:09 Present+ Alex 14:11:28 aldafu has joined #tvapi 14:11:32 https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping -> Requirements Mapping table 14:11:52 zakim, unmute me 14:11:52 ddavis should no longer be muted 14:12:27 cannot hear daniel 14:12:35 :-( 14:13:14 Daniel: The draft API is largely the same as the Mozilla TV API 14:13:31 ... one difference regards the tuner notifications, which were supported in a previous version, but not in the current draft 14:13:37 i/https/Progress measurement of the draft of technical specification/ 14:13:44 rrsagent, make log public 14:13:49 rrsagent, draft minutes 14:13:49 I have made the request to generate http://www.w3.org/2015/02/17-tvapi-minutes.html kaz 14:14:19 ... Under general program requirements, we have program data detail, there's a comment saying the requirement is unclear 14:14:31 s/Progress measurement/topic: Progress measurement/ 14:14:32 rrsagent, draft minutes 14:14:32 I have made the request to generate http://www.w3.org/2015/02/17-tvapi-minutes.html kaz 14:14:37 "[program.data.detail] Other detailed information of the channel/program with TV stream. " 14:15:56 Bin: My understanding is this could be a general object allowing for other information, which could be extended by the implementation 14:16:41 Daniel: In terms of progress, we have some requirements supported and some not 14:16:51 ... Some sections are blank, such as time shifting and recording 14:17:16 ... Should we focus on completing the partially supported sections first? 14:17:57 Bin: Who has a plan to work on the partially supported/unsupported sections? 14:18:48 Paul: For the specific APIs just mentioned, should we pass our requirements to the Media Stream recording API? 14:19:53 Bin: So we should do a gap analysis on the Media Stream Recording API to see how well it supports our requirements 14:21:23 Paul: The requirement for series recording implies there's a cron-type scheduler running 14:22:11 Alex: This is meant to allow recording of an entire series containing an episode. This could be done through the EPG 14:22:33 i|So we should|-> http://www.w3.org/TR/2015/WD-mediacapture-streams-20150212/ Media Capture and Streams| 14:22:37 rrsagent, draft minutes 14:22:37 I have made the request to generate http://www.w3.org/2015/02/17-tvapi-minutes.html kaz 14:23:17 Paul: I think it could be done within the API or it could be at the application-level 14:24:05 ... the requirement implies we can give an identifier to the system e.g., a TV-Anytime series id and have it automatically record 14:24:34 Alex: I would prefer to see this at the application level 14:25:21 Paul: In that case we could remove the recording.series requirement 14:27:22 ... Could we modify the requirement, to split it between application and system level 14:28:01 cpn: If one of our feature goals is feature parity with OIPF then that's where it's come from. 14:28:14 cpn: If we can make it from the application layer that would be good. 14:28:36 cpn: Complete but minimal would be good in my API - we don't need to bake all these features into the API itself. 14:28:43 i/If one of our/scribenick: ddavis/ 14:30:20 Bin: I suggest asking this question on the mailing list, and take a decision on this requirement on the next call 14:30:46 i/I suggest/scribenick: cpn/ 14:31:14 Action: Alex to email the mailing list regarding the recording.series requirement and proposed solutions 14:31:14 Created ACTION-23 - Email the mailing list regarding the recording.series requirement and proposed solutions [on Alexander Futász - due 2015-02-24]. 14:32:57 Action: Paul to look at the Media Capture and Streams API and compare against our recording and timeshifting requirements 14:32:57 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]. 14:33:24 action-24 due march 10 14:33:24 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. 14:34:06 Paul: It may be that the time shifting requirements could be handled by the HTML video element 14:34:34 Paul: I'll just look at the recording aspect, and leave timeshifting for now 14:34:55 action-24 due april 14 14:34:55 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. 14:36:23 Action: Chris to look at the timeshifting requirements and the HTML video element 14:36:23 Created ACTION-25 - Look at the timeshifting requirements and the html video element [on Chris Needham - due 2015-02-24]. 14:36:41 action-25 due march 17 14:36:41 Set action-25 Look at the timeshifting requirements and the html video element due date to 2015-03-17. 14:37:27 Bin: Regarding the emergency alert requirements, are these supported? 14:38:10 q+ 14:38:52 Daniel: There's an isEmergency flag on the Channel object 14:39:17 Alex: This doesn't cover the notification requirement we have 14:39:43 s/This doesn't/The API doesn't/ 14:40:16 Paul: The channel emergency flag likely means the user can't tune to the channel 14:41:08 ... There are different ways of handling alerts in different countries 14:42:21 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 14:42:50 Paul: This requires a dedicated tuner, in case something appears 14:43:48 q? 14:43:58 Bin: So the emergency alert is only partially supported 14:44:36 -> http://www.w3.org/community/websignage/wiki/Web-based_Signage_Player_Emergency_Profile emergency requirements 14:44:50 Kaz: The Web Signage group has created a requirements document 14:45:13 s/document/document on emergency use cases/ 14:45:59 Sung Hi: This work isn't active at the moment. For major emergencies we would use the whole signage system 14:46:10 s/Sung Hi/Sung-Hei/ 14:46:25 in the US: https://www.fema.gov/emergency-alert-system 14:47:05 Bin: We should revise the specification 14:47:30 Action: Bin to contact Sean and add emergency alert requirements to the spec 14:47:30 Created ACTION-26 - Contact sean and add emergency alert requirements to the spec [on Bin Hu - due 2015-02-24]. 14:48:59 Kaz: We should also consider if we need a server push mechanism 14:49:11 Bin: The Web Apps group has defined a server push API 14:49:39 http://www.w3.org/TR/push-api/ -> Push API 14:49:44 s/mechanism/mechanism, because in that case we need to think about security as well/ 14:49:52 Paul: We'll need to see whether an IP based emergency notification is permitted 14:50:25 Chair: Bin 14:50:39 rrsagent, draft minutes 14:50:39 I have made the request to generate http://www.w3.org/2015/02/17-tvapi-minutes.html kaz 14:51:23 Bin: I think the focus for us is to surface the notifications from the platform. We're not defining the entire alerting platform here 14:52:02 ... Each country has its own regulations for emergency systems 14:52:44 Paul: So we define how to surface the notifications to the application layer, but not specify how even should be handled at that level 14:52:56 Bin: Yes, i agree 14:55:11 Bin: Next requirement to look at is the Conditional Access System 14:56:04 Daniel: This is unsupported at present. Should we leave these and come back to them later? 14:57:08 Bin: If we don't have anyone to work on these, they can be left, possibly for a future revision of the API 14:57:55 action: bin to work on triggered interactive overlay requirements 14:57:55 Created ACTION-27 - Work on triggered interactive overlay requirements [on Bin Hu - due 2015-02-24]. 14:58:51 q+ 14:59:39 Bin: We should aim to complete the API requirements by June. Then we can decide whether to defer anything remaining to a future revision 14:59:53 Kaz: Is there a face to face meeting of the TV API CG planned? 15:00:48 Bin: I would only be able to attend if its in the Bay Area 15:01:34 ... we could have our next meeting colocated with the next Web and TV group meeting 15:02:17 -Paul_Higgs 15:02:25 Kaz: I'll let the group know when we have more details 15:02:32 sorry - have to drop off 15:02:44 [ adjourned ] 15:02:45 -skim13 15:02:46 -alex 15:02:46 -Bin_Hu 15:02:48 skim13 has left #tvapi 15:02:48 -ddavis 15:02:49 rrsagent, dtaft minutes 15:02:49 I'm logging. I don't understand 'dtaft minutes', kaz. Try /msg RRSAgent help 15:02:55 -Kazuyuki 15:02:57 -Chris 15:02:58 WEBT_TVAPICG()9:00AM has ended 15:02:58 Attendees were Kazuyuki, Paul_Higgs, Bin_Hu, Chris, ddavis, skim13, alex 15:03:05 rrsagent, stop