Re: Presentation API usage: Mirroring vs Extension

Hi Louay,

Apologies, realized that I think you didn't get an answer on this - the
current tabCapture API is available for extensions only at the moment.

Mark.


On Tue, Mar 25, 2014 at 1:16 AM, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

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