RE: Early Holiday Present: Settings API version 6

Here's a detail involved in moving takePhoto to the Recording class.  takePhoto will now need to take an argument indicating the Track to take the photo on. So the question is how to do that.  I can see 3 possiblities:

1. We could make that argument be of type Track, but then someone could pass in a Track that was not a member of the MediaStream that was passed to the Recorder() constructor.  I think that we should signal an error in that case.

2.  The argument could be the index of the track in the MediaStream's videoTrackList.  There could still be errors if the index was out of bounds, but otherwise it's reasonably constrained.  This might be a bit difficult for the app, though, since it would have to figure out what the index was (on the other hand, if you assume there will normally be only one video track, it's pretty easy.)

3.  We could add a separate constructor Recorder(Track track).  Such a recorder could be used only to take photos.  However, then the UA would have to deal with all the error cases of apps calling takePhoto on a Recorder that was constructed with a MediaStream, etc.

Of these options, I think that 2 is the best, 3 is the worst, and 1 is possible, but a bit awkward.  On the other hand, 1 matches the DTMF Sender API, so it's more consistent with the rest of the spec.  

Anyone else have an opinion?  Harald, what will the DTMF API do if the app passes in a Track that's not part of the PeerConnection?

- 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 Friday, 14 December 2012 14:55:24 UTC