- From: Francois Daoust <fd@w3.org>
- Date: Tue, 10 Jan 2017 16:05:57 +0100
- To: <public-tvcontrol@w3.org>
Hi,
The minutes of today's call are available at:
https://www.w3.org/2017/01/10-tvapi-minutes.html
... and copied as raw text below.
Thanks,
Francois.
-----
TV Control WG Meeting
10 Jan 2017
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2017Jan/0002.html
See also: [3]IRC log
[3] http://www.w3.org/2017/01/10-tvapi-irc
Attendees
Present
Chris_Needham, Francois_Daoust, Kazuyuki_Ashimura,
Ryan_Davis, Tatsuya_Igarashi, Steve_Morris,
Alexander_Erk, Michael_Probst
Regrets
Chair
Chris
Scribe
Francois
Contents
* [4]Topics
1. [5]Rechartering of the group
2. [6]Liaison letters
3. [7]Source-centric API model and getUserMedia
4. [8]Mappings to DVB
__________________________________________________________
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> [9]current charter
[9] https://www.w3.org/2016/03/tvcontrol.html
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> [10]Chris's draft message
[10] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Dec/0035.html
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>
[11]https://lists.w3.org/Archives/Public/public-tvcontrol/2016D
ec/0010.html
[11] 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:
[12]https://lists.w3.org/Archives/Public/public-media-capture/2
016Dec/0038.html
[12] https://lists.w3.org/Archives/Public/public-media-capture/2016Dec/0038.html
<cpn>
[13]https://lists.w3.org/Archives/Public/public-media-capture/2
016Dec/0048.html
[13] 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.
[14]https://www.w3.org/wiki/TV_Control/Protocol_Mappings
[14] 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>
[15]https://dev.w3.org/html5/html-sourcing-inband-tracks/#mpeg2
ts
[15] 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?
[End of minutes]
Received on Tuesday, 10 January 2017 15:06:11 UTC