See also: IRC log
[Chris reviewing the agenda]
Chris: We had a very good meeting
at TPAC. Discussions were very interesting and lively. We made
some good progress in terms of the direction that we'd like the
spec to take.
... One of the things that we really needed for the group was
someone to edit the spec.
... The spec initially came from Mozilla but Mozilla is not
around anymore, so we were out of an editor.
... It made it difficult to make updates to the spec.
... I'd like to say "Thank you" to Steve who agreed to become
the editor of the spec.
... Your contributions have been very useful already. I'm glad
that you can take on the role.
Steve: You're welcome. I hope I can do a good job!
-> Issue #4 on TVSource and TVTuner
Ryan: I have some perspectives on this particular issue
Chris: Great. It kind of became
clear that the relationship between sources and tuners was not
entirely clear to us at TPAC.
... The last comment in the issue tries to summarize the
problem.
... The goal is to move to a source-centric model rather than a
tuner-centric model.
... It's consequent changes to the spec, so it's important for
us to agree on the direction, and also to work on
details.
... One of the goals for changing the API is to simplify it
from the application developer's point of view.
... and in doing so, maybe hide some details that implementers
may care about but developers may not.
... Essentially, the proposal is to change the TVManager
interface, which has a getTuners method, to rather expose a
getSources method to retrieve a list of sources.
... From sources, you can request a channel list.
... When you request a tune-to-channel operation, this returns
you a tuner object that gives you access to the stream.
... I'm wondering about the name of "TVTuner" here as well.
Ryan: Generic tuner is almost a
hardware container of sources.
... How do you get around the constraints of available
tuners?
... One of our constraints that there are multiple users of the
same tuner.
... Sometimes tuners can be sourced twice.
... The front seat and back seat could tune in to different
sources
Steve: One of the issues we
discussed at TPAC is that there is an implementation issue. It
also depends on the decoding pipeline that you have.
... The tuner is just one of the aspects here. It's not clear
what the relationship between these resources is.
... Is that something that an application will care
about?
... Or does it care whether it can decode and present a
stream?
... Where does that piece of intelligence that selects the
tuner gets built? The app? The UA?
Ryan: A tuner that is already
used should leave the "available" list.
... So that the user cannot select it. User experience would
not be good.
Igarashi: In term of
requirements, we have a requirement that applications will want
to know the tuner, the physical resource.
... About tuner-centric or source-centric, it's more a question
on how an app wants to find about these resources.
... I would suggest to separate abstracting physical resources
from discovery of content.
... In terms of content discovery, I agree with the
source-centric approach.
... However, that does not address the requirement I mentioned
before. We should address it and give a way for an app to
select the physical tuner.
Steve: I'm not disagreeing with
that, but think we should be careful. I think tuner is going to
be only one type of available resources (also hardware decode
blocks, hardware decryption blocks).
... I don't think we should define all terms in the spec but we
should be very clear about what we mean.
Igarashi: Since we have the Picture in Picture (PiP) use case on our plate, we need to expose that to the app.
Steve: I don't necessarily agree about that, but let's not have that discussion here.
Igarashi: Right, my point is that it is a separate issue that we need to discuss, independent of the source-centric approach discussion.
Steve: If I rephrase it slightly, the app needs to know about the decoding capabilities to know what resources it can render.
Igarashi: Yes, if the app wants to render two resources, it will want to know this. The specific capabilities are another discussion.
Steve: I think we agree, although
we use different words.
... I am thinking about the case if an application is
presenting a 4K TV channel and it wants to know whether it can
present another SD channel or another HD channel.
... I can see some value for an API that forces the UA to use
specific tuning settings because the app knows that something
valid will come out of it.
Igarashi: Apps should know that
tuner availability depends on the type of resources and on the
device state.
... It depends on which source gets streamed.
... Also, if the receiver device is in recording mode, the
underlying tuner may not be availaible. We need to think about
these cases.
... We may be able to create abstractions not to expose the
capabilities.
Steve: The ability to present a stream depends on the content that is currently being presented as well, the device state. There are several things that relate to that.
Igarashi: One tuner instance cannot render any content resources. The availability of the tuner resources varies over time and depending on its capabilities.
Chris: In the new API that we
drafted, we have this tuneToChannel method that returns a
Promise to get a TVTuner object which we can then either
resolve successfully which means you can get a stream
... or we can reject which means you cannot get a stream.
... Is that the right model? Do we need something on top of
that?
... More precisely, what does the API need to have that this
proposal does not?
Steve: I think the shape of the
API as is currently crafted is mostly correct.
... I think what we're saying is that we want another method
that says "can I tune in to this channel?", or "what
capabilities are still available?".
... Perhaps "How many more HD channels can I present?", "How
many more FM radio channels can I tune to?"
... I'm not sure about the shape of the API for that
part.
... I haven't thought about that too much.
Chris: So, no objection to making
the API more source-centric, provided that there's some kind of
query interface available to determine what we could stream,
display, or record?
... Igarashi-san, would you be able to help with providing the
parts to this API that you think are missing?
Igarashi: The TVManager gives a
list of sources. Then the application chooses a source and
wants to know how many tuners are available. The maximum number
of instances should be exposed somehow.
... In addition, the application may want to know the
availability of a specific tuner instance.
... Third requirement, decoder capabilities can be different
(OTT, IPTV cases). Assuming that IPTV content is a source, but
the device may have one HD decoder and one SD decoder.
... Application cannot render two different streams. It should
know about this.
... How we spec the API in the end is a discussion point.
Ryan: I still see other sources.
If you go through the different sources, some come with numeric
range. Media streams come with different properties. When you
are on an HD station and need to be on the station for a
certain amount of time to know that there are other stations,
things are more difficult.
... The way I try to solve it is to have a notion of
sub-channel. I don't know if HDTV works in similar ways. That's
the most difficult requirement for us.
... When you're in a vehicle, the list of stations can change
rapidly.
Chris: Do you see any gap in the API that we have?
Ryan: No, I'm just "glad" that you have the same problems as ours :)
Ryan: I came up with the same
challenges as you seem to have, which is good. The ability for
the client to know the available zones.
... There is nothing in the TV Control API specification.
... With earphones and other audio output devices, an app may
want to select the output device.
... In a vehicle, it's important, some vehicles are 3 tuners
and different zones.
... Persons may be listening to totally different streams using
headphones.
... I could see this with TVs as well.
... The audio zone could be the room in the house for
instance.
Igarashi: I think that, in the
case of TVs, we also have similar use cases.
... To address these use cases, we should be careful about the
type of applications that we're targeting.
Igarashi: I wonder whether the audio use cases you mention apply to type 1, type 2 or type 3 applications.
Ryan: In my mind, any of these applications should be able to do that.
Chris: That's something that I don't think anybody else has really thought about, the concept of audio zones.
Steve: Conceptually, this is similar to some of the discussion that is happening in the Second Screen WG around remote playback.
Francois: with WebRTC
you can enumerate output audio devices, and select the device
you prefer to use
... This could perhaps
be extended to cover the 'zone' notion we're discussing
Ryan: User preferences are another area that I haven't seen in the spec.
Chris: I wonder if that should not be up to the app.
Ryan: User-based list of preferences could be useful across apps.
Chris: That may be something to pick up with Alex.
Igarashi: "zones" could be a generic feature, addressed elsewhere, e.g. in WebRTC. Selecting an audio output zone could be generic to the HTML5 media.
Chris: I think that's a very good
point. This routine could be a generic thing to HTML5 media
elements.
... I'm not sure that doing a TV-specific thing is the right
approach.
Steve: I agree with that.
... It's important but not TV-specific.
Chris: Igarashi-san, can you capture your requirements on the Wiki?
Igarashi: Yes.
Chris: Just use the use cases
page.
... Ryan, feel free to do the same.
Ryan: OK.
Chris: I'll give some thoughts on
capabilities and lookup of available resources.
... Thank you very much for joining. Now that we have an
editor, I hope we'll be able to make good progress.
... Next call in four weeks from now. Please use GitHub issues
in the meantime.