RE: Presentation API usage: Mirroring vs Extension

Thx Mark for the explanation, I already played with Chromecast and Cast extension for chrome, it is the same flow as you described (using DIAL directly instead of  Presentation API). Is the tabCapture API available also for web pages or only for extensions?

Regards,
Louay

From: mark a. foltz [mailto:mfoltz@google.com]
Sent: Dienstag, 25. März 2014 02:29
To: Bassbouss, Louay
Cc: Min, Hongbo; Rottsches, Dominik; public-webscreens@w3c.org
Subject: Re: Presentation API usage: Mirroring vs Extension

[Catching up on old threads - sorry if this was answered/updated in a later thread]

We have considered the use case of allowing a page to "mirror itself" using the same mechanism as the chrome.tabCapture API [1].  I think this can be accommodated in the existing API by extending getUserMedia [2] with a media constraint that indicates a capture source of "self."  User permission and notification would be required for obvious reasons.

One model for how this would work if using WebRTC [3] (after the MediaStream is obtained):
(1) Page creates a local PeerConnection
(2) Invokes the presentation API to request showing a remote URL that implements WebRTC (i.e. knows how to play out the stream)
(3) Messages via the Presentation session to offer/answer and exchange candidates with the remote PeerConnection
(4) Remote agent renders the stream when media connectivity has been established

If a transport other than WebRTC is desired, the flow would look different; it may require adding specific support for self-mirroring via the Presentation API.  However, I assuming that it's still out of scope for the charter, I don't have anything specific to propose at this time.

Cheers,
m.

[1] https://developer.chrome.com/extensions/tabCapture

[2] http://dev.w3.org/2011/webrtc/editor/getusermedia.html

[3] http://dev.w3.org/2011/webrtc/editor/webrtc.html



On Sun, Jan 12, 2014 at 11:50 PM, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de<mailto:louay.bassbouss@fokus.fraunhofer.de>> wrote:
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<mailto:hongbo.min@intel.com>]
Sent: Montag, 13. Januar 2014 02:24
To: Bassbouss, Louay; Rottsches, Dominik; public-webscreens@w3c.org<mailto: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<mailto:louay.bassbouss@fokus.fraunhofer.de>]
> Sent: Friday, January 10, 2014 9:40 PM
> To: Rottsches, Dominik; public-webscreens@w3c.org<mailto: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<mailto:dominik.rottsches@intel.com>]
> Sent: Freitag, 10. Januar 2014 13:40
> To: public-webscreens@w3c.org<mailto: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.fraunhofer.de><mailto:louay.bassbouss@fokus.frau<mailto:louay.bassbouss@fokus.frau>
> nh
> ofer.de<http://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




--
http://wiki/Main/OnlyCheckEmailTwiceADay