See also: IRC log
Mark_Vickers: [going through the agenda: joint session with the HTML Media Extensions Working Group (HME WG), then with Timed Text WG, TV Control WG and the rest of the day dedicated to Cloud Browser TF]
-> Kaz updates
Kaz: The TV Control CG
transitioned to a TV Control WG. Meeting tomorrow at
TPAC.
... ATSC update, Mark will talk about that.
... [going through updates while scribe was fighting against the polycom]
-> Mark Vickers's Web and TV IG updates
Mark_Vickers: The Web and TV IG
takes inputs from members and standards orgs, discusses use
cases and requirements. The IG does not do specs. From
requirements, we may file bug reports, or kick off work on new
APIs.
... Active task forces will meet today, Cloud Browser TF in
particular.
... The Media Pipeline TF is done but contributed requirements
for MSE/EME. It also lead to the work on Sourcing in-band
streams, developed in a Community Group.
... That spec is not properly implemented in browsers for the
time being. That's still a problem, and the CG is not really
active for the time being, future is unclear there.
... I'd like to mention the Web Media Profile work that we did
in the past. We put that on hold at the time, mainly because
HTML5 was not yet stable at the time.
... There is an update here with a new Web Media API CG that I
chair.
... The goal is to create a profile of HTML5 specs that are
widely supported across media devices.
... I plan to present this work during a breakout session on
Wednesday this week.
... Associated with CTA WAVE.
... The Home Network TF led to the work on the Network Service
Discovery specification. This got abandoned due to security
issues.
... The Timed Text TF pushed for TTM and WebVTT to be addressed
in the same group. There will be a joint meeting later
today.
... The Media APIs TF created a set of use cases and
requirements.
... This led to the creation of the TV Control CG, which
transitioned to a TV Control WG earlier this year.
... In terms of active Task Forces:
... 1. GGIE (Glass-to-Glass Internet Ecosystem) working on
identifying new technical work from media capture to
consumption.
... Main requirements are around content identification.
... In addition to that, the active work has transitioned to
IETF drafts.
... It's about addressing media segments directly with IPv6
addresses. The top of the address would be an identifier for
the content, then more details as you go down through the rest
of the address.
... There's work going on there. In the IETF since it touches
on IP address.
... From a W3C perspective, the TF is a bit on hold.
... 2. The Cloud Browser TF is really active. Led by Alexandra.
The afternoon will be dedicated to this TF.
... This work also brings some MSE requirements.
Alexandra: We kicked off the TF
in January this year. Our goal was to identify the use cases
and requirements for the interface between the client device
and the cloud part.
... We are done with the architecture. We basically started to
work on the use cases.
... We have started to work on EME and MSE because it's a
complex topic. We need to do some more work on the use
cases.
... This is just a first draft.
... For MSE/EME, the magic somehow happens in the cloud.
... The terminal is "dumb", it cannot do a lot.
... 3 different use cases have been identified.
... The first use case does not bring new requirements for MSE,
it's meant for legacy devices.
... The second use case remotes the API. Things are transparent
for the client.
... The third use case is the most interesting here.
... When the browser is fully in the cloud and when the MSE
magic fully happens in the cloud, this creates new
requirements.
... Some of the actions still need to be performed by the
client.
... The client needs to send requests on behalf of the cloud
browser.
... We're looking at solutions to inject identifiers.
... Another requirement is that the client should be able to
signal the available bitrate data to the cloud browser.
... There should also be a way for the Web application to e.g.
change the timestamps or manipulate the data somehow.
... A fourth requirement: there is no way for the client to
know which XHR request is getting appended by calls to
appendBuffer.
... This appendBuffer method should be able to signal to the
client only the changes to the data.
... Another requirement: the client loads the chunks in any
order. The chunk ordering must be made available to the client
and the different resources must be made distinguishable for
the CB client.
... One last requirement: XHR data does not necessarily
correspond with appendBuffer. The browser needs to be notified
about what and when data can be removed.
... Now looking at EME, again the third use case is the one
creating new requirements.
... There needs to be a way to associate the IP address of the
cloud browser with the address of the client, because both will
request the keys at license servers.
plh: I'm wondering how that
translates into requirements for EME.
... We don't care about the details of what keys contain. This
is opaque to the spec.
Alexandra: The key server could block things because it receives requests to use the same key from different addresses.
plh: My feeling is that this seems to be a requirement on the license server. But the EME spec does not address this.
Paul_Cotton: The fact that the
license server may be depending on the IP address of the cloud
browser. EME does not know anything about that. That may be the
case for some EME implementations.
... Why does the client also need to talk to the License
Server?
Alexandra: There is a more intelligent use case that does not appear on this slide where the cloud browser generates the UI and the video stream is processed by the client.
Paul_Cotton: OK, I do not know whether that's feasible but now I understand.
Mark_Vickers: The keys may also be retrieved by the cloud browser and used by the client.
plh: I don't think that works at all. Imagine a "play" event, since you're not playing the video on the cloud browser but rather on the client, you don't get the "play" event.
Alex: Yes, that's one of the MSE requirements I mentioned earlier.
Paul_Cotton: In effect, what you
want is you want to take part of the MSE/EME logic and move it
over into another process and define the interface between
these two different processes.
... You need to define all the communication going back and
forth.
... The logic is very event driven, events need to flow
back.
Mark_Vickers: Note there are
products that are deployed and used, done in a proprietary for
the time being. Right now, MSE/EME cannot be supported, at
least not in any standard way.
... The idea of the Cloud Browser TF is to see whether we can
standardize across these groups.
plh: This is somewhat sorcery to
me.
... Take the Youtube UI, there's an interface on top of the
video.
Colin: We render the UI in the cloud and send the video to the client.
plh: How do you do compositing?
Colin: We manage to do it on the client
Alexandra: There is of course some code that runs on the client.
Mark_Vickers: This is an industry
that is using Web technologies and does not get a lot of
visibility in the W3C world.
... It's used by millions across the world.
... MSE/EME is just one of the problems.
... That's a very interesting space. CE devices often have
longer lifetime than browser on desktops, the cloud solution
helps alleviate these constraints.
Alexandra: [clarifying the cloud browser architecture]
Mark_Vickers: MSE is running in a
"normal" way from a cloud browser perspective, and you're
worried about relaying what is happening on the front.
... That could just be a detail of your HTML user agent.
... In other words, it could be below the Web level. But if you
do that, you cannot develop clients that are independent of the
cloud browser part.
Alexandra: Right.
Mark_Vickers: If you want to do a
spec to define the interface between the front and back part of
your pipeline, it seems to me that you need a separate spec,
not embed it in MSE.
... The JS player in the MSE model makes a decision about
bitrates based on bandwidth and so on. Doesn't the client need
to live with whatever the bandwidth of the cloud browser
is?
Alex: That's one of the questions. Could the client communicate current bandwidth metrics to the cloud browser?
[Discussion on manipulating the data available on the client from the cloud browser, linked to one the MSE requirements]
plh: I think you'll have to have
limitations. You're not going to send video bits back to the
Web app, that's not efficient.
... For instance, if you take EME, you cannot take the bits
coming out of EME and put them in a canvas. That would defeat
the point of EME.
... In most cases, the client is not going to modify the bits
coming out of MSE, so you should be fine.
Mark_Vickers: I think that's a
good first taste of this cloud browser world.
... We welcome the vendors doing it who joined the discussion
the Cloud Browser TF. I'm really glad that people are
discussing this in W3C.
Paul_Cotton: Both specs are at
Candidate Recommendation phase. That's where we focus on
testing to check implementations.
... MSE is more advanced. We had a CfC last week to request
publication of MSE as Proposed Recommendation.
... The CfC passed, so I sent the transition request on
Saturday last week.
... We're anticipating going the call for review to the AC
soon. We're busy assembling the transition request.
... All of the relevant information is publicly available today
(issues, test suite, test results, spec).
... We're hoping to get a final Recommendation of MSE first
week of November.
... That would give us the first MSE Recommendation.
... EME is not quite as far along in the process as MSE.
... It's been published as Candidate Recommendation as
well.
... Since then, editors have made a number of editorial
changes.
... There's a lot of testing that still needs to be done for
EME.
... We have had a series of tests submitted by Google some time
ago but these tests need to be converted to Web Platform Tests
format.
... Mark Watson from Netflix has been doing a lot of this
work.
... When I talk about the results of the W3C test suite, you
can check the archives of the mailing-list.
... It is not clear to me or Philippe what the results are so
far. Implementers seem to have chosen different features in the
spec.
... I hope we'll have a better perspective within two
weeks.
... We already have a number of formal objections recorded for
EME and note there will be a public demonstration on
Wednesday.
... I think that's the status with EME. I cannot give you a
prediction as to when we can go to the Director for a
transition to Proposed Recommendation.
... I should note that the charter for the HTML Media
Extensions WG expires end of September, meaning next week.
plh: Let's be clear. If I don't
have a clear plan as to when the spec is going to be finished,
I cannot tell whether the Director will approve the extension.
This is serious.
... On the one hand, we have people telling us not to finish
EME. On the other hand, if people who care about EME do not
inject resources to finalize the spec, I cannot go and ask the
Director to extend the charter.
Giri: From a broadcaster
perspective, we've identified a hang up from a crypto
perspective on EME.
... Do we need an EME version 2?
... Why talk about version 2 if we still don't know whether
version 1 is going to be done in the end.
Paul_Cotton: There are 10s of features that we triaged out of v1. Version 1 does not solve everything that the community wants.
Giri: Would it make sense to include features in v1 right away since it's not done yet?
plh: No, let's be clear. I cannot recommend the Director to let the work on EME continue if we cannot get version 1 out soon.
Mark_Watson: Two problems. For
testing, there's not a lot of things that remain and it should
be easy to work on a proper plan to finalize the test
suite.
... Another problem is implementations, which fail some of the
tests.
... If we go ahead with progress on the Recommendation track,
we may not get implementers feedback that could improve the
spec. I'm fine with this approach, just noting that.
... I also note that DRM on the Web is a market need.
Mark_Vickers: I think that we
must finish v1. That's absolutely necessary.
... In terms of motion: committing testing resources should be
easy to do. For spec compliance, there are 4 codebases that we
are talking about, and I don't see what I can do there. I'd
like to hear from them what their implementation plans are.
Paul_Cotton: I made a suggestion this morning that bugs should be opened against implementations so that we can at least point out these bugs when we face the Director.
Mark_Vickers: Third thing is that I see some editing going on today.
Paul_Cotton: That's really editorial and normally that's done. David mentioned last week that he was done.
Mark_Vickers: Is there more we should be doing?
plh: How long is it going to take? That's the question.
Mark_Vickers: I guess that's what the F2F should discuss here at TPAC.
plh: If we don't have interop, the motivation for W3C is going way down. We need to solve this for version 1. And we need to do it fast.
<Zakim> wseltzer, you wanted to comment on politics
Wendy: On the politics front,
clearly there are some people who are misconceiving the role of
W3C here.
... Even if the market wants DRM, that does not necessarily
mean that W3C should recommend something in the area.
... There are valid concerns, e.g. around the possibility to
investigate these interfaces from a security perspective.
Giri: We seem to have interop
issues. Past experience in Geolocation WG, we went through a
lot of pain due to interop issues, but that did not mean the
spec died.
... Do we need to put some statement in favor of the charter
extension?
plh: You need to finish the spec.
Mark_Watson: I have a bit of a concern if we say that the fact that there are external protests should influence our internal process. I'm all fine to addressing the issues that have been raised against EME rationally, of course.
Mark_Vickers: I would add that
there is an interoperability milestone that has been achieved
already with MSE/EME, even though it involves polyfills which
is not entirely acceptable.
... We have deployments on the Web, using different codecs,
different DRMs.
... There used to be zero interoperability. Now we have content
that is independent of DRM that can be deployed across the
world.
... I'm not saying that's enough, but that's unprecedented in
the video world.
Paul_Cotton: [without Chair hat off]. I find it frustrating that W3C can charter a group like this, go to CR and then decide to kill the group. I find it phenomenal that after having chaired this group for several years, we hear that this work is at risk because it's not making enough progress, especially given the progress that was made in the last few months.
plh: With all due respect, previous re-chartering has been painful and something that I do not want to reproduce. I need a proper plan.
Mark_Watson: That seems like the usual way of doing specifications though. We don't have a lot of control on the implementation front. Other groups just carry on while there are issues to resolve.
Mark_Vickers: For example, Web Crypto.
plh: My problem today is that we
don't even know what we're lacking in terms of
implementation.
... I'm not blaming people here who have been active of
course.
... Don't tell me it's important to you if you did not put
resources into it since April.
Jean-Pierre_Evain: We all know that standardisation is about masochism and frustration. Nothing new here.
Paul_Cotton: I would suggest that those of you who are in the room and interested show up for the HME meeting today and tomorrow and contribute to the work.
[coffee break, back at 11:00]
nigel: The TTWG was rechartered
earlier this year (https://www.w3.org/2016/05/timed-text-charter.html)
with no significant change in scope.
... The TTWG is working on a draft of a Note, available as an
Editor's Draft at https://w3c.github.io/ttml-webvtt-mapping/
for mapping between TTML and WebVTT.
... The TTWG has published a Note listing profiles of TTML and
initiated a process to update the media type registration to
allow richer description of which profiles of TTML a processor
needs to support in order to process any given document.
... The TTWG published earlier this year a Recommendation for
Internet Media Subtitles and Captions, consisting of a Text
profile and an Image profile of TTML 1. This is known as IMSC
1.
... The TTWG is currently focusing on TTML 2 with amongst
others, the goal of supporting the text layout requirements of
every script globally. The group intends to update IMSC to IMSC
2 to incorporate changes that are appropriate for this use
case, from TTML 2.
Mark_Vickers: Some people talk about simplification of IMSC1. You talk about adding new features.
Nigel: I'm not aware of on-going plans to simplify IMSC1.
Giri: We're still struggling in the broadcast world with timestamped events. Is this being addressed by the on-going re-chartering process?
Nigel: Let' come back to that question
nigel: WebVTT's current status is Working Draft.
Mark_Vickers: Is the CG still active?
Nigel: Yes, it is. Some participants have moved on.
nigel: There has been increasing usage of various profiles of TTML by other standards bodies including SMPTE, EBU, DVB, ARIB and HbbTV.
Nigel: There's also some work
going on at MPEG on CMAF.
... There's a general issue with video media and timed text.
There can be mismatches between the aspect ratio of the video
and the rectangular box that is to contain timed text.
... That affects positioning.
... Then there's a general question on the management of
time.
Andreas_Tai: I'd like to address
one issue that I think could fit within the mission of the Web
and TV IG to identify gaps in existing technology.
... The issue is on how to make use of TextTrack and
TextTrackCue interfaces
... To add a TextTrack to a media element, there are attributes
that you can use.
... What is missing though is some way to identify the MIME
type of the track.
... One solution would be to add a "type" attribute to the
track element.
... That would be similar to the "type" attribute to the source
element.
... A TextTrack is a set of TextTrackCue. These cues are
defined in a format independent way.
... There are some events for when a cue gets active and when
it becomes inactive.
... Apart from the Edge browser, there is no way to initialize
a generic TextTrackCue.
... What is implemented is a specialization of the
TextTrackCue, in other words a VTTCue.
... You can initialize a VTTCue and then tweak it, which is
probably not the way that it should work.
... What could be done is to make sure that there is a
constructor for a generic TextTrackCue.
... We could go further and add an attribute for the payload.
Also we could define a new API for specialised TextTrackCue
(e.g. SubtitleCue or HTMLCue that got discussed last
year).
... I'm not sure what the Web and TV IG could do here, but that
sounds like the right place to gather requirements.
... We propose a breakout session on Wednesday to discuss these
issues.
Mark_Vickers: There is some
history on that issue.
... Another question is to understand what the user agent has
to do with text tracks that come within the transport
stream.
... This relates to the Sourcing
In-band Media Resource Tracks from Media Containers into HTML spec that is
currently in limbo.
... It's referenced by HTML5 but not implemented yet.
... We need a place to publish standard mapping between
transport standards and HTML5 types.
Giri: There are some timing
issues that become problematic with TextTrackCue. There are
additional delays triggered by the user agent having to process
the cues and so on.
... Is the effort on TextTrackCue going to look into
that?
... e.g. for tuning into a channel.
... There are other approaches, e.g. creating a new type of
cues, possibly done in CMAF.
Andreas_Tai: I think the "type" attribute would address some of this. The question for me is where should be the home of this issue.
Giri: I also encourage you not to start with WebVTT, but rather with TTML, SMPTE, beecause that's what the broadcaster world uses.
Andreas_Tai: To be clear, I don't propose to improve support for VTTCue. The TextTrackCue exists independently of that and we shouldn't be using VTTCue here.
Glenn_Adams: The VTTCue was meant to be generic although implementations have not implemented the generic aspects of it. DataCue was the closest thing to it.
Andreas_Tai: I encourage people to come on Wednesday to discuss this. I think the Web and TV IG is the right place to gather requirements.
Nigel_Megitt: Another topic I wanted to touch upon, is requirements for audio(video) description.
[presenting a requirements draft document]
Nigel_Megitt: My intent is for
TTML2 to support this. The intent is that any mixing directive
would be addressed by Web Audio.
... I submitted this doc to the Timed Text WG and to the Web
and TV IG.
... A couple of other things to mention: one of the things that
have been missing is how you implement accessibility
requirements for subtitles.
-> EBU-TT Live Interoperability Toolkit
Nigel_Megitt: From an EBU perspective, there's a draft specification around live interoperability toolkit to generate EBU-TT documents.
Mark_Vickers: Thanks for the great update!
Chris_Needham: The purpose of the
WG is to work on an API for sourcing media, such as TV and
radio from broadcast, IPTV, or other sources, allow their
presentation onto HTML media elements, and be agnostic of
underlying transport streams.
... It started in 2013-2014 within the Web and TV IG with a
couple of use cases related to tuner control. Following this,
we created a Community Group (2014-2016) to gather requirement,
compare existing APIs and draft an initial version of the TV
Control API specification.
... Mozilla was active in that group as part of their Firefox
OS for TV effort.
... We transitioned to a Working Group in April 2016 and
published a First Public Working Draft of the spec, which is
basically the same version as the one developed by the
CG.
... The spec addresses different features: enumeration of
tuners and sources, channel selection, playback, Conditional
Access Modules, Timeshifted plabyack, recording, etc.
... The WG may decide to split some of these features out of
the main spec.
... [showing examples of API usage]
... The interesting part here is the ability to associate the
MediaStream to a video element in HTML5.
... In terms of current work and next steps, there's some
effort to adapt the API to radio devices.
... We'd like to support radio as TV with this API.
... It brings some new requirements in terms of new information
to expose.
... We also collaborate with the Auto BG.
... User privacy is a big thing that we identified in the
group. At the moment, the spec does not define the execution
context that it runs under.
... There's a question as to whether the API is tied to the
runtime of the device, or whether the API is exposed to more
general applications.
... Some features could be fine for device runtime, but
probably not for general application runtime.
... Also, what are the access controls to media and metadata,
coming from content providers and broadcasters?
Giri: Will you be considering application-driven ad-insertion as part of this topic?
Chris_Needham: From a broadcaster perspective, this is highly relevant yes.
Giri: Are you thinking about integrating the Permissions API for features that could require a more privileged / device specific context?
Chris_Needham: That's a good
question. I guess we'll want to reduce the number of
interactions with the user.
... Integrating with the Permissions API seems like a resonable
approach.
Giri: In ATSC, we've been
considering that broadcasters could stream their own
application, similar model as in HbbTV.
... In that model, user privacy is somewhat less of a concern.
The open web is not really the target.
Chris_Needham: I agree.
... Issues for the group: there is a lack of editorial effort.
There is an open opportunity for anyone to take on the editor's
role.
... It would be interesting to know who's looking at this API
from TV industry groups, such as ATSC.
... More generically, we need more feedback from industries on
whether we're going on the right direction and support that
effort.
Mark_Vickers: Do you see this running only on tuner-centric devices? Or also on devices that do not have a tuner?
Chris_Needham: I see this as a
sourcing API. I have a slight concern about this being too
tight to the tuner hardware.
... If other groups could review the spec and provide feedback
on how well it aligns for other sources, that would be
great.
Mark_Vickers: So you're saying that this should work in situations where there are no tuners but that this hasn't been done yet?
Chris_Needham: Correct.
Mark_Vickers: Another question. The notion BBC2 is independent of its delivery mechanism. Is the name going to be BBC2 or will it be tied to the tuner and source?
Chris_Needham: I don't think
that's an aspect that the group has particularly been looking
at. It may be that these things vary, e.g. for regional
reasons.
... At the moment, the way the API is structured is that BBC2
streamed through a given source is different from BBC2 streamed
through another source.
Mark_Vickers: So I don't have a name that is independent?
Chris_Needham: Not
currently.
... In our meeting tomorrow, we do have a session on
integrating with metadata vocabularies. I think that's an
important aspect to cover.
... Existing published metadata should be available for
use.
Mark_Vickers: Yes, that's a problem I'm familiar with. Right now, there's no way to correlate sources with published data.
Chris_Needham: Anyone with an interest on that topic would be more than welcome.
Tatsuya_Igarashi: Comment on ad-insertion. The current spec does not really address this problem.
Chris_Needham: Correct.
Mark_Vickers: Thanks for the report. This concludes the plenary part of the F2F. Next on: the Cloud Browser TF.
[lunch break]
alexandra: [introduces the cloud
browser tf]
... the task force's mission is to look at use
cases for a cloud browser architecture
... and requirements for
interfaces between the cloud browser and client
... you can see the high level architecture on the Cloud
Browser TF wiki page
... The cloud browser is a flexible approach supporting
different ways of being deployed
Colin: The browser runs in a
cloud environment and streams the UI to the runtime
environment
... This displays the stream and sends information to the
cloud, eg, keypress or tuner information
... Also streaming of out-of band media
Alexandra: We have dependencies
on other groups, such as HTML Media Extensions, TV Control,
Multi-device timing, Accessibility platform architecture
... are there others to add to this list?
Louay: Also the Second Screen WG,
which has two specs: the Presentation API and Remote Playback
API
... We can reference the existing use cases, which are be the
same
... Maybe there will be additional requirements for the cloud
browser
<Louay> -> Second Screen Use Cases and Requirements
Alexandra: [some discussion of
what are dependencies and what is related work]
... I want the group to discuss what our final goals are,
different approaches
... Looking at what we've done so far, Deutsche Telekom have
been looking at the TV Control API
... We've written a Cloud Browser introduction on the TF
page
... It clearly describes what the CB is
... The introduction needs reviewing
... We'll produce an official document from this after
TPAC
... We're now half-way through use case and requirements, with
a plan to finish by end of march
... There are open questions, eg in terminology: zero-client or
runtime environment
Dan: Why not just call it the cloud browser client
Colin: This introduces some
ambiguity
... [Presents Introduction cloud browser]
Alexandra: I'd like people to review the Cloub Browser architecture
Alexandra: [ presents an overview
of the architecture page ]
... There are four approaches
... For each approach, we've assigned functionality between the
cloud environment, cloud browser, and client
... This work is ready to be finalised
Dan: How important is synchronisation, and has that been considered, eg, keeping the UI in sync with the media?
Alexandra: We have a use case for that
Colin: It is very important, it needs to be precise
Dan: How do you handle failures on the UI side, eg, if connectivity for the UI is lost?
Colin: This currently depends on the implementation, but would need to be standardised
Dan: Although you're trying to be stateless, this would some tiny piece of state information
Alexandra: Synchronisation is also important for accessibility
John_Foliot: Is the primary use
case here for video, or as a general purpose browser?
... What is the input mechanism? A traditional computer has a
keyboard or pointer or touch interface
Alexandra: So far we've focused
on video delivery, and input with a remote control
... It's not a remote desktop, more a TV user interface
Colin: We don't have solutions
yet for DRM bridging
... So far we've focused on architecture, but we should define
new use cases
Cyril: What about subtitles?
Colin: If these are rendered by
the cloud browser, it's easy, but needs synchronisation at if
rendering in the client
... Similar case for advertisements
Louay: If you send the timelines
for both streams, need to ensure all streams are in sync
... We should clarify synchronisation of multiple streams to a
single device, and synchronisation for companion devices
Ingar: If the cloud browser means moving functionality to the cloud, then synchronisation also moves to the cloud
Alexandra: We can capture these as several use cases
John_Luther: Is it a goal to standardise the control protocols?
Colin: Not at this stage, so far only use cases, but protocols might happen outside W3C
Dan: Synchronisation between devices is more a requirement than a use case
???: I agree, and the most critical point could be latency
<tidoust> scribenick: tidoust
[session resumes]
Alexandra: Thanks to everyone for
propositions in last session.
... Continuing with the use cases now.
... Core use cases are those that enable the communication
between the client and the cloud browser.
... That includes Control, State, Session, Communication use
cases.
... We have to think about Authentication use cases, whether we
have to include them in our task force or not.
... Then discovery and synchronization.
... The use cases appear on our Wiki.
... On top of these core functions, we have essential services
use cases for data exchange between the client and the cloud
browser.
... Here we have video and audio use cases, UI use cases. And
then of course security use cases.
... Also accessibility that we need to talk about.
... We put the major TV service use cases and went through them
to see if anything was missing from our core platform.
... This should be mapped onto core and essential services use
cases.
Tashiki: My sense is that these
use cases depend on how you articulate the cloud browser work.
For instance, you may have a low-level device with rendering
that happens on the cloud.
... Articulating the use cases depending on the type of cloud
browser will give different perspectives.
... Sometimes, there is very limited power to embed a browser.
In that case, the UI use cases viewed from a client perspective
seems out of scope for W3C.
... I have no objection to doing the work to identify
requirements at W3C, but work may need to be done outside.
Colin: Right, when we started this work, we thought in terms of use cases, but then we realized that people had different things in mind when referring to cloud browsers. So we worked on an architecture document to start with, instead.
Louay: They are two types of
synchronization: multiple stream synchronization and
multi-device synchronization.
... As a core function, we could have multi-stream
synchronization. Multi-device synchronization would be at the
essential services.
... We don't need to have a use case for multi-device
discovery, communication and synchronization. We can reference
the Second Screen Presentation API there.
Colin: We don't use discovery in practice, but there may be a future need for this.
Alexandra: Use cases have question marks. We still don't know if we're going to include them or not.
Colin: Maybe this is a good opportunity to discuss whether this is in scope.
Alexandra: What is your perspective on authentication?
Chris: What are the use cases that drive this?
Colin: I don't think we have any for authentication for the time being.
Kang: Are we talking about authentication with a server?
Alexandra: We were thinking about
authentication between the client and a server. I don't know
whether it is in scope of not.
... We have identified control use cases. They still have to be
reviewed.
... TF participants are encouraged to review the use cases.
Others may chime in as needed. Work happens in public.
... For state, we have e.g. tuner state, which relates to the
TV Control API.
... For session, use cases are somewhat similar to the control
use cases and we had a discussion on whether they could be
merged. For the moment, we kept them separate.
... For communication, we have a use case but it needs to be
re-written following the use case template.
... I wasn't clear whether we have requirements derived out of
that use case.
Colin: Right, that still needs to be assessed.
Alexandra: For security, we'll
discuss with the Web of Things IG. Based on side discussions
with Louay, maybe we do not need to decide in the TF.
... Discovery could be part of a multi-device use case.
... Same for synchronization, where multi-stream
synchronization should stay here but multi-device sync should
be moved to multi-device use cases.
... Moving on to essential services use cases. The payload
between the client and the cloud browser.
... Here, we have identified a video use case (mse and tuner
use cases).
... We mentioned MSE use cases in the morning during the joint
session with the HTML Media Extensions Working Group.
... Review is missing for tuner use case.
... Some low-level approach could perhaps lead to a situation
where no update is needed to MSE. But of course, there are
drawbacks with any approach.
... We also have an overlapping use case for video. The
question is whether it's a real use case.
Colin: It does not seem so.
Alexandra: it needs to be performed by the client and not provided by the API?
Colin: Right.
Alexandra: Then we have the
audio. The background of this use case is accessibility where
you provide some sound effect. It will reference the
synchronization use case.
... Not sure whether the group wants to address this as a use
case.
... I'll take this to John.
Kang: We're also think about double streams for audio, right?
Colin: When we say video streams, we mean media streams.
Alexandra: That's a good comment,
maybe we should update the term.
... I'm not clear whether there's an accessibility API that
browsers need to support.
... I think the UI EPG use case can be handled as part of
normal function use cases. To summarize, the AIT table is
available on the client, but to build the EPG, we need this
info to be shared with the cloud browser.
Kang: In the IPTV case, that's not really the case.
Alexandra: Sometimes we get
different IDs for channels and we need to fuse them, that can
be very tricky.
... We also have the UI Switch that was brought by
Entrix.
... On very old browsers, we cannot deliver Youtube for
instance, and that's when you'll want to switch to a cloud
browser.
Colin: More generically, how you
execute native applications on the client. It could be through
a Web browser.
... In a cloud browser architecture, you would like to have
everything in the cloud, even the main device UI.
Alexandra: So, that's the
interface between cloud browser and client app
environment.
... For security, we have EME use cases with two different
approaches, including a complicated one where you try to
duplicate things across the client and cloud browser.
[Discussion on accessibility requirements, in relation with the Presentation API, the Remote Playback API and the Cloud Browser TF. Mentioning Media User Interface Accessibility Requirements: http://www.w3.org/TR/media-accessibility-reqs/ ]
Alexandra: Going through
essential services use cases. Most need to be described (VoD,
timeshift, Ad-insertion, gaming, etc.)
... We have added the catch-up service as well. Also the
OTT-based video app (amz, nflx) use case.
Louay: About HbbTV, maybe use Hybrid TV application, because it could be HybridCast or some other standard.
Alexandra: OK.
... The exact scope of this task force is not entirely settled
but that can probably be done over time.
Alexandra: No specific agenda, we
just thought it would be useful to discuss.
... [presenting the cloud browser task force]
Joerg: Chair of the Web of Things
IG.
... We're coming from quite a different side. We'd like here to
keep you informed, not sure how much of it will be
useful.
... Status update and on-going AC review on the proposed Web of
Things WG charter.
... We're trying to interconnect silos. Different application
domains such as consumer home, transport, health, cities,
etc.
... The goal is to find synergies.
... IoT is very much looking at how you can share information
across these domains. WoT is looking at how you can develop
applications across these domains.
... We're looking into this, e.g. because there are much more
Web developers than embedded developers (711000/3800 looking at
LinkedIn profiles).
... Also we want to make applications easier to write to enable
the long tail marked for embedded devices. Also Web
technologies are useful for Web-grade multi-stakeholder
security.
... That's quite interesting to see how we can learn from the
Web here.
... Finally, it helps simplify the integration of embedded
devices.
... Now, this opens a number of questions around scope. We
don't want to be too open and generic, and don't want to be too
specific either.
... The first four questions we identified: discovery, how do
things find each other? How do things describe themselves?
Privacy and Security? Scripting APIs?
... Standardization at the IETF is taking care of the
protocols.
... So information can be exchanged. To be able to make
applications, we need to make additional building blocks.
... The IG has quite a lot of different companies in
there.
... We started to work in Sprint 2015 on use cases and
requirements. This is tricky.
... We're doing plugfest to prove the interoperability of our
proposed solutions.
... Looking a bit more at the inside, we have the "Servient",
which can be running on the Server or on the Client.
... The resource model describes what the thing can
achieve.
... Different protocols can be used through protocol bindings,
e.g. CoAP.
... The Thing Description allows you to discover what that
thing is doing and how you can interact with it.
... [going through plugfest example]
Alexandra: Thank you for the introduction.
Alexandra: When we started this
work, we thought we'd be able to come up with a browser API
that we could propose to browser vendors. So we started to
work. There are lots of graphic-related tasks.
... The basic question is: do we try to make an API for the
browser? Or do we work on the level below, which could end up
being developed at IETF?
... If we have an API, the application will need to use it,
which gives it more control.
... [projecting some open questions on screen]
... These questions might change during the discussions.
Louay: From my perspective,
having worked on the Presentation API. For now, there are
different implementations of the API on top of different
protocols.
... From an application perspective, it's the same application.
Of course, it's not interoperable between implementations, but
that's the goal of the new work being carried upon by the
Second Screen CG.
... Here, it could be similar if we develop an abstract API
that could be implemented on top of different protocols.
... I think this approach could work.
... In the future, interoperability between different browsers
is better.
... It may not be W3C specifications, maybe IETF specs.
Francois: What consumes the API? No Web runtime on the client, right?
Colin: It depends, there may be a low-end browser runtime on the client, and the app may be willing to connect to a Cloud Browser.
Francois: OK, so you want a way to retrieve a MediaStream out of a Cloud browser and then pass on events and the like in between the devices. That resonates with some v2 use cases for the Presentation API where the group may consider cloud-based second screens.
Kaz: When we say API here, it
does not necessarily mean a JS API, right? It could be an API
between the client runtime and the cloud browser runtime. It
would be built on top of WebSockets for instance.
... In the Automotive group, the group has been talking about a
sockets-based approach.
... The Cloud Browser TF guys might want to connect with Auto
folks tomorrow.
<kaz_> Vehicle Signal Server specification by the Automotive WG
Alexandra: Maybe it's interesting
to take a look at who would like to implement this possible API
in devices.
... Thanks for your participation.