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> 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> media pipeline tf discussion

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