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> 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]
> 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
>
>
>


-- 
http://wiki/Main/OnlyCheckEmailTwiceADay