TV Control WG Meeting

Chris: [reviewing the agenda]. Any additional item that you'd like to add to the agenda?

Rechartering of the group

Chris: Initially, idea was to have a new charter ready by end of January.

<kaz> current charter

Chris: To get more time, I wonder whether we may ask W3M for a short extension
... Francois, any update on that?

Francois: No update yet, but I'll investigate.

Liaison letters

Chris: We already sent one to ATSC. I'm not aware of any reply yet.
... I drafted one for HbbTV. Any comment?

<inserted> Chris's draft message

Alex: Looks good. In the second paragraph, it would be helpful to name the "TV Control Working Group" instead of just "Working Group". Letter is fine otherwise.

Chris: OK. With that edit, I guess we can send it almost immediately.

Alex: One additional comment in the last paragraph. On one hand, you wonder whether HbbTV members can join the Working Group. That's fine, but then you ask for support. Who can support? Only W3C Members, right?

Chris: Right. We'd like to get the participation of HbbTV members who are not W3C members as well. It would be helpful to identify them.

Francois: Note a letter of support from HbbTV as a whole would be useful too. Of course it's preferable to get concrete participation in the WG, but letter of support would already be a good thing.

Chris: I have a similar draft letter to DVB, which I'll circulate. I aim to send both of those this week if that's ok with you.

Alex: This is ok.

Source-centric API model and getUserMedia

<cpn> https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0010.html

Chris: Thanks Steve and Ryan for the continued discussion.
... The diagram you shared, Ryan, seems very well aligned with the direction the group is pursuing. We use different terms, but conceptually, this seems to map very well.
... The idea that we have some set of resources managed by the device, and exposed through the API, is the same.
... I think it would be quite good to include a diagram such as this in the specification itself.

Ryan: That's the reason why I did this. I wanted to make sure we were talking about the same thing. As far as the resources are concerned, I wanted to make sure they are grouped by "availability".
... Resource is gone once it's no longer available. That's the whole point.

Chris: Yes, it helps clarify the thinking. When I look back at the proposed API in Steve's email, I started to compare with the work done in the WebRTC group, where they have the notion of "constrainable track".
... I wonder if we should have a similar constraint pattern.
... In WebRTC, you have a getCapabilities that lists the capabilities and then setCapability method to apply each of them.
... Our API could work similarily.
... Capabilities could be specified to help the implementation lock the appropriate resource, as requested by Igarashi-san back at TPAC.

Ryan: This would be further down in my diagram. "FM1" would be a source, with different constrainable capabilities.
... In my diagram, when FM1 is used, AM1 is no longer available. I don't care where they come from, they could be coming from different tuners. What matters is that locking one makes the other unavailable.

Steve: I see where you're getting at. One question there that I had was your use of the term network.

Ryan: Several nodes will be accessing this API. The network would be all the nodes that can access this API. In a TV situation, it could be different tablet/computers that have access to this API.
... The diagram can scale to external players which would call getResources to determine which resources are available, and so on...

Chris: A number of questions come into mind. When you talk about other players, I'm trying to understand the relationship between this device and the "user agent". If the user agent has an implementation of the TV Control API in it, then any rendering that is done by that user agent can make use of the resources that are available.
... Are you suggesting that we should have a multiple user agent approach?

Ryan: I would leave the architecture open to that.

Steve: I would agree to leave the architecture open to that. You may also have multiple tabs of the same user agent open on the same device.

Chris: Right, my point is whether we are talking about re-distribution of the media over the network.
... This ties in to the discussion on whether we should be using a JavaScript API or a RESTful type of API.

Ryan: I am looking at it with a RESTful angle.

Chris: OK, what we have right now in the TV Control API is direct access to resources. We haven't been considering the network approach.

Ryan: Goal is to leave it open to that.
... You may have different players which can lock different resources. I would hope there should be some synergy so that we can both use the same API.

Chris: OK, that sounds fine. I have the feeling that we may be exceeding the scope of our charter if we start talking about network access to resources.
... But if there's an architecture that is useful to both contexts, then we should try to achieve it.

<inserted> Scribe: cpn

Francois: With WebRTC we can transmit media streams over the network, so the TV Control API could be extended with WebRTC based protocols to allow sending the media over the network, so this seems orthogonal.

<inserted> scribenick: tidoust

Chris: What I'd like us to do is to identify the practical next steps for this.
... I've started to look at Steve's proposal, and then I started to look at how to apply getUserMedia constraints.
... We are also engaged in a discussion with media capture folks which we should respond to:

https://lists.w3.org/Archives/Public/public-media-capture/2016Dec/0038.html

<cpn> https://lists.w3.org/Archives/Public/public-media-capture/2016Dec/0048.html

Chris: Some proposal there to get a stream from a channel. Once you have a set of resources allocated, in order to get a channel, we wanted to be able to reuse the existing connection between the resources and the playback.
... I guess we should reply to this to explain our thinking around our thinking.
... Does that still stand, though?
... Request a new stream for each new channel? Or reuse the stream?
... I'm happy to take a closer look at these questions myself.
... I think we should try to pin down the terminology

Ryan: The player for me does the decoding and rendering of the stream. No tuner in there, it basically plays the media. You're assigning a media URL.

Chris: I'll continue to have a look and assess the different feedbacks and arguments received so far.

Mappings to DVB

Chris: Michael has worked on the mapping to DVB. Thank you for documenting what you found so far on the Wiki.

https://www.w3.org/wiki/TV_Control/Protocol_Mappings

Michael: After last call, I started to populate a Wiki page. It's not that much so far. The main purpose of this exercise is to double check whether the API can be mapped onto a broadcasting system such as DVB without major gaps.
... I started with existing things, notably the Sourcing In-band Media Resource Tracks from Media Containers into HTML.

<cpn> https://dev.w3.org/html5/html-sourcing-inband-tracks/#mpeg2ts

Michael: It's already referenced by HbbTV.
... However, when I looked at it, I saw a couple of things that I would rather change.
... Then I populated a table for the TV Channel, using a similar construct from OIPF.
... Today, I started to look into the TVTrigger interface.
... I'm trying to see how stream events can be mapped to the TriggerCue interface. As TriggerCue is based on TextTrackCue, it's not an ideal mapping.
... These cues have start/end times, which is not always applicable to stream events.
... A DVB implementation would have to make some changes or re-interpretation.

Chris: In DVB, is the intention that the events are actioned immediately, or would events be paused as well when media is paused?

Michael: Based on MHP. Two event types, one associated with a timestamp, and the "do it now" events, which are the only ones used in HbbTV. There's no clear definition as to what happens when the media is paused.

Chris: OK, so this is missing from the TV Control API, as we only support the timed event.

Michael: Right, the notion of active cues with a start time in the past and an end time in the future cannot be applied to stream events directly.

Chris: The closest thing that we have to this is the emergency events. Intended to be triggered by the client as soon as they are received.
... I guess we could add a new kind of event close to the stream that would expose the "do it now" events.

Francois: Any example of "do it now" event?

Michael: Typically for synchronization with the broadcast app.
... Synchronized pop-ups, typically.
... That's implemented in HbbTV terminals and used by applications.
... I think that's how far I got. If you think that's useful, I would continue and then we can discuss that and adjust the API.

Chris: I think this is extremely helpful. Please continue!
... The approach you're taking is good. Documenting the Wiki in particular. That's really good work, thank you.
... One final thing that I'd like to mention. We merged Alex' initial radio proposal but agreed to do some refactoring, for instance move application notifications to media streams.

Alex: Sure, go ahead, as needed!

Chris: OK, this may need to wait until we're done with the re-design of the API.

Alex: OK, the main point is to get the basis correct. Then we can adjust to support applications.

Chris: OK, we'll continue the discussion on the GitHub and mailing-list. Any other points?