W3C home > Mailing lists > Public > public-tvapi@w3.org > April 2015

RE: [tvapi] minutes - 14 April 2015

From: Paul Higgs <paul.higgs@ericsson.com>
Date: Tue, 14 Apr 2015 18:56:18 +0000
To: Kazuyuki Ashimura <ashimura@w3.org>, "public-tvapi@w3.org" <public-tvapi@w3.org>
Message-ID: <9681F60D17697C41A146FC70CD4B48D61E0FF3BD@eusaamb103.ericsson.se>
Comments not raised during the call…


   <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/


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:

also as text below.

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




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

                               - DRAFT -

             TV Control API Community Group Teleconference

14 Apr 2015


      [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



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

          nigel, Alex, AndreasBosl







     * [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


   ... 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


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

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


   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


   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



      [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


   ... 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


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

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


   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


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


   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


   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


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


   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


   <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


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

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


   Alex: This is the TVEITBroadcastedEvent, which has a programs


   ... 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


   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


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

   tf and let this cg know [recorded in


   [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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:45:14 UTC