See also: IRC log
[Round of introductions]
Chris: Welcome. Going through the
spec. The TVManager gives access to TVTuner objects. And then
from TVTuner objects, you get access to TVSource objects.
... The source lets you switch to a channel exposed on the
tuner.
... There's some interesting relationship between a source and
tuner, which we'll look into in more details later on
today.
... The TVManager also allows one to schedule recordings.
... The source object provides access to channel scanning and
the list of available channel list.
... From there, you get access to the EPG.
... There are also some interfaces for defining triggers, that
takes the form of an extension to TextTrackCue.
... When you assign a MediaStream to an HTMLMediaElement, the
browser will create the necessary tracks and expose them.
Colin: Is there any reason why it
is tied to the Navigator object?
Francois: That's the "usual" way APIs are designed these days. I think the idea is not to expose APIs to the global object directly.
-> Open issues
Chris: Starting from oldest
issue.
... Management of underlying resources initially came from
folks at Broadcom.
... The particular scenario that they have is that they have
two modules making use of the API against one tuner.
... The first module uses the tuner, and when it's done the
second module is allowed to use the tuner.
... The question is: how can the application be aware that the
tuner is free to be used?
-> Management of underlying resources
Chris: The application may be
able to issue commands that may not be able to be satisfied. Do
we have an automatic way of locking/unlocking resources or do
we need an explicit mechanism? There are pros and cons for each
approach.
... With the explicit approach, we're putting a burden on
applications, and some of them may not do it properly. It may
not be wise to rely on them.
-> List of tuners instead of just one tuner
Chris: The underlying question is
"why can applications do with this kind of information?". This
points to the particular use cases that we have for the
API.
... What kind of applications do we envision that could make
use of this kind of features.
... Is it something that should be exposed to TV device to
generate the main UI? Should it be exposed to broadcasters? Or
should it be more generically available to all types of Web
applications?
Igarashi_San: Not sure I understand the issue.
Francois: getTuners returns a
list of tuners. But what are applications going to do with that
list? How are they going to select one of them? Tuners do not
have friendly names, they cannot really ask the user.
[discussion on getTuners purpose]
Igarashi_San: The intention is to get an instance of tuners physically present on the device.
Chris: The list of tuners gives you an indication of the number of streams that can be made available.
Mike_Assenti: Are we talking about the multiplex stream or individual media streams?
Francois: The API exposes
MediaStream, so not the multiplex stream.
Chris: But that's a good point indeed.
Steve: We seem to be dwelving into the next agenda point, here.
Chris: Right, that's the architectural discussion that I'd like to have next.
Chris: That issue is a minor one, that's the recommended way.
Jean-Pierre: where do startTime and endTime come from? DVB SI?
Chris: That's an open question.
Francois: ReSpec no longer supports the WebIDL mode that we're using, and that breaks the rendering. This needs an editor!
Chris: Next issue is channel
scanning. The question is why does it need to be exposed to Web
applications?
... How can a web app decide when it needs to do a channel
scan?
... Coming back to the architecture discussion, we need to find
the right balance between exposing the hardware layer and
providing too abstract interfaces.
... Also, when we extend to radios, do the same considerations
apply?
-> Privacy and fingerprinting considerations
Chris: I went through a few W3C
documents for guidance.
... I found it quite a useful exercise trying to answer some of
these questions.
... The things that mainly came out were that the list of
recordings and the list of channels can be used for user
fingerprinting.
... The question is again whether this information can be
exposed to regular applications, or only to the device
environment.
-> Mappings to media delivery formats and protocols
Chris: At the moment, we don't
say anything about how the different attributes that are
exposed by the API are to be initialized from broadcast
data.
... Question is whether we want to work on such mappings or
whether we're happy to just leave the spec as is and let others
do that work.
-> More flexible presentation restrictions requirements
Chris: Speaking from a BBC
perspective, we would be concerned about exposing broadcast
streams to arbitrary origins.
... I'd like to hear other views.
Jean-Pierre: I'm pretty sure that you're not the only broadcaster to have similar requirements.
Alex: I agree. There could be a commercial broadcaster which displays ads and may not want things to be tempered with.
-> Access to parental control methods
Chris: It's fairly trivial for an application to enumerate all pin codes. Should it be part of the API? Again, this ties back to the architecture discussion.
Alex: If someone enters 3 or 4 incorrect pins, the app should be blocked for e.g. 10mn to prevent that kind of problem.
Chris: Yes, we can certainly add text to the specification along these lines.
Steve: I guess this ties to the
kind of applications that we're expecting will use this
API.
... If it's for TV device UI, does it need to be exposed to the
application?
Chris: 3 categories. The in-built on-screen display, the broadcaster web application context, the general web application environment. And there may be what could be out of scope.
-> Radio API
Chris: The final issue that we
have takes the form of a Pull Request that Alex kindly provided
to support radio.
... We'll go through that this afternoon.
[Break until 10:45]
Chris: does any one have thoughts on the architectural questions?
Colin: What we'd like to is a replacement for the various proprietary APIs, so for us it's helpful to have a low-level API
Francois: Is this for the in-built device UI?
Colin: The browser has control of everything, parental control, etc
Francois: Can the end user use this browser to browse the web?
Colin: Yes, the same environment
can be used for the EPG as well as browsing the web
... But we wouldn't want to give access to all these APIs
Francois: So you see there could be these different contexts
Colin: A low level API should only available in a more restricted context
Igarashi: What do you mean by a low-level API?
Francois: I see the current API as low level
Colin: The API should be abstracted but it should have all the functionality needed to control the TV device
Igarashi: The current model
doesn't directly map to tuner devices, so there already is some
abstraction
... If the getTuners returns a list of 3 tuners, that doesn't
mean it can produce 3 simultaneous streams
... ... How does the Tuner object map onto the physical
tuner?
Steve: The API may be trying to
mix different types of requirements.
... An app may just want to get a list of channels and tune to
a particular one. That app would not need to care about tuners
and sources.
... Other types of apps would need to care about that level of
details.
... Are we posing problems to implementations if we expose that
level of details.
Chris: Question about sources. Would that be setup once or would user want to often switch from one source to another?
Steve: Why would the user care
about sources? Most would care about the channels that they can
tune in.
... There are devices with multiple sources (terrestrial,
satellite, IP). But do applications care?
Jean-Pierre: The stream exposed on the tuner level comes from a source. That's somewhat confusing.
Colin: I don't think you can just get a list of channels because the source might be important if the channel can come from different sources.
Steve: Question is whether you'd
prefer to leave that to applications or to the
implementation.
... Potentially, you can get different lists of channels from
different sources and if you're not careful about this, the
user experience can suffer.
Alex: Sure, there are devices
with multiple tuners. The distinction between tuner and sources
may make some sense in some cases. But do we really need to
bring this to the end user and to the application?
... Normally, the application should not care about that.
Chris: I think we should be able to support non-broadcast types of sources as well. Some better level of abstraction would be useful.
Jean-Pierre: From a broadcast
perspective, you have a tuner through which you get one or more
sources (services in DVB SI), through which you get one or more
channels, through which you get programs.
... But we don't say where the metadata comes from.
... I'm trying to understand what we're trying to achieve
here.
Steve: I agree we should be concentrating on trying to define that scope.
Jean-Pierre: Where is that
supposed to be integrated?
... In a TV set?
Francois: Looking at people around the table, we seem to be targeting TV/embedded devices, not "regular" Web browsers.
Igarashi_San: I think we can
cover all the possible targets with only one API.
... The object model hierarchy tuner, source, stream should be
the common case that applies to all cases.
... Tuner represents a maximum number of output streams.
... But it does not always guarantee that two streams can be
shown.
Steve: The mapping between the
tuners and the streams that you can render is very
complex.
... Devices may not have decode resources to decode more than
one 4K stream at a time.
Francois: Then I don't get why we want to use a complex object-model that does not seem to expose useful workable information to applications.
[discussion on tuners and sources]
Mike_Assenti: Use case with one DVB-T tuner and one DVB-S tuner but only one decoder.
Igarashi_San: I think this issue
works well with the current model. If TV supports multiple
video streams, each tuner should have DVB-T and DVB-S sources,
but if one tuner selects one source, the other tuner may not be
able to switch to the same source.
... That's a capability issue.
Chris: I've wondered whether the entry point, through the TVManager. I wondered if the source should be the source.
Igarashi_San: That's another possibility if we take a metadata approach.
<Steve_Morris> we have lost the phone connection to the meeting
<Steve_Morris> can you please re-join?
Alex: Question is why don't we
mix tuner and sources together.
... The current model maps well onto current hardware
design.
... We have promises in the current model. If resources are no
longer available, then the promise fails.
... In my point of view, putting the two interfaces together
would help.
Francois: Keeping it simple for Web app developers should have priority over keeping it simple for implementers.
Chris: From a BBC perspective, I
would support having a more source-oriented approach.
... Methods that are promise-based can fail, so this should
address possible issues.
Steve: From an implementer
perspective, I would agree with this. It's not only easier for
developers, but also some cases are harder to map to the
current model.
... Some combination of broadcast channels over RF and IP
multicast can be tricky to address.
... Merging the interfaces would be more flexible and make it
easier for implementers.
[discussion on possible use cases]
Igarashi_San: I see two types of
application developers. Attaching a stream to a media element.
Then retrieving the EPG information might need a more
service-oriented model.
... I note that not so many devices have multiple tuners in
use, and often two tuners at most.
... Being able to know how many streams can be rendered at most
is useful information, to know if you can support
picture-in-picture for instance.
Chris: I think that can be
supported with a more source-oriented approach.
... We may need to expose a more "capability" type
method.
... I'm imagining that a Source gives you a list of channels,
and then you can get a stream that corresponds to a
channel.
[Steve detailing practical device capability constraints]
Steve: A source-oriented approach probably maps better to how hardware work in the end.
Chris: It seems to me that the
use of tuner in the interface is problematic, because it
implies a hardware component.
... We may want to separate the stream that could be presented
and rendered from the tuner itself.
... From a source oriented model, you could get a list of
sources you're interested, then you could ask the API to play
the current channel, and then you could do "next"/"previous"
channel in the list.
... If you create a single instance of the stream, I'm
wondering whether the media element can reconfigure itself.
Steve: I think that approach would work.
Alex: Reasonable approach to get rid of the tuner level. The complexity implied on the implementations is up to implementers.
Igarashi_San: I don't think that each channel should have a stream, rather a source would have a stream.
Chris: I think that would bring us to the source-oriented approach.
Steve: I don't think there is a useful distinction between primary stream and secondary (e.g. Picture in Picture) stream. We've made that mistake in the past.
[discussion around multiple streams]
Francois: Note that I think the
HTMLMediaElement is for the time being limited. Tracks are not
supposed to change over time.
... Different streams would likely introduce a gap when you
switch channels.
Steve: I don't think that's a big issue, there's always a gap when you switch channels.
Discussion around possible IDL interfaces:
interface TVManager : EventTarget {
Promise<sequence<TVChannel>> getChannels();
Promise<TVMediaStream> getStream(TVChannel? channel);
};
Igarashi_San: You need to introduce sources in that design.
Francois: Why?
Igarashi_San: All TV user interfaces are per source in practice.
Chris: Yes, I don't think it makes sense to flatten the whole list of channels.
More discussion on IDL, introducing sources. What happens when you issue a second call to "getStream"? Comparison with getUSerMedia. Idea is to check with WebRTC folks on how they address the lifecycle of media streams.
Question on where things fail. Probably preferable to fail the promise. Assigning the stream to a media element is probably just a question of where you want the stream to be presented.
Igarashi_San: I'd like to introduce the notion of tuner here.
Alex: I disagree, that does not seem needed.
Igarashi_San: Each tuner has a state linked to the service. Binding streams to a channel is problematic. I'd like streams to be bound to services, meaning the source.
Francois: I think it already is.
Igarashi_San: But how do you support multiple streams?
Steve: The way to get a first stream is easy. When you get a second stream, the question is why you want it? A second stream or a stream that replaces the first one?
[more discussion on single stream vs. multiple streams]
Steve suggesting a second TVMediaStream
parameter to getStream that provides the stream that the app is
ready to dispose of.
Igarashi_San suggesting to introduce back a
TVTuner interface available from TVSource.
Chris: Interrupting the discussion to stay on schedule. We'll get back to it this afternoon (see Back to Architectural issues below)
Jean-Pierre: Preliminary
discussion on metadata.
... [projecting slides]
... There are so many things in DVB-SI but I don't see anything
that exposes the metadata to the end user.
... You are not yet using the metadata that is in the
stream.
... The other option is about getting some metadata somewhere,
perhaps on the page or elsewhere.
... And then you want to link that back to the tuner.
... That's a completely different approach.
... Probably, if you publish the EPG, then when you select the
content, you'd like some way to reuse the API to access that
content.
... We have a missing link here. The spec does not allow
that.
... There are so many other things around multiplexing and so
on, but discussions so far seem be heading in the right
discussion.
Chris: This is really
interesting. Two cases: generic application that goes to BBC
web site which advertises the catalog, and if you happen to
browser that catalog on the TV, you could switch to the channel
directly.
... Right now, there is no proper way to map the catalog with
the list of channels that the TV Control API exposes.
Igarashi_San: This assumes that the metadata comes from the broadcast?
Jean-Pierre: No. I'm not saying that the metadata needs to be delivered on the channel.
Igarashi_San: What can be standardized, then?
Jean-Pierre: Probably today, we
cannot use the current API to make the link between the
published information and the information that comes out of the
API.
... It's not about standardizing the metadata.
Francois: I imagine it's still about aligning metadata exposed on the TVProgram interface with vocabularies that could be used to publish the EPG, e.g. schema.org vocabularies.
Jean-Pierre: For me, schema.org is useful to be hidden behind the page.
Francois: I think this triggers 2 actions for the group. One to align TVProgram attributes with common vocabularies, the other to allow an app to use published information to construct a TVProgram instance, which cannot be done right now.
Alex: The link is specified in some systems, for instance in RadioDNS. IDs can be easily assigned, and broadcasters know these IDs.
Jean-Pierre: If you have an EPG,
it's indeed probably easy to map it with published
information.
... Francois' point was about constructing an EPG from
published information when you don't have one to start
with.
Alex: In Germany, we have the DVB
EPG broadcasted with the streams.
... We may download the EPG from the broadcast, or we get the
same info from the RadioDNS XML EPG.
... If the channel has no broadcast EPG, can the application
use the metadata of the channel, the IDs, to get additional
information from published information on the Internet.
Jean-Pierre: It would be nice to have a graphic that gives the flow of data.
Mike_Assenti: This strikes me as an area where we should remain high-level. Even DVB has fragmentation.
Jean-Pierre: Yes, I think I'd like a high-level presentation.
Chris: Should we align the metadata that we expose to schema.org?
Jean-Pierre: I think schema.org is only used when you publish the information.
Francois: So we just need to ensure that there is an identifier that can easily be mapped across vocabularies.
Jean-Pierre: Yes.
... I'll continue to circulate ideas on this topic.
[Lunch break, restarting at 14:00]
Chris: We had a suggestion that
the getStream method should take an input parameter to make a
decision as to whether to reuse the existing stream or to
create another.
... Igarashi_San has been advocating the tuner object.
Igarashi_San: That would also help with keeping the amount of changes to the spec minimal.
IDL whiteboard discussions.
One possibility:
interface TVManager : EventTarget {
Promise<sequence<TVSource>> getSources();
};
interface TVSource : EventTarget {
Promise<TVTuner> tuneToChannel(TVChannel? channel);
Promise<sequence<TVChannel>> getChannels();
int getNumberOfTuners();
};
interface TVTuner : EventTarget {
attribute TVMediaSTream stream;
Promise<> stop();
Promise<> setChannel(TVChannel channel);
};
// Usage example
TVManager.getSources().then(sources => {
let source = sources[0];
source.getChannels().then(channels => {
let channel = channels[0];
// This would tune to the "current" channel
source.tuneToChannel().then(tuner1 => {
video.srcObject = tuner.stream;
});
// This would tune in to a specific channel
source.tuneToChannel(channel).then(tuner2 => {
video.srcObject = tuner.stream;
})
.catch(err => {
console.log('Oh no! No way to get a tuner');
tuner1.stop();
});
});
});
This doesn't work properly, because tuners are not interchangeable. A tuner may support HD, while another one may only support SD for instance.
Another solution could be to expose a
getTuners method on TVSource:
interface TVSource : EventTarget {
Promise<sequence<TVTuner>> getTuners();
Promise<sequence<TVChannel>> getChannels();
int getNumberOfTuners();
};
One question is how to select the tuner that can be associated with a given channel.
Alex: If I have DVB-T, DVB-C, and
DAB. I get 3 sources, then I get a list of channels and can
tune sources to a particular channel.
... That works for me. I can call tuneToChannel multiple times.
It may succeed 2 times, then the third time, the call may fail
because I ran out of tuners.
... In that case, I can release a tuner.
Igarashi_San: But then the application does not know which tuner is used.
Steve: Why would the application care?
Igarashi_San: Broadcast system and TV implementation.
Steve: I don't see why an application would care. It may care which source is used, but which tuner, I don't know.
Igarashi_San: But then, there may be a capability issue, if one stream is used for picture in picture, using SD, and the main stream is used for HD. If the HD tuner is locked for PiP, there is a problem.
Steve: But then what happens when you switch the streams.
Igarashi_San: I think this is a
scope issue. The model with getTuners support both regular Web
runtime and in-built TV device interface.
Steve: For PiP, for the whole
decoding pipeline, it does not matter whether you want to
render a small video. You'll have to decode 4K if the stream is
4K, period.
... I'm not clear what we mean by different capabilities of the
tuner.
Igarashi_San: For instance, HD
supported by hardware, or SD supported by software.
... In some cases, applications should know about such
capabilities.
Alex: The application developer
job will be more complex. He will have to know whether the
channel is HD to select the right tuner.
... It's much more complicated for the developer.
Chris: In the current API, we don't have the tuner capability exposed anyway.
Igarashi_San: Other standardisation efforts could extend the tuner definition.
Francois: What about adding a
TVCapabilities options parameter to tuneToChannel?
Igarashi_San: That does not address my need, because the receiver is still responsible for selecting the right tuner, not the application.
Steve: I think we're using tuner
wrongly here. I think we mean that we have the capability to
perform a certain number of "decodes".
... I think there may be value in being able to tell the user
agent a hint about capabilities, but I think it should remain
up to the user agent to select the right pipeline under the
hoods.
Francois: I would suggest creating an issue to address Igarashi-san need to let the application decide which tuner to use.
Igarashi_San: Other standardisation bodies may want to extend the specification there to distinguish tuners.
The takeaway from the discussion is that the group agrees to move to a source-centric approach for the API. The issue as to whether we expose the list of tuners or dynamically map channels to tuners remains an open issue at this stage.
Discussion should continue as part of issue #4.
Alex: I edited the spec,
independently of today's discussion on tuner and sources
... so that doesn't really impact the radio changes
... i added new interfaces for the radio use cases
... and had some discussion with Chris, but we were concerned
with duplicating the interfaces
... so there aren't many differences between radio and TV
... what i've done is to remove the TV prefix to make it more
generic
... I've added types for radio to SourceType, so dab, fm,
am.
... We have the same concepts: manager, tuner, sources, this
works for radio in the same way as TV
... With the Channel interface, we have a channelType
attribute, which could be a TV, radio or data channel
... The channel interface has transport stream id, network id,
which seems to be DVB specific. It may not apply in ATSC, or
other systems
... I've introduced a new interface, ChannelAttributes. Then
there are DVB and DAB specific ChannelAttributes
interfaces
... in DABChannelAttributes this contains the ensembleId and
serviceId
... I haven't renamed TVMediaStream, because MediaStream already
exists, but maybe we need a better name for this
... The other thing I added to Channel is getApplications() -
could be used to return MHEG or slideshow, dynamic label or
journaline for radio
... There's an editor's note on whether we should deliver the
application data or expose more application-specific
interfaces
... I haven't detailed out these application specific
interfaces
... I've left the TV specific interfaces in the spec using the
TV prefix
... I'm not sure about the EIT change
Francois: I agree about dropping the TV prefix, but we do need a common prefix for all our interfaces as they're all exposed in the Window
Chris: About the TVMediaStream interface, that's borrowed from WebRTC, extended to allow buffering and timeshifting. A better name could be BufferableMediaStream to make it less TV specific.
Steve: Could be BroadcastMediaStream.
Igarashi: There's a scope question about applications here
Chris: I don't think we'd want to support MHEG through this API
Alex: The Application interface
doesn't imply the implementation has to support MHEG or
similar
... In radio, we have slideshow, which in DAB terminology is
called a "User Application".
Igarashi: Would third party web
apps make use of the Application interface?
... We should clarify what would be used by broadcast services,
and what would be used by third party web apps
Chris: In terms of the categories we talked about this morning, what category of apps would use these Applications, eg, a general web app?
Alex: Yes, it could be used by general web apps
Francois: Would it be possible to write a few lines of code to show how these are used in practice?
Alex: Yes, I'll do that in a
GitHub issue
... [ shows HbbRadio interface example ]
... This web app has listeners for dynamic labels and slideshow
images
Igarashi: This is an example of a vendor specific UI?
Alex: Yes
... But this also supports broadcaster specific use of the API,
showing channel lists, and controlling radio playback
Chris: As the term 'application' may be overloaded, maybe we could call it BroadcastApplicatrion?
Toshihiko: On naming, a lot of the terms are overloaded, so we should find a name that fits the user perception: TV, audio
Steve: We could use LinearMediaStream, which avoids the problem with TV, radio etc
Alex: BufferedMediaStream more closely describes what it does
Chris: Is there similar work on streams in other groups?
<tidoust> MediaStream Recording draft spec
Travis: What are the differences between these streams and web delivered streams?
+Present Travis_Leithead
Chris: TV devices typically have a different state model than what the media element provides
Travis: When you pause the stream
in the Media Recorder API, the content between pausing and
resuming is lost
... This is like a local recording of the stream, there are no
signals back to the stream itself
... The assumption is that it's a continuous feed, or a linear
signal as you'd call it
<tidoust> [Discussion on MediaStream, TVMediaStream, and HTMLMediaElement and the possibility to buffer and timeshift]
Chris: Right now, the JS API does
not say anything about how the broadcast information gets
mapped onto the API.
... One question is whether the group feels this is in
scope.
... It seems like a big chunk of work.
Steve: I agree. My gut reaction
is that it's very useful if someone does that, but it's a big
ask.
... There are other organizations that have probably done some
of this already.
... We may find variations which make things hard to
specify.
Chris: Without specifying that, we leave things open to interpretation.
Steve: I'm wondering whether a
subset of that which could be doable.
... A subset that would avoid regional variations.
... In a previous life, I was editor of some of OIPF specs.
Some of these mappings were defined for the HTML mapping.
... There may be something there that we could borrow.
... I think there is work out there that we could use and build
on top of this.
Chris: There's also the sourcing in-band metadata spec.
Francois: Status and future of that spec is still unclear, although it's definitely useful. My gut feeling is that we should resolve the main issue in this group, which is to get traction and sufficient resources, including an editor, to work on the main spec, and not embark on another deliverable in the meantime.
Kumanan: Perhaps we should define an extension point, with a URN scheme and leave the rest up to other organizations.
[Discussion on the need for mapping to have implementers expose interoperable information]
The situation across the world is pretty horrible for channel and EPG metadata.
Some information is universally agreed on such as program title, start time, end time. There might be a minimum number of such information available.
-> Sourcing in-band tracks draft spec
Kumanan: There is consistency in
the metadata, for about 8 to 10 fields
... Take a look at the programme object metadata fields in OIPF
/ HbbTV, there are fields with 90% certainty that there'll be
there
... The OIPF might specify a mandatory set
[session resumes]
Chris: Access to parental control methods. Adding new functionalities always increases the fingerprinting surface.
Igarashi_San: Privacy considerations typically apply to "Type 3" applications, generic web apps in other words, right?
Chris: Yes.
... For content protection restrictions, if type 3 applications
cannot access channels, then the question is whether this API
is any useful at all.
... Type 1 (in-built) and Type 2 (broadcast applications) would
be the only targets, restricting the API to a small number of
potential authors.
Kumanan: Steve mentions that one
of the possible use cases could be a PC with a tuner
card.
... In that case, it's type 3, and the privacy problem is
probably to be dealt with as a permission.
... Similar to a conferencing case.
Travis: You may also want to restrict to secure contexts, top-level contexts, etc.
Kumanan: There are third party
applications that may run on the device. In our product, we
have two "modes", a "trusted" view and a Web view.
... In the Web view mode, it operates with all the restrictions
that apply to regular Web content.
Francois: So we need to look precisely at type 3 applications. Implementers may take some permissions for granted for type 1 and type 2 applications.
Igarashi_San: Yes, broadcast services will define that in their own specifications.
Chris: Let's say that I'm in a
BBC web page and schedule a recording. The list of recordings
becomes available. That's sensible from a privacy perspective.
For type 1, that's normal. For type 2, I'm less clear.
... Type 2 is broadcast-related application.
... HbbTV defines when the application launches. In our case,
we don't.
Kumanan: In that case, I would argue that BBC should not see my previous recordings.
Francois: Model is per origin.
Igarashi_San: I think we need to focus on type 3. The permissions, for me, will be defined per service.
Kumanan: In the PC with a tuner use case, I think the user should be in charge.
Igarashi_San: For privacy reasons, sure. But the restrictions in terms of access to broadcaster channels are a business issue.
Chris: Right, one concern would be the presentation of advertisements along the media stream associated with a BBC channel for instance.
Kumanan: DRMs could solve the
issue in the sense that BBC would own the keys and could grant
specific apps access to the streams.
... But then that seems out of scope for this spec.
Travis: The origin is strongly tied to the URL you're visiting in the browser environment.
Igarashi_San: A key to be able to use the API could help. This is similar to the EME case.
Travis: That seems similar to the
problem we're facing for the USB connection work. Allowing
arbitrary origins to access any USB device that I connect to my
computer.
... The current thought is that the browser vendors will embed
a whitelist of origins that are allowed to interact with the
device.
Kumanan: The TV with a tuner card
seems easy to me. The user will know it put a tuner on
purpose.
... The second case is the recording, and the restriction per
origin seems to make sense to me.
Travis: Unless you create another
type of local storage.
... When you're recording, the question is whether it is
something that you can carry, share.
Kumanan: The desktop world is a
strange case. Using two browsers, it will be hard to hide
recordings away from another browser for instance.
... Encryption of recordings would solve most of the issues. We
encrypt everything, unless a broadcaster absolutely wants us
not to encrypt a free-to-air channel.
[Discussion on master key and protection mechanisms]
Kumanan: We would want any application to be able to use this API to access my list of free-to-air channels.
Francois: They are less likely to complain about ad-injection?
Kumanan: There's not much that
can be done about it.
... If it's encrypted, then it's protected. If it's not, we're
not doing anything worse than what people are doing
today.
... We need to focus on the user.
... I think the spec should have some guidelines as to how
content can be protected, but it should not mandate things
there.
Chris: It is more a regulatory question than a technical question.
Discussion on whether recording should be in the first version of the spec or whether it should be in a separate spec. Viewing and recording to storage permissions seem separate. There's a bunch of complexity with recordings that the spec currently does not address as well. There are some regulations that require unencrypted content to be recorded unencrypted, etc.
Chris: The content protection restriction is a requirement that we brought late into the work.
Kumanan: I think watching should
be easy. Recording is the problem.
... Do we need recording in the first phase?
Chris: Some external organizations are looking at the spec. It's not entirely clear whether they need the spec as a whole, or could make do with different specs shipping at different times.
Chris: I think we've covered the
entire agenda. We've had some discussion in the morning session
between the relationships that we have between the interfaces
that we have in the spec.
... Some refactoring that still needs to be worked upon.
... We'll capture those in the issue tracker.
... Good steps forward!
... Discussion on metadata: Jean-Pierre took an action to share
with us some proposal on how we can better integrate with
existing schemas.
... Two aspects: a Web page with embedded data, can you map it
to the API?
... And then also the metadata that gets exposed to the
application. How is that represented?
... This afternoon, we had a look at supporting radio and
extending the API to support radio slideshows. Alex has taken
an action to look at some restructuring of the API.
... We need to agree on a prefix. Should it be TV? Should it be
Broadcast? Tuner? Linear? Live? Something else?
... We deep dived in the content protection restrictions as
well.
... That's it, really.
... The big remaining issue is that we do not have an
editor.
... We have great discussions but that needs to materialize
into spec changes.
... It could be a shared responsibility.
... The document has been largely untouched since late last
year.
... Thank you all for joining us today.