W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2013

RE: Screen capture

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 31 Jan 2013 00:56:50 +0000
To: "stephane.cazeaux@orange.com" <stephane.cazeaux@orange.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3853BC3031@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
According to the V6 settings proposal (https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html#source-states), the screen or some specific application, etc., could be requested as long as the screen/app/etc., could be identified with a specific "sourceId". The sourceType, in that case would be "readonly".

As mentioned, getting the id is the sticky point. Of course, we could simply reserve some common keywords for grabbing screens/apps, etc., that the user agent could process how they will, e.g., {sourceId: "screen"} or {sourceId: "app"}.

> -----Original Message-----
> From: stephane.cazeaux@orange.com [mailto:stephane.cazeaux@orange.com]
> Sent: Wednesday, January 30, 2013 9:37 AM
> To: public-media-capture@w3.org
> Subject: RE: Screen capture
> 
> Hi,
> 
> The screen capture (or more generally, the ability to use the screen or
> part of the screen as a source) is necessary to enable use cases where
> sharing is involved. And a "video communication with sharing" use case is
> stated in the IETF use case & requirements document.
> 
> Thus I don't think that we can defer it now. Or I should say, I don't
> agree to defer the use cases where sharing is involved.
> 
> Stephane.
> 
> -----Message d'origine-----
> De : Martin Thomson [mailto:martin.thomson@gmail.com]
> Envoyé : mardi 29 janvier 2013 22:49
> À : Jim Barnett
> Cc : public-media-capture@w3.org
> Objet : Re: Screen capture
> 
> Yeah, I find that particular use case less compelling than a "help my
> technically-challenged family member diagnose what is wrong with their
> computer".
> 
> In any case, if we don't want to do this now, then it's OK to defer it.
> 
> (I was reading the IETF requirements doc, which has a similar
> requirement.)
> 
> On 30 January 2013 06:43, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> > This is what's in the (unpublished) revised requirements draft (of which
> I am custodian).  It does call for general-purpose screen capture, but I
> wonder if we really want to tackle this:
> >
> > 5.1.1 Showcase demo on local screen (screen as an local media input
> > source)
> >
> > During the video conference call, Amanda invites a member of the product
> development team to demonstrate a new visual design editor for the
> prototype. The design editor is not yet finished, but has the UI elements
> in place. It currently only compiles on that developer's computer, but
> Amanda wants the field agents' feedback since they will ultimately be
> using the tool. The developer is able to select the screen as a local
> media source and send that video to the group as he demonstrates the UI
> elements.
> >
> > - Jim
> >
> > -----Original Message-----
> > From: Martin Thomson [mailto:martin.thomson@gmail.com]
> > Sent: Tuesday, January 29, 2013 4:22 PM
> > To: public-media-capture@w3.org
> > Subject: Screen capture
> >
> > I was just reading the use cases and requirements again and this one
> jumped out at me:
> >
> >    F30             The browser MUST be able to use the screen (or
> >                    a specific area of the screen) or what a certain
> >                    application displays on the screen to generate
> >                    streams.
> >
> > I don't believe that there is a way to express this in the getUserMedia
> API.  I believe that there was some talk of pulling media from a <video>
> tag, but that doesn't seem quite sufficient.  Is this an issue we want to
> address?
> >
> > Capturing content that is not normally visible to the application
> introduces some interesting questions.
> >

Received on Thursday, 31 January 2013 00:57:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:03 GMT