Re: Screen capture

Sure, I'm actually thinking that the sourceId might not be the right
constraint to apply in this case, perhaps:
{ video: true, screen: true }

On 31 January 2013 09:56, Travis Leithead <travis.leithead@microsoft.com> wrote:
> 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 02:19:33 UTC