- 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