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 19:45:48 UTC