- From: Francois Daoust <fd@w3.org>
- Date: Mon, 26 Sep 2016 09:59:17 +0200
- To: <public-tvcontrol@w3.org>
Hi TV Control WG,
The minutes of last week's F2F at TPAC are available at:
http://www.w3.org/2016/09/20-tvapi-minutes.html
... and copied as raw text below. Let me know if you find inaccuracies that should be fixed or parts that need to be completed.
Discussions covered a number of open questions on the TV Control API specification, including architectural issues, purpose, metadata, radio and access control considerations. The group agreed to replace the current tuner-centric design with a source-centric approach (whether the list of tuners needs to be exposed remains an open question at this stage).
Reminder: The TV Control API specification cannot proceed without an editor!
Thanks,
Francois.
-----
TV Control WG F2F
20 Sep 2016
[2]Agenda
[2] https://www.w3.org/wiki/TV_Control/Meetings/2016-09
See also: [3]IRC log
[3] http://www.w3.org/2016/09/20-tvapi-irc
Attendees
Present
Chris_Needham(BBC), Tatsuya_Igarashi(Sony),
Louay_Bassbouss(Fraunhofer),
Colin_Meerveld(ActiveVideo), Jean-Pierre_Evain(EBU),
Francois_Daoust(W3C), Youngsun_Ryu(Samsung),
Hyojin_Song(LGE), Alex_Erk(IRT), Steve_Morris(Espial),
Shin-Gak_Kang(ETRI), Mikoung_Huh(ETRI),
Hiroki_Endo(NHK), Mike_Assenti(Dolby),
Kasar_Masood(Viacom), Toshihiko_Yamakami(ACCESS),
Kumanan_Yogaratnam(Espial), Travis_Leithead(Microsoft)
Chair
Chris
Scribe
Francois, Chris
Contents
* [4]Topics
1. [5]Walkthrough the API
2. [6]Brief review of open issues
3. [7]Architectural issues
4. [8]Metadata
5. [9]Back to Architectural issues
6. [10]Radio use cases and API changes
7. [11]Mapping to underlying protocols
8. [12]Permissions and access control issues
9. [13]Wrapping up
__________________________________________________________
[Round of introductions]
Walkthrough the API
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.
Brief review of open issues
-> [14]Open issues
[14] https://github.com/w3c/tvcontrol-api/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?
-> [15]Management of underlying resources
[15] https://github.com/w3c/tvcontrol-api/issues/3
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.
-> [16]List of tuners instead of just one tuner
[16] https://github.com/w3c/tvcontrol-api/issues/4
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.
-> [17]Use DOMTimeStamp
[17] https://github.com/w3c/tvcontrol-api/issues/5
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.
-> [18]WebIDL contiguous mode
[18] https://github.com/w3c/tvcontrol-api/issues/6
Francois: ReSpec no longer supports the WebIDL mode that we're
using, and that breaks the rendering. This needs an editor!
-> [19]Channel scanning
[19] https://github.com/w3c/tvcontrol-api/issues/7
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?
-> [20]Privacy and fingerprinting considerations
[20] https://github.com/w3c/tvcontrol-api/issues/8
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.
-> [21]Mappings to media delivery formats and protocols
[21] https://github.com/w3c/tvcontrol-api/issues/10
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.
-> [22]More flexible presentation restrictions requirements
[22] https://github.com/w3c/tvcontrol-api/issues/13
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.
-> [23]Access to parental control methods
[23] https://github.com/w3c/tvcontrol-api/issues/11
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.
-> [24]Radio API
[24] https://github.com/w3c/tvcontrol-api/pull/14
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]
Architectural issues
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.
-> [25]Priority of Constituencies
[25] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
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 [26]Back to Architectural
issues below)
Metadata
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]
Back to Architectural issues
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.
Radio use cases and API changes
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> [27]MediaStream Recording draft spec
[27] https://w3c.github.io/mediacapture-record/MediaRecorder.html
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]
Mapping to underlying protocols
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.
-> [28]Sourcing in-band tracks draft spec
[28] https://dev.w3.org/html5/html-sourcing-inband-tracks/
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]
Permissions and access control issues
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.
Wrapping up
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.
[End of minutes]
Received on Monday, 26 September 2016 07:59:27 UTC