TV API monthly call, May 2015 -- 12 May 2015

<scribe> scribenick: ddavis

Bin_Hu: There'll be the Fraunhofer FOKUS event next week.
... There'll also be a face-to-face meeting for the Second Screen Working Group.
... Sean (editor) will be attending both and giving a presentation of the TV API there.

seanlin: Maybe I can get some more information at the event and share it over email or next conference call

Bin_Hu: Looks like you also wrote a blog post last week that summarizes the TV API: https://hacks.mozilla.org/2015/05/how-tv-functionality-leverages-web-technology/

Open action items

Bin_Hu: There were two open action items.

http://www.w3.org/community/tvapi/track/actions/open

Bin_Hu: I'd like to leave the triggered overlay action item #27 open.
... The next is action #30 - Skim the work done by the media pipeline tf and let this cg know (Kaz)

ddavis: Kaz is currently travelling so not on the call.
... There's also a typhoon here so he might be busy!

Bin_Hu: Let's leave that item open.

Progress Measurement

skim13: I volunteered to work on Conditional Access System (CAS) requirements
... I've looked at it a bit.
... I said I would look at EME. Since because this is protection of content I thought EME could perhaps be used, but EME is not for real-time streaming so I think we need a new API to protect TV contents.
... We can use the style that's in EME in a new API but I think there's a gap between EME and CAS that we're thinking of having.
... That's what we have so far.

<aldafu> actually EME is not excluded from live streaming, it's very much a use case

skim13: Also, the requirements that we have are a bit too short to accurately protect TV programs.

Bin_Hu: So we need to leverage some features. Would you mind looking into to see if we can propose a CAS system for the API spec?

ddavis: Alex (not on the call) says streaming is a use case for EME.

skim13: I mean live streaming for TV. Broadcast streams have a different style - we want to make clear that live streaming is different from TV content.
... We think it's impossible to use EME for TV content.

Bin_Hu: It would be better to have an example of how it might be possible to use EME for TV content.

<aldafu> didn't want to cause confusion, sorry. i think that skim13 is right when he says broadcast streaming can't be done with EME. EME relies on MSE which relies on HTTP. skim13's idea to create something EME compatible for broadcast streams might be a good idea

Bin_Hu: So we have covered the progress measurement - more work is needed.
... We have work to do on time-shifting, program recording, and parental controls.

cpn: I'd like to do more on time-shifting but I'm not sure I'll have the time before the next call.
... I'd like to ask seanlin about his experience on using the Media Streams API for handling streams.
... How have you approached pause and resume for live TV?

seanlin: For time-shifting we didn't implement the current Media Streams API.
... I don't have details right now but I can check with my colleagues and get back to you.

cpn: If you could reply on the mailing list that would be great.

seanlin: As far as I know there might be some gaps in our implementation.

cpn: We still have to define an interface in our spec for time-shifting.

Bin_Hu: Thank you cpn. Can anyone else sign up for parent control or program recording?

ddavis: It might be worth send a request to the mailing list asking for volunteers.

Bin_Hu: Apart from that there are various small gaps.
... So for the next stage we work to improve the trigger proposal for Kaz and time-shifting requirements.
... Then we can work on the minor gaps in the tuner and channel sections to hopefully have a spec by the end of the year.
... kaz requested to talk about Tuner APIs for Genivi.
... kaz requested to talk about Tuner APIs for Genivi.

kaz: I attended the automotive group meeting three weeks ago in Germany.
... They were very interested in this work.
... Francois (tidoust) mentioned the work that's being done and the automotive people wanted to share ideas.
... We could add a column to the requirements table to give ideas from this group's viewpoint.

Bin_Hu: I think it's OK to add that to the gap analysis table, if we can find a volunteer to fill it in.
... Kaz, can you take that action?

kaz: Yes, I can do that.

<scribe> ACTION: kaz to add column to gap analysis/requirements table for Genivi ideas [recorded in http://www.w3.org/2015/05/12-tvapi-minutes.html#action01]

<trackbot> Created ACTION-32 - Add column to gap analysis/requirements table for genivi ideas [on Kazuyuki Ashimura - due 2015-05-19].

kaz: And if automotive group participants want to join this group they are free to do that.

Any other business

<kaz> requirements mapping table

Bin_Hu: Any other business from anyone?

Paul_Higgs: What will we do if we don't have coverage in these other areas?

Bin_Hu: That would mean there's not sufficient interest so wouldn't make it into the spec, or at least dropped from the 1st version.
... Maybe in a future version they could be added if there's enough interest.

Paul_Higgs: The spec we've written is as much as we can do based on the initial scope.
... It feels like some of it are gaps in other specs, where things are lacking.
... Are you saying participants in this groups should work in other groups to fill those gaps in other specs?

Bin_Hu: It's challenging to try to convince other groups to revise their specification to cover the TV part.
... At the same time, it's worth trying to do that and we'll see if anybody is willing to do it either way.
... Either with an API that's compatible but made by a separate group, or made here.
... For example with the EME issue earlier where we may need to modify EME to work with TV content.
... I don't know how much time we can spend on improving that in a short time period.

Paul_Higgs: I was trying to think how I'd tackle it. One way is for us to write our own patches on top of e.g. File API, EME, Media Stream API.
... The other approach is why don't we just define what we need?
... The video object is extensible so we could create e.g. a Broadcast Media Extension.
... That would cover the middle ground.
... We seem to be creating a lightweight API that's bridging other W3C specs, which is fine.
... But maybe we should build something with more logic in it.

Bin_Hu: I think that's what we're doing now. This spec is a kind of extension of the functions we want to support.
... This is the plan e.g. for the CAS requirements, based on EME but extending it to be our own API to support CAS.

Paul_Higgs: That would probably work for content scrambling.
... But I was also thinking about time-shifting and other things.

Bin_Hu: Right now there are three major gaps - program recording, time-shifting, and parental controls.
... cpn has just volunteered to look into time-shifting. You are welcome to look into that with him.
... Also, you can look into other gaps if you're interested.
... There are also minor gaps in the tuner and channel requirements.
... It depends on your personal interested.

Paul_Higgs: OK. There might be more than one way to get this job done.

Bin_Hu: The most important thing is to have a spec that either extends an existing spec or adds a new spec with new functionality, but either way we need to have a spec that supports these features.

Paul_Higgs: I think parental controls feels closer to the CA system. Maybe there could be some way of injecting parental ratings as that's happening.
... Whereas time-shifting and program recording are more on the playback side.
... I'll try to give some more thought into how we can do this.
... Maybe we just want to have recording functionality locally, not in the cloud. I'll have to think about it.

Bin_Hu: Thanks - we'll consider that an unofficial action item at the moment.
... If you have more bandwidth I'd also suggest giving suggestions to skim13 or cpn about the specs.

skim13: OK for me. I think broadcast engineers are more focussed on CAS than DRM.
... I wasn't sure if they could help me with that but I'll ask their thoughts and ideas.
... And for other external standards, how they've done this and if we can use their ideas in our APIs.

Bin_Hu: So at least we have high-level assignments of work. Let's see how we've progressed at the next meeting.
... Any other business?
... Thank you everybody for your time and dedication.

ddavis: We'll have to move to Webex so I'll let you know about the details for this.

Bin_Hu: Thank you.

Meeting adjourned.

s/summarizes the TV API/summarizes the TV API: https:\/\/hacks.mozilla.org\/2015\/05\/how-tv-functionality-leverages-web-technology\//

- DRAFT -

TV API monthly call, May 2015

12 May 2015

Attendees

Contents

Open action items

Progress Measurement

Any other business

Summary of Action Items

Scribe.perl diagnostic output