W3C

TV Control WG call

28 Jun 2016

Agenda

See also: IRC log

Attendees

Present
Francois_Daoust, Younsun_Ryu, Chris_Needham, Alex_Erk, Ryan_Davis, Kaz, Bill_Rose, JP_Evain, Steve_Morris
Chair
Chris
Scribe
Francois

Contents


<SteveMorris> Unfortunately I can only join the IRC channel today, not the webex

Chris: [going through the agenda]
... Feel free to raise additional topics as needed
... I've seen some discussions around the TV Control API in the Cloud Browser TF of the Web and TV IG. I'd like to know if there are requirements coming from them.
... Also, we had feedback from folks from Broadcom which I'd like to discuss.
... Any other topic for the agenda?

Publication as First Public Working Draft

Chris: The main issue is to set the purpose and context in an introduction
... I would hope for somebody to contribute text for that.
... Anyone willing to write some introductory text for the specification?
... Does anyone else feel that we need to address other issues before publishing the spec as FPWD.

Alex: The only question I have is whether we can include radio use cases in the spec before publication as FPWD.

Jean-Pierre: Have you specified something yet for these radio use cases?

Chris: Not yet

Ryan: I'm still planning to add some text from my perspective.
... I have gone through and tried to cross-reference a lot of automotive use cases with TV tuner use cases.
... I'm not sure that's useful for you guys from your perspective.
... I can probably provide a few of them by end of this week.
... I need to reach out to some of my co-workers to see if they have specific use cases to contribute.

Chris: Overall, this group is looking at how we can source audio/video media into the browser.
... It's looking at the different media sources and then provide access to these sources as well as metadata that these sources may provide.

Ryan: What we've been focusing on with the media tuner discussion in automotive, is with Genevi.

Chris: It would be great if Alex or Jean-Pierre could take a look at your use cases and see how best we can cover enough of the functional requirements in the TV Control API.

Alex: Is the Genivi stuff open?

Ryan: I believe so. The group is closed but I think the spec will be open and public. I'll get back to you on that. I'm not part of that group. They opened up the specification for us in W3C.
... There are lots of common people in W3C and Genivi.

Alex: Can we have a look into it?
... I began to fill the Wiki page for the use cases on that.
... We can extend those use cases.
... Maybe there are some more areas to cover. I haven't looked at EPG right now but will do so.

<ryandavis> GENIVI IVI Radio Use Cases

Alex: Some of the general scanning can be done quite straightforward.
... It's just a different type of tuner with no video. Nothing special about it.

Ryan: I added a link just now.

<cpn> W3C TV Control Use Cases

Alex: Main question is how to integrate radio text and images?

Jean-Pierre: We all know that radio community is different. Is it a good idea to merge the two in the same spec?
... I'm not quite sure that people will read it or apply it.

Alex: I think it's not a problem. Why should it be? Even now on DVB, you could have radio-only services.

Jean-Pierre: The point is you *could* have but we *don't*.

Alex: We have. The ARD has a complete radio service like this.
... It's not a huge movement in the market, but we have first smartphones with DAB receivers into it.
... People are looking into use cases.
... Currently, we can only use that in a native application, but it would be fantastic to integrate that in Web browsers.

Chris: My own feeling is that the details of the API might be sufficiently similar that one spec can cover both.
... A lot of the text in the spec is TV-oriented, but that seems easy to fix.
... For the FPWD, since it's important to set the scope of the publication, we should include radio. Whether that means we need to update the interfaces or simply insert it in the introduction, I'm less certain.

Alex: I'm busy this week. But after that, I may have some time to go through the spec and see how I can integrate the work that we've been doing in our prototype.

Chris: That would be very welcome. Could it be done by next call in 4 weeks from now?

Alex: At least some comments on parts that I think could be changed, yes.

Kaz: I just skimmed through Ryan's use case document. On the left side, there is a link to the media manager and media control.
... There are some requirements there.
... We might want to think about Genivi managet and control use cases as well.

Ryan: Yes, I agree. That's why they are there.
... Genivi did a lot of research when they developed these use cases and maybe they have a draft spec already available.

Kaz: In addition to simply radio tuner, finding a way to integrate Genivi's media tuning with the TV Control specification would be great.

<kaz> GENIVI Media Control

Chris: Are there features that fall out of scope of the TV Control WG charter?

Kaz: Ryan put the link to the GENIVI Software Projects, and there are links to (GENIVI's) Media Manager which includes its own Media Control feature. From the Automotive group's viewpoint it would be nicer if we could handle media tuning in general, e.g., DVD, smartphones, in addition to radio. The Automotive group also should have some more discussion which topics should be brought to the TV Control group, though.

Ryan: Comme use across the board will be the use of MediaStream.

Chris: This makes me wonder whether we should aim for a higher level of abstraction than we currently have.
... The ability to source any kind of media regardless of where it comes from.
... TV tuner, Radio tuner can be included but also collection from other sources.
... I need to refer back to the WG charter.

Ryan: I think everybody's goal is to play any kind of source. In the tuning device, the frequency is involved and the details as to how they switch frequencies matter.
... I like to have a list of sources with different characteristics depending on the type of source.

-> TV Control WG charter

Chris: I just had a look at the charter, this would be in scope in any case. It's a good fit for this group.
... In terms of next steps on this, maybe we should record some action.

<scribe> ACTION: Alex to provide feedback on the spec for integrating radio use cases based on experience with prototyping [recorded in http://www.w3.org/2016/06/28-tvapi-minutes.html#action01]

Ryan: I have some of the radio tuner stuff already. It coordinates with the use cases of the media tuner.

<ryandavis> Automotive Media Tuner Use Cases

Chris: I suppose reconcialing these different sets of use cases.
... Alex added some use cases to our Wiki page.
... It would be good to add Genivi use cases that are not yet covered on that page.
... and ideally cross-reference them

<alexerk> https://www.w3.org/wiki/TV_Control/Use_Cases

<scribe> ACTION: Ryan to investigate internally to complete radio use cases Wiki page as needed [recorded in http://www.w3.org/2016/06/28-tvapi-minutes.html#action02]

Cloud browser use cases

<kaz> minutes from the latest call

Chris: Have new requirements emerged from that discussion?

Kaz: Not yet. The Cloud Browser TF has mainly been talking about use cases and possible architecture models.
... The requirements discussion will be done a bit later on.

Chris: OK.

Kaz: The architecture discussion possibly includes communication with the tuner.
... Cloud browser is server-based, server-side tuning would require communication with the client side.

Chris: OK, thank you for the update

Feedback from people at Broadcom

-> Feedback from people at Broadcom

Chris: People at Broadcom have been working on an implementation of the TV Control API specification.
... They have raised an interesting issue.

<kaz> s/brought to the TV Control group, /brought to the TV Control group, though./

Chris: This is talking about 2 software modules that want to access tuner capabilities.
... How do these modules negotiate or release the tuner?
... So that the user agent may know that the tuner is available for other uses.
... At the application level, you can make requests that cannot be satisfied by the underlying resources.
... What they found is that it's not clear how to handle this particular use case.
... Two possible solutions: have module A explicitly release the tuner so that module B can access it.
... or make that more implicit.
... The response that I sent was to suggest to make that explicit, but maybe there should be more of an implicit approach where the implementation is able to manage the resource without putting the burden of the acquire/leave mechanism on the application.
... Has this issue arisen in other areas?
... Is there an existing pattern that we could follow?

Ryan: I don't know of any existing pattern, but based on experience, implicit would help recovering from buggy applications.

Chris: I agree

Steve: As an implementer of the specification, it gives you more freedom to optimize the use of the resource instead of relying on the application.

Alex: You cannot rely on application developers to share resources.

Steve: especially if applications come from different sources.

Chris: What implications does it have on the spec?
... It may either be normative changes or guidance for implementers.

Kaz: There has been some similar discussion in the Automotive group, and the group thinks that they should handle 2 levels of interfaces, high-level and lower-level interfaces.

<kaz> vehicle information service spec draft

Kaz: There's some discussion on whether to support sessions and/or transactions.

<kaz> MMI Architecture

Kaz: Another spec named MultiModal Interactions (MMI) to integrate speech and other user modalities, also have lifecycle model for session connections.
... It may be useful for TV Control as well to have two levels of interfaces and have session support in the lower level.

Chris: So we'd have the current layer for applications. And then underneath that specification, we'd have another level for implementers.
... Is that something that would need to be standardized?

Kaz: That's a good question. In the automotive case, the group feels the industry need it. The TV Control WG needs to discuss this.

Chris: OK, that's a question I need to put in front of all participants here.
... At this stage, I don't have a strong opinion either way.

Alex: Isn't that very implementation-oriented?
... Assuming I'm watching a stream for an hour, my app will never release the tuner. If a second app comes in and requests access to the tuner, I would expect a kind of modal dialogue that offers the user the possibility to force the release of the tuner so that the second app may acquire it.

Chris: Right. I'm also thinking about an application that tries to render multiple streams at the same time.
... I suppose the failure value in the API will give the application some clue as to what happens.

Ryan: It could be that the client that wants to claim the resource can request an override.
... "This is currently in use. Are you sure you want to do that?"
... If there's one user at home, override would be a good thing. If there are multiple users, being able to steal the tuner may not be a good thing.

Chris: From a TV UI point of view, is it a question that the API presents error information back to the application so that it can handle contention, or are we talking about a modal dialogue approach?
... It has implications on the user experience, and interaction through the TV.

Kaz: I agree with Chris. If the use case is simply switching from channel A to channel B, then a high-level API should be enough. However, if we have more advanced use cases to superimpose channels from small screen to the big screen.

Chris: Yes, that second scenario is what I had in mind.
... Does the specification provide enough information to know what the problems are? Do we expose that information beforehands? Or do we let the application try the API and fail?
... I think we need to think about it. What I would suggest is to follow-up the email thread.
... I'm hoping that the guys from Broadcom will come back to share their views on the topic.

Kaz: In addition to responding to email threads raised by Broadcom, maybe we can add a section in the Wiki for advanced use cases. If there's enough need, we could think about supporting them.

Chris: I think it would be useful to get feedback on whether a second level seems needed.

Kaz: And if there's no need, then we can simply concentrate on the current API.

Chris: Should I reply to the thread to mention that possibility of a second API?

Kaz: Please do so, yes.

<scribe> ACTION: Chris to get back to Broadcom's thread to mention the idea of a lower-level API [recorded in http://www.w3.org/2016/06/28-tvapi-minutes.html#action03]

Chris: Any other comment?
... Next call is 26th of July

[Call adjourned]

Summary of Action Items

[NEW] ACTION: Alex to provide feedback on the spec for integrating radio use cases based on experience with prototyping [recorded in http://www.w3.org/2016/06/28-tvapi-minutes.html#action01]
[NEW] ACTION: Chris to get back to Broadcom's thread to mention the idea of a lower-level API [recorded in http://www.w3.org/2016/06/28-tvapi-minutes.html#action03]
[NEW] ACTION: Ryan to investigate internally to complete radio use cases Wiki page as needed [recorded in http://www.w3.org/2016/06/28-tvapi-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/28 14:15:35 $