- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 4 Oct 2016 00:34:10 +0900
- To: Francois Daoust <fd@w3.org>
- Cc: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
- Message-ID: <CAJ8iq9XbEYSQMvgJd=pBaB17_-EF9oEJkcMRpPLRz=HhdMKONw@mail.gmail.com>
Thanks, Francois! I've added several photos to the minutes :) Kazuyuki On Mon, Sep 26, 2016 at 4:52 PM, Francois Daoust <fd@w3.org> wrote: > Hi Web and TV IG, > > The minutes of last week's F2F meeting are available at: > > https://www.w3.org/2016/09/19-webtv-minutes.html > > ... and copied as raw text below for archival. > > The group held a number of joint meetings with the HTML Media Extensions > WG, the TV Control WG, and the Timed Text WG in the morning. The Cloud > Browser Task Force met in the afternoon. Minutes are rough and sometimes > possibly incorrect. Feel free to get in touch to have them fixed or > completed! > > Thanks, > Francois. > > > ----- > Web&TV IG f2f meeting in Lisbon > > 19 Sep 2016 > > See also: [2]IRC log > > [2] http://www.w3.org/2016/09/19-webtv-irc > > Attendees > > Present > 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) > > Chair > Mark_Vickers > > Scribe > Francois, Chris_Needham > > Contents > > * [3]Topics > 1. [4]Status of the action items from last TPAC > 2. [5]Joint session with HME WG - MSE/EME requirements > from Cloud Browser TF > 3. [6]Joint session with HME WG - MSE/EME update > 4. [7]Joint session with Timed Text WG > 5. [8]Joint session with TV Control WG > 6. [9]Cloud Browser TF > 7. [10]Cloud Browser TF - Joint session with Web of > Things IG > 8. [11]Cloud Browser TF - interface between the cloud > browser and the client > __________________________________________________________ > > 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 > > -> [12]Kaz updates > > [12] https://www.w3.org/2016/Talks/0919-webtv-ka/ > > 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] > > -> [13]Mark Vickers's Web and TV IG updates > > [13] https://lists.w3.org/Archives/Public/public-web-and-tv/ > 2016Sep/att-0021/2015-09-19_WebTVIntro_v2_.pdf > > 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 > ([14]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 > [15]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. > > [14] https://www.w3.org/2016/05/timed-text-charter.html) > [15] https://w3c.github.io/ttml-webvtt-mapping/ > > 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 [16]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. > > [16] https://dev.w3.org/html5/html-sourcing-inband-tracks/ > > 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. > > -> [17]BBC Subtitle Guidelines > > [17] http://bbc.github.io/subtitle-guidelines/ > > -> [18]EBU-TT Live Interoperability Toolkit > > [18] http://ebu.github.io/ebu-tt-live-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> -> [19]Second Screen Use Cases and Requirements > > [19] https://github.com/w3c/presentation-api/blob/gh-pages/uc-req.md > > 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 [20]Introduction cloud browser] > > [20] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_ > TF/Introduction_cloud_browser > > Alexandra: I'd like people to review the [21]Cloub Browser > architecture > > [21] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_ > TF/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: > [22]http://www.w3.org/TR/media-accessibility-reqs/ ] > > [22] 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_> [23]Vehicle Signal Server specification by the > Automotive WG > > [23] http://w3c.github.io/automotive/vehicle_data/ > vehicle_information_service.html > > 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] > > > -- Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo Tel: +81 3 3516 2504
Received on Monday, 3 October 2016 15:35:55 UTC