- From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
- Date: Mon, 13 Jan 2014 07:50:02 +0000
- To: "Min, Hongbo" <hongbo.min@intel.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-webscreens@w3c.org" <public-webscreens@w3c.org>
Hi Min, Thx for clarification. We already use the chrome tabCapture API to mirror tab content on second screen (including Chromcast via Chromecast Plugin for chrome). I was thinking about a unified API also for screen Mirroring as for screen extension. For example using tabCaputure API with other technologies like WiDi, Miracast, Airplay, etc. Best regards, Louay -----Original Message----- From: Min, Hongbo [mailto:hongbo.min@intel.com] Sent: Montag, 13. Januar 2014 02:24 To: Bassbouss, Louay; Rottsches, Dominik; public-webscreens@w3c.org Subject: RE: Presentation API usage: Mirroring vs Extension Louay, Thanks for your diagrams. They are descriptive and informative. Regarding to the tab mirroring, Chromecast adopts an approach to use chrome.tabCapture API in combination with WebRTC usage, once a tab content is captured, WebRTC is used to stream the capture contents to remote side. See [1] and [2]. Another alternative but a bit complicated way is, both the first screen and second screen are showing the same URL, but any input events happened on the first screen should be also streamed to the second screen by window.postMessage (or you can access the window object of the screen screen directly to emit events, like window.open, since they are in the same origin,). In such a case, you don't need to rely on tab capture function. [1] https://groups.google.com/forum/#!topic/mozilla.dev.planning/FrfEwqs5FH8 [2] http://updates.html5rocks.com/2012/12/Screensharing-with-WebRTC > -----Original Message----- > From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de] > Sent: Friday, January 10, 2014 9:40 PM > To: Rottsches, Dominik; public-webscreens@w3c.org > Subject: RE: Presentation API usage: Mirroring vs Extension > > Thx Dominik for clarification. Please feel free to use/change the graphics. > > Best regards, > Louay > > -----Original Message----- > From: Rottsches, Dominik [mailto:dominik.rottsches@intel.com] > Sent: Freitag, 10. Januar 2014 13:40 > To: public-webscreens@w3c.org > Cc: Bassbouss, Louay > Subject: Re: Presentation API usage: Mirroring vs Extension > > Hi Louay, > > On 10 Jan 2014, at 13:46, Bassbouss, Louay > <louay.bassbouss@fokus.fraunhofer.de<mailto:louay.bassbouss@fokus.frau > nh > ofer.de>> wrote: > > >From my point of view, requestShow is suitable for screen extension > >as > depicted in the first two graphics (extension1.png for local > rendering, extension2.png for remote rendering). > > Thanks for the detailed diagrams. The first two are exactly what I > meant with the two possible implementation scenarios. I think it's > very useful to have these as diagrams to refer to. > > The question is how to realize mirroring as depicted in last graphic > (mirror.png). > > With regards to mirroring, we defined in the charter for the CG that > those scenarios are out of scope for the CG for now. [0] > > However, if Presentation API is implemented in Chrome, one possibility > is to use the tab streaming API from a Chrome app, see: > http://developer.chrome.com/extensions/tabCapture.html > The tab capturing stream can then be sent to the remote page, > implementing the mirroring case. > > Dominik > > [0] > https://github.com/webscreens/presentation-api/wiki/Second-Screen-Comm > un > ity-Group-Charter
Received on Monday, 13 January 2014 07:51:57 UTC