Re: Screen capture

On 2013-01-31 03:19, Martin Thomson wrote:
> Sure, I'm actually thinking that the sourceId might not be the right
> constraint to apply in this case, perhaps:
> { video: true, screen: true }

Probably no-one remembers, but we demo'ed this in the Mountain View 
interim just about a year ago.

I our implementation the screen showed up as one more source to select 
for video in the UI that the browser displays as a result of 
getUserMedia with video: true.

But I think the screen deserves a separate constraint, just as you propose.

Stefan

>
> 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 07:52:47 UTC