Web&TV IG f2f meeting in Lisbon

19 Sep 2016

group photo
(Some more pictures are available on the W3C server. (Member-only).)

See also: IRC log


Mohammed_Dadas(Orange), Kaz_Ashimura(W3C), Mark_Vickers(Comcast), Paul_Cotton(Microsoft), Francois_Daoust(W3C), Hyojin_Song(LGE), Louay_Bassbouss(Fraunhofer), Cyril_Concolato(Paristech), Dan_Druta(AT&T), Eric_Carlson(Apple), Alexandra_Mikityuk(Deutsche_Telekom), Kazuhiro_Hoya(JCBA), Satoshi_Mishimura(NHK), Kinji_Matsumura(NHK), Tatsuya_Igarashi(Sony), Kiyoshi_Tanaka(NTT), Shi-Gak_Kang(ETRI), MiYoung_Huh(ETRI), Toshihiko_Yamakami(ACCESS), Kenichi_Nunokawa(Keio_University), Tomohiro_Yamada(NTT), Barry_Leiba(Huawei), JP_Abello(Nielsen), Koji_Ikuno(FujiTV), Ingar_Arntzen(Norut), Sungham_Kim(ETRI), Keun_Karry(IOT_Connected), Jungo_Kim(Entrix), Taewon_Kim(Entrix), Olivier_Thereaux(BBC), Hiroki_Endo(NHK), Mark_Watson(Netflix), Jean-Pierre_Evain(EBU), Nigel_Megitt(BBC), Chris_Needham(BBC), Colin_Meerveld(ActiveVideo), Giridhar_Mandyam(Qualcomm), John_Foliot(Deque_Systems)
Francois, Chris_Needham


participants 1 participants 2

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]

Status of the action items from last TPAC

-> 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.

Joint session with HME WG - MSE/EME requirements from Cloud Browser TF

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.

Joint session with HME WG - MSE/EME update

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]

Joint session with Timed Text WG

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.

-> BBC Subtitle Guidelines

-> 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!

Joint session with TV Control WG

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]

Cloud Browser TF

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.

Cloud Browser TF - Joint session with Web of Things IG

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.

Cloud Browser TF - interface between the cloud browser and the client

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.

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/10/03 12:47:17 $