RE: Screen capture

Unless I'm wrong, according to the v6 settings proposal, not all sources require to have a source identifier, like local files sources. Like files, screen/app might not require to have a source identifier.

-----Message d'origine-----
De : Travis Leithead [mailto:travis.leithead@microsoft.com] 
Envoyé : jeudi 31 janvier 2013 01:57
À : CAZEAUX Stephane OLNC/OLPS; public-media-capture@w3.org
Objet : RE: Screen capture

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 07:49:41 UTC