- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 29 Jun 2017 00:40:08 +0900
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
available at: https://www.w3.org/2017/06/28-webtv-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - Media and Entertainment IG - Cloud Browser TF 28 Jun 2017 See also: [2]IRC log [2] http://www.w3.org/2017/06/28-webtv-irc Attendees Present Alexandra, Colin, Kaz, Chris Regrets Chair Alexandra Scribe kaz Contents * [3]Topics 1. [4]UI scale 2. [5]UI visibility timing 3. [6]Media capabilities 4. [7]Identification 5. [8]MSE issues 6. [9]Accessibility 7. [10]TPAC 2017 8. [11]Next call * [12]Summary of Action Items * [13]Summary of Resolutions __________________________________________________________ alex: during the previous call ... we had a brief chat on the IG Note ... we can start over with the use cases ... have 2 points colin: updating the wiki page alex: quality of experience/service ... also MSE stuff ... let's go through the use case wiki UI scale colin: not in a formal description yet ... starting with "UI scale" ... resolution like a scroll bar ... could be scaled down in a cloud browser ... what is different with the cloud browser solution? ... that is the first use case alex: in your view, what would be the impact for APIs? colin: you could look up device pixel ratio, etc. ... and user resolution ... prefer using guidelines for this kaz: possible collaboration between a cloud browser and another screen like a smartphone? ... possibly included in "displayed in another way (e.g. in a PiP)" colin: yes, but Cloud Browser doesn't know how to send that information (at the moment) kaz: maybe we need another channel or connection for that purpose coline: yeah ... so would see existing guidelines for that kind of requirements alex: possible control channel between the cloud browser and the server ... but we also would see guidelines because this need is not the first one colin: cloud browser and abstract orchestration layer ... two different levels ... same for the devicePixelRatio as well alex: we can decide use cases and requirements first ... and then think about what kind of APIs are needed colin: ok ... let's move ahead UI visibility timing colin: "UI visibility timing" ... when does the end user sees the UI screen? ... Since the UI is terminated in the cloud it is hard to tell when the user actually sees it. alex: interesting Media capabilities kaz: fine ... but maybe we should call these topics as "difficulties" or "issues" as the starting point of concrete/detailed use case descriptions colin: ok ... (move ahead) ... on a cloud browser solution you would also like to know which types are played natively on the client device and which are transcoded. ... some examples of codec var support = videoElement.canPlayType('type=\'video/mp4; codecs="avc1.42E01E, mp4a.40.2"\); if (support == "probably") console.log("natively supported") else if (support == "virtually") console.log("supported by transcoding") ]] colin: existing APIs could be extended for cloud browser Identification colin: identification is also a problem with cloud browser ... for example, with geolocation api ... how to identify the cloud browser and its device? ... also we need a means to analyze the problems alex: we need to clarify our requirements and also existing APIs (=gap analysis) colin: and the WG side should make decision about concrete APIs ... will update these description to generate proper use cases (chris joins) chris: will check the minutes ... any concrete expectation from me? colin: now we're talking about Quality of Service/Experience kaz: "Quality" could include accessibility. right? colin: right. but we have another separate section for accessibility chris: what is the difference between QoE and accessibility? kaz: maybe we could ask Chris to review all the use cases including QoS/QoE, couldn't we? colin: indeed related to each other chris: accessibility/usability viewpoint colin: "usability" has some specific meaning for broadcasting alex: there is another viewpoint from telecommunication as well ... QoS may include latency issue ... another question is ... have you thought about latency and packet loss? colin: have not done yet alex: ITU recommendation on video quality and how to measure it ... also what is important for each user? ... big issue with operation ... big infrastructure for QoS ... the operator sees problems on what QoS is colin: need to clarify what is expected for cloud browser UI ... would highlight generic problems within this group kaz: possible intermediate proxy server for identification topic? colin: have wide channel use case ... you need to add some information if you have multiple cloud browser devices at the same geolocation kaz: a possible use case is a collaborative game by multiple users at some specific meeting room colin: need a mechanism of communication with each other for multi-user game alex: broadcasting vs unicasting colin: we should clarify delivery mechanism for each specific use case MSE issues alex: we have problems with MSE for Cloud Browser ... how we could adapt MSE for Cloud Browser? [14]MSE use cases [14] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/MSE [15]UC3 Cloud-based MSE support [15] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/MSE#UC-3_Cloud-based_MSE_support alex: explains the use case ... MSE is complex. Cloud Browser is also complex ... the mixture of them would be more complex ... we have a lot of steps within this UC ... split into 4 sub use cases ... 3.1 Execution of XHR 1. CB initiates a session with the CB client (session id, user id) 2. The CB client requests a web application that uses MSE for video delivery 3. CB executes the web application: CB parses the html and css data, web app sets the HTMLMediaElement 4. The web application requests the manifest (mpd, etc.) file and the CB parses it 5. The web application creates mediaSource objects and associates it with HTMLMediaElement 6. mediaSource creates sourceBuffer objects that in turn append media segments into the SourceBuffer array with the appenBuffer method 7. The web application defines the media segment URLs (with byte range params, video chunks id, etc.) 8. The web application sends the XMLHTTP Requests towards the media host to request these media segment 9. As the media segments are downloaded by the client, these XMLHTTP Requests are forwarded to the CB client by the CB. ]] alex: cloud browser doesn't know what request is being executed Gap1: in MSE the Web browser currently does not have any metadata information about the type of XHRs and therefore does not have any mechanisms to select the required ones. ]] colin: can understand the need but not sure how to implement it kaz: one possibility is bringing the requirements to the WoT WG later alex: problem with buffering, media segment, etc. ... would people to review this use case colin: will go through this uc again Accessibility chris: still struggling with what is expected for accessibility for cloud browser colin: maybe there are 2 different levels: OS level and DOM level chris: any suggestions? colin: for desktop PC browsers, there is alternative text ... how can we do that with cloud browser? ... there is an "Introduction" page: [16]https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_ TF/Introduction_cloud_browser [16] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Introduction_cloud_browser chris: each kind of operation ... how to maximize the availability kaz: currently the topics are rather list of keywords ... maybe you could elaborate concrete use case description, Chris ... also we could see the Media Accessibility User Requirements as the starting point: [17]https://www.w3.org/TR/media-accessibility-reqs/ [17] https://www.w3.org/TR/media-accessibility-reqs/ TPAC 2017 colin: are you going to attend TPAC 2017? alex: still checking kaz: Media & Entertainment IG will have its f2f meeting on Monday, Nov. 6th ... and we're expected to have a section on cloud browser there colin: agenda decided? kaz: the IG Chairs are generating the initial agenda ... and will have a whole IG call shortly Next call alex: next call in 2 weeks [adjourned] Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [18]scribe.perl version 1.152 ([19]CVS log) $Date: 2017/06/28 15:37:01 $ [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 28 June 2017 15:41:26 UTC