RE: Early Holiday Present: Settings API version 6

OK, I'll work on it.

- Jim

-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Thursday, December 13, 2012 2:44 PM
To: Jim Barnett; public-media-capture@w3.org
Subject: RE: Early Holiday Present: Settings API version 6

Yes, I think that would be a fine change to make. The state, capabilities, and constraints would still apply to the "photo-camera" source type, we'd just move the takePhoto and event to the recording proposal. 

In the recording proposal, takePhoto (or whatever we call it) could use the track's constraints, and also the track's source capabilities and state to take the snapshot. This could produce a high-resolution photo if the track's source is "photo-camera", or just a frame-grab otherwise.

Sounds very do-able.

-Travis

> -----Original Message-----
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> Sent: Thursday, December 13, 2012 5:42 AM
> To: Travis Leithead; public-media-capture@w3.org
> Subject: RE: Early Holiday Present: Settings API version 6
> 
> Does the snapshot capability belong in the recording draft?  It sure 
> looks like a recording/capture operation, right down to returning an 
> event with a Blob of data.  Admittedly it works on the Track rather 
> than Stream level, but that could be handled by having the Track be an 
> argument to the API call.  I think it looks a little odd to have one 
> record/capture function be a method on Track, while  all the others 
> are in a separate class.
> 
> - Jim
> 
> -----Original Message-----
> From: Travis Leithead [mailto:travis.leithead@microsoft.com]
> Sent: Wednesday, December 12, 2012 2:02 PM
> To: public-media-capture@w3.org
> Subject: Early Holiday Present: Settings API version 6
> 
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-
> capture/proposals/SettingsAPI_proposal_v6.html
> 
> This is the original (v5.1) planned revision of the settings v5 
> proposal, due 2 weeks from our last telecom. It contained enough 
> substantial changes that I bumped the planned version number.
> 
> Please read the definitions section (2) which sets out some of the 
> terminology and concepts that will make the rest of the document far 
> easier to understand.
> 
> (Brief) Summary of Updates:
> * Martin's proposal for getting the list of device identifiers 
> (sourceIds) is included
> * Bakes in concepts from Martin's synchronous gUM Option 3, notably:
>   - Tracks can take constraints in their constructors
> * "Settings" are now split into capabilities and constraints (there is 
> no more "settings" concept)
> * Further simplified the "source" model from prior proposals
> * Added a concept of "read-only" sources to better allow for either 
> file- backed sources or readonly device-sharing (born from EKR's 
> comments in the telecom).
> 
> -Travis
>

Received on Thursday, 13 December 2012 20:16:19 UTC