Creating API to access TV level functions -- 31 Oct 2012

<jcverdie> rssagent, Meeting: Creating API to access TV level functions

<jcverdie> Meeting: Creating API to access TV level functions

<scribe> scribe: Matt

Introductions

Mark_Vickers: Mark Vickers from Comcast. I am co-chair of the Web and TV interest group.

Giles: Giles from BskyB

??: <missed>

??: From Samsung

Mark: Mark from NetFlix

Mancin: From Access

<Dewa> Yoshiharu Dewa from Sony

Sebastien Godard: From MStar Semiconductor

<CF> Christian Fuhrhop, Fraunhofer FOKUS

jcverdie: JC Verdie from MSTAR

??: From KDDI

??: from Zynga

??: From Nippon TV

Yoshi: From ??

Giueseppie: from Opera

Osamu: From Nishioka from Nippon Television

Niklas: From Erricson

??: From NHK

??: From Wowow

<Yanagiuchi> Keiji Yanagiuchi from TBS Televsion

Agenda

<Dewa> s/??:From Nippon TV/Nishioka: from Nippon Television/

jcverdie: Let's just make sure we are all here for the same thing and what our output will be.
... What's important to MSTAR is low-level access to the to the TV.

<Dewa> s/??:From NHK/Matsumura: From NHK/

jcverdie: It's also important that we define something new.

<Dewa> s/??:From Wowow/Sakai: From Wowow/

jcverdie: I've gotten a message from OIPF chair who wanted to clearly state that OIPF would be happy to contribute and collaborate with W3C on this to ensure it's widely spread.

John_Simmons: From Microsoft. Does that mean OIPF is going to implement the source media extensions on the video tag from W3C.

jcverdie: They've proposed many APIs for integrating with HTML, including switching to <video> tag.

giuseppe: We shouldn't start the discussion from the API, but the use cases.

jcverdie: Agreed.

giuseppe: From my experience there are some things that make no sense on the web, and sometimes end up with things irrelevant to web community.
... For the TF, what are the things people want to do, and look at how others are solving the problem. Since we have the Web Platform we have to see how it fits, and not force it.
... Take it from that perspective and see if that could be done from there.

Mark_Vickers: There's been a long history of extensions to HTML for television, going back to WebTV, CEA, DLNA, my own company OTA Technologies, etc. Those were all before HTML from W3C supported video, so it may be made sense then.
... None of those previous extensions had any effect on what happened in W3C. They were branches that became, IMO, dead branches. Now that there is video support in the Web, it only makes sense to do them within W3C. That's my companies position.
... We looked at <video> and saw a lot of gaps and came to w3c to solve those. There wasn't support for TV remote controls, we got it added to DOM3. There wasn't support for multiple tracks, we got that. Live TV stream switching, we got that too. It's been 100% success for us.
... If there are further gaps that you may see, the only way to go is to have those changes go through the same process. We can help in Web and TV IG, we know how to do it and can help.
... In my mind there's no need for further APIs outside of W3C anymore. Bring use cases, and we can start on them, no more dead branches.

markw: Practically, any app that is used to writing HTML 5 apps, I've looked at OIPF, etc, and I'm not going to give those to the HTML guys, they have enough to deal with with HTML.

jcverdie: What I was saying was all that OIPF told me, not necessarily my vision.

giuseppe: Some APIs have been designed with some assumptions that are not necessarily designed for what works on the Web. Thus it's important to start on the requirements.

Mark_Vickers: So far, all of the APIs we've built into HTML5 and related specs, they were general application APIs that any website might do. Key/stream access, open to any website .
... And they are safe. The other APIs I've worked on were low-level and not safe for websites. If they are low-level work with the System APIs WG.

giuseppe: There are things that we will do that are safe for the Web, but if they're system APIs they can work differently and be treated in the system APIs WG, which may have security framework around it.

jcverdie: Is there consensus that we don't want to start with what APIs have been used elsewhere, but start with use cases and requirements, and then look at the Web specs.

Mark_Vickers: The Web and TV IG works by making use cases and requirements and then links with the appropriate group.

jcverdie: As a TF in Web and TV it's in our charter to work on the requirements.

Mark_Vickers: We have the domain knowledge from working in TV to do requirements and then look at the gaps in the current APIs.

giuseppe: We've written some partial proposals, but just to spur discussion with other groups. Anyway, this all doesn't mean we are not interested in discussing with the other groups.

jcverdie: We need to talk with them, we can agree and disagree, but it's worth listening to them.

giuseppe: If you reach the same level of functionality as the other APIs, you should be able to map them back and forth.

jcverdie: Any opposition to model of defining use cases and then requirements and try to map those to existing stuff?
... 1…2….3… done.

??: In this task force we are trying to find use cases for TV devices?

jcverdie: In my mind this is open to discussion. Doesn't mean we'll go through the process for all the use cases, as I expect there will be a bunch. It'd be interesting to see if there is support for common use cases.

Guen-Hyung Kim: My concern is that there are a lot of devices like channel and volume and we make some use cases allowing for specific features using those features, after finishing those requirements, we go to the other WGs. When will we decide that this user case.

jcverdie: The most important thing is to get all the use cases needed, then prioritization knowing that the WGs won't be able to address all of our use cases.
... In your presentation Guen-Hyung, you express the need for a channel API. Do others think this is relevant?

giuseppe: The use case might be how to get video from tuner and see if it's doable with HTML5.

??: It's not clear how you hook up a traditional TV signal, and if that's not solved channel changing doesn't make sense.

Mark_Vickers: It comes down to a meta-data problem and a naming problem.
... As long as the system has a name that the user end knows then you don't have to worry about channel changing.

jcverdie: I proposed changing nothing to the video object, but to add RDF, XML or whatever to exchange that information.

giuseppe: XML doesn't seem too cool these days...

Mark_Vickers: XML is not the right answer. Nor JSON. We deal in requirements, and leave it up to the WGs.

giuseppe: It's good to document, but maybe instead of sending it to a WG put it on Web Platform as a way or something.

Mark_Vickers: It could be a URI scheme even.

jcverdie: We need to make sure the appropriate thing is sent to the browse.

giuseppe: Maybe document what people can expect and have an open discussion.

jcverdie: In addition to channel, I need basic information about services, program, rating, parental control, etc.

giuseppe: We also have a metadata TF.

giuesppe: Maybe recording

giles: Trick-play maybe?

Mark_Vickers: Trick-play is already there, but recording is not. Nor download.

HJ: Is it a live TV set, or a variety of "TVs", smart phone, tablet, etc. What is the TV concept here?
... Is it a TV receiving a signal from the air, or a notebook, or a phone, are those called TVs? They are in Web and TV IG. In these Use Cases they have traditional TV concepts like channels.

jcverdie: I think some of the use cases are not going to be specific everywhere, but we are just building the use cases for whatever you can imagine. Are you thinking of a specific use case?

giuseppe: The follow-up was a workshop that we haven't done.

John Simmons from MS: we should gather what has been said and make sure they are not lost. These things tend to auger back onto themselves.

jcverdie: Do you want to volunteer to gather the minutes on these?

John_Simmons: I think so. It's a matter of working with folks who chaired those meetings. Some folks might have better memories of these.

giuseppe: Which discussion? I don't recall this.

John_Simmons: I think there were lots of discussions on APIs.

HJ: The first workshop in Tokyo.

giuseppe: For APIs? Yes. There's been discussions in the workshops, but nothing happened after that.

matt: I think trick-play and recording are different use cases, and downloading a third.

giuseppe: We said on Thursday downloading is recording.

giles: I think they're very different.

markw: What's missing for trick-play?

Mark_Vickers: Nothing I'm aware of.
... The only thing I'm not sure is supported is where the files are all on the server.
... I'm fine taking it off though.

markw: We should be more specific about what's missing.

Mark_Vickers: I'll take it off.

??: PIP is not possible now. Video element can only have one active track.

markw: You can use two of them.

Mark_Vickers: you can layer them.

markw: There's no limit in the HTML spec on where you can do these effects in HTML, so it is a question of what you want to support.

Mark_Vickers: Discovery API would be good.

giuseppe: It's not clear from HTML5 when you have a resource constraint.

Mark_Vickers: Device capabilties
... For example the number of decoders

Yoshiharu: Is that including capabilities about the receivers memory?

Mark_Vickers: It's whatever we think is the requirement.
... I'm not sure what you do with a memory number.

Stephane: Even decoders you could have software decoding. It becomes very complex.

Mark_Vickers: Let's not deep dive on it.

??: You're choosing a strategy here with capabilities detection rather than conflict detection.

Mark_Vickers: I agree, leave ourselves open.

??: Time shifting is part of recording?

Mark_Vickers: I think if you have recording and trick play you can do it.

Sangwhan: Channel list information

??: Channel itself usually refers to the tuned in channel, while channel list is more.

Sangwhan: EPG been covered?

giuseppe: That goes into metadata.

??: metadata should be redescribed.

s/??: EPG/sangwhan: EPG/

Mark_Vickers: I encourage people with access to OIPF or other systems and look through them and see what other gaps may be there, send it via email.

<Dewa> +p Christian

Christian: I don't think W3C wants to include anything in HTML to screw up TV settings. Makes complete sense in OIPF. If you try to mirror OIPF you end up with requirements that may not make sense.
... Tune in to channel would be killed immediately and not even mention it.

Mark_Vickers: I wasn't suggesting we carry everything over, just look for use cases.
... I wouldn't say it's impossible for W3C to define dangerous APIs because there is a new effort, the System-level APIs WG that is about that exactly.
... I don't have interest in that, but if you do, we could do that within that group.

markw: It all depends on what the system is you're talking about. There could be a need for a web thing over here to control a tuner over there.
... Setting the channel is potentially the same as setting the URL on a video element.

giuseppe: This hybrid architecture is still in scope. There's no standard way to do this right now.

markw: That's the gap, standardizing the URL. Whether the tuner is in scope is a question.

giuseppe: ??

markw: You are going to use a URL on the video element, which is different than having a video pane that's separate from the page.

Mark_Vickers: I'm just talking about APIs that may be dangerous and have security issues around them. The system group is defining things like that, and it'd be legit for this group to define that and send them to the sys apps group.

giuseppe: We should go through all the use cases and classify them that way.

<olivier> [time check]

jcverdie: How to deal with conditional access and ...

HJ: Some of this depends on environment, some things should be allowed by trusted applications.
... Applications that have access to these things must be trusted.

jcverdie: You're talking about access to the APIs, I'm talking about the CI and CA features in every set top box.

Mark_Vickers: Switching video output control.

jcverdie: We should find descriptions for each of these use cases. And may end up with new use cases.

<jcverdie> rssagent, publish minutes

- DRAFT -

Creating API to access TV level functions

31 Oct 2012

Attendees

Contents

Introductions

Agenda

Summary of Action Items

Scribe.perl diagnostic output