RE: [tvapi] minutes - 14 April 2015

Comments not raised during the call…

To..

   <tidoust> [I note that there is more than just the “how to

   record” issue here, there is also the possibility to record

   streams in the background (and schedule recordings) which

   cannot be done either for the time being]

This is probably true of any “background application” and something that the Task Scheduler API [1] should address (it even states “A scheduled task must actively wake the system if the scheduled time is reached while sleeping.” as a requirement). In a TV environment, I don’t know what would happen if the App that initiated the timed event is not running at the scheduled event time





[1] http://www.w3.org/2012/sysapps/web-alarms/


Paul


From: Kazuyuki Ashimura [mailto:ashimura@w3.org]
Sent: Tuesday, April 14, 2015 1:06 PM
To: public-tvapi@w3.org
Subject: [tvapi] minutes - 14 April 2015

available at:
 http://www.w3.org/2015/04/14-tvapi-minutes.html


also as text below.

Thanks a lot for taking these notes, Chris and Francois!

Kazuyuki

---

   [1]W3C



      [1] http://www.w3.org/




                               - DRAFT -



             TV Control API Community Group Teleconference



14 Apr 2015



   [2]Agenda



      [2] https://lists.w3.org/Archives/Public/public-tvapi/2015Apr/0010.html




   See also: [3]IRC log



      [3] http://www.w3.org/2015/04/14-tvapi-irc




Attendees



   Present

          kaz, cpn, skim13, Bin_Hu, seanlin, tidoust, Paul_Higgs,

          nigel, Alex, AndreasBosl



   Regrets

   Chair

          Bin



   Scribe

          Chris



Contents



     * [4]Topics

         1. [5]Requirements & Action items

         2. [6]AOB

     * [7]Summary of Action Items

     __________________________________________________________



Requirements & Action items



   Paul: the item is can we use the media capture API for

   recording, but we think it's currently unlikely

   ... one of the authors is from Ericsson, we've discussed it

   internally

   ... the API wasn't really designed for that kind of recording,

   i.e., long durations of media content

   ... we could possibly use the File API, which is doing the

   recording

   ... there doesn't seem to be a way to append to an exsting

   file, so we may end up with lots of individual snippets

   recorded



   Bin: so we may have to define our own mechanism for this, is

   that right?



   Paul: the spec as written today wouldn't enable us to write an

   app that does background recording of programmes

   ... if someone can show how to do it with these APIs, as an

   example, that would be helpful



   Chris: the timeshifting requirement has similar problems, the

   existing APIs don't do what we need



   Alex: but capture from a webcam is quite different to from a TV

   tuner



   Paul: The existing / current TV API spec uses the MediaStream

   from WebRTC, which doesn't meet our needs



   Bin: We should update the requirements mapping table to update

   what we've found



   <tidoust> [I note that there is more than just the "how to

   record" issue here, there is also the possibility to record

   streams in the background (and schedule recordings) which

   cannot be done either for the time being]



   Paul: It should say 'not supported', but there it could with

   alterations to the other APis we've mentioned



   Bin: so we can close action 24



   <tidoust> ACTION-24?



   <trackbot> ACTION-24 -- Paul Higgs to Look at the media capture

   and streams api and compare against our recording and

   timeshifting requirements -- due 2015-04-14 -- OPEN



   <trackbot>

   [8]http://www.w3.org/community/tvapi/track/actions/24




      [8] http://www.w3.org/community/tvapi/track/actions/24



   <tidoust> close ACTION-24



   <trackbot> Closed ACTION-24.



   <inserted> scribenick: tidoust



   Chris: Similar story with the timeshifting, because the output

   of the tuner uses a MediaStream which essentially prevents any

   sort of buffering for the time being. It is a realtime stream,

   which makes sense in WebRTC scenarios. So, no change of

   playbackrate, no timeshifting.

   ... It seems to be a case where we would need to implement our

   own interface.

   ... The use of existing capabilities from MediaElements would

   be good. It's the underlying state machine that is different.

   In the OIPF specification, there is quite of a different model

   there.

   ... That's really as far as I got. I haven't done any work on

   how the API might need to look like. If we want to support this

   requirement and have playback that can support this

   timeshifting, then we would need to define our own interface

   and see how it integrates with MediaElements and the rest.



   <inserted> scribenick: cpn



   Paul: I agree, i don't see how we can use the existing APIs for

   a TV-like experience



   <paul_higgs> We need to define some type of media pipelining

   model then APIs around managing that



   Bin: So we should put more time into looking at this



   Paul: It's a substantial topic, but yes



   Chris: I'm interested to do more on this, but I think

   implementation experience would be valuable



   Paul: I wonder if someone could look at the IPTV Forum Japan

   spec, but their spec may be more browser-aligned, is there

   something we can learn from it?



   Kaz: I agree



   <kaz> [9]media pipeline tf discussion



      [9] http://www.w3.org/2011/webtv/wiki/MPTF




   Kaz: Also there was previous discussion in the media pipleline

   task force we could review

   ... and we can talk to people from the IPTV forum Japan



   Bin: what's the status of that task force?



   Kaz: It's closed, but we can look at their previous discussions

   and documents



   Paul: By pipeline I was meaning something gstreamer-like, not

   necessarily this TF



   <kaz> ACTION: kaz to skim the work done by the media pipeline

   tf and let this cg know [recorded in

   [10]http://www.w3.org/2015/04/14-tvapi-minutes.html#action01]



   <trackbot> Created ACTION-30 - Skim the work done by the media

   pipeline tf and let this cg know [on Kazuyuki Ashimura - due

   2015-04-21].



   Bin: I updated the wiki for action 25, to say its not

   supporting, the same as for programme recording



   close action-25



   <trackbot> Closed action-25.



   Bin: Re action 26, there has been discussion between Sean and

   Paul about emergency notifications



   Sean: we've added a new 'type' attribute to reflect the nature

   of the emergency, e.g., earthquake

   ... and also region information, if broadcasters can supply

   this information, allows the client to do further filtering



   Paul: This update makes the spec more in line with how it

   should work outside of Japan, eg, in North America it's now

   closer



   Bin: So, is the emergency notifications part of the spec is now

   stable?



   Paul: I think we're close, but should check the requirements

   ... I've just checked the requirements - they're are generic

   enough that they are supported now by the TV control API



   close action-26



   <trackbot> Closed action-26.



   Bin: Re action 27, triggered interactive overlay requirements



   Sean: We have extended the TextTrackCue and added our own

   trigger type

   ... we have a generic object there now

   ... Looking at the requirements, we now have minimum support

   for those items



   Bin: so let's leave this action open, until we get more example

   data objects

   ... Re action 28, for Daniel, sharing the results of the Japan

   meeting



   Kaz: Daniel added a note on the wiki, Yosuke is writing up a

   detailed report of the meet-up, which we can share with the

   group

   ... It should be ready soon, I'll ask him to share it with the

   group



   close action-28



   <trackbot> Closed action-28.



   Bin: action 29 is similar to 25, we've covered that



   close action-29



   <trackbot> Closed action-29.



   <scribe> ACTION: Kaz to ask Yosuke to share the meet-up report

   with the group [recorded in

   [11]http://www.w3.org/2015/04/14-tvapi-minutes.html#action02]



   <trackbot> Created ACTION-31 - Ask yosuke to share the meet-up

   report with the group [on Kazuyuki Ashimura - due 2015-04-21].



   Bin: We've made some good progress

   ... There are still some gaps in our requirements, where

   capabilities are not supported

   ... such as: recording, time shifting, conditional access,

   parental control

   ... Can anyone look into the conditional access and parental

   control requirements?

   ... no takers... so I'll invite all to think about these, and

   hopefully someone will be able to work on these gaps



AOB



   Paul: There spec has an EIT information event, defined only as

   an object. What properties would this have, e.g., title, start

   time?



   Alex: This is the TVEITBroadcastedEvent, which has a programs

   attribute

   ... This is the schedule of future programmes



   Paul: What fields does each object in the list have?



   Alex: So we should introduce a Program object with known

   properties



   close action-31



   <trackbot> Closed action-31.



   Paul: So this is an object that needs to be cast to a sequence

   of programmes



   Bin: Thanks everybody, speak again in 4 weeks



   <kaz> [ adjourned ]



Summary of Action Items



   [DONE] ACTION: Kaz to ask Yosuke to share the meet-up report

   with the group [recorded in

   [12]http://www.w3.org/2015/04/14-tvapi-minutes.html#action02]

   [NEW] ACTION: kaz to skim the work done by the media pipeline

   tf and let this cg know [recorded in

   [13]http://www.w3.org/2015/04/14-tvapi-minutes.html#action01]



   [End of minutes]

     __________________________________________________________





    Minutes formatted by David Booth's [14]scribe.perl version

    1.140 ([15]CVS log)

    $Date: 2015/04/14 14:28:15 $



     [14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


     [15] http://dev.w3.org/cvsweb/2002/scribe/


--
Kaz Ashimura, W3C Staff Contact for Auto, TV, MMI, Voice, Geo and NFC
Tel: +81 3 3516 2504

Received on Tuesday, 14 April 2015 18:56:55 UTC