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