Reusing ConstrainablePattern for mediacapture-image? (was: Depth image capture workflow proposal for Web)

Hi Giri, All,

> On 24 Mar 2015, at 01:01, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> 
> Apologies for late response.  Also, note that some of my answers to the following is based on my recollections of discussions in the group over the past few years and may not be accurate:
> 
>>> what was the reason for not reusing the MediaStreamTrack.getSettings() accessor?
> 
>> getSettings() is specific to the constraints model. Giri was of the opinion that he wanted a simpler model for settings manipulation than the constraints model used on MediaStreamTracks.
> 
> Part of the reason for breaking out image capture functionality into its own spec was so that the MST could have a simpler list of settings that could the types of cameras seen in high-end smartphones and simpler webcams that could be used in typical WebRTC settings.

Thanks for shedding light on the design discussions.

Let's look at a concrete use case I think a web developer might want to tackle to make sure I've understood the current model correctly:

To obtain a blob that represents an image that is at least 640x480 pixels with red eye reduction turned on (omitting some details for brevity):

track.applyConstaints({ width: { min: 640 }, height: { min: 480 } });
var ic = new ImageCapture(track);
ic.setOptions({ redEyeReductionSetting: true })
  .then(ic.takePhoto().then(blob => console.log(blob)));

console.log(track.getSetting());
console.log(ic.photoCapabilities);

Is this correct?

Some observations by looking at the above:

What belongs to the MediaTrackSettings and PhotoSettings may not be clear to a web developer. Also the API shape is different. A potential API ergonomics issue, but not a blocker.

I thought a single interface for dealing with settings that provides the accessors, takes a property bag as an argument that can consisting of both generic properties and properties specific to a kind that operate on the MediaStreamTrack level would be easier to work with. The specialized interfaces would inherit from it.

But I'm hearing that did not really work for this case. Pointers to earlier discussions appreciated.

> I can also add that I don't think the constraints paradigm is applicable to camera settings.  Constraints define a sort of language that allows developers to list a range of conditions under which they would like to get access to a capture stream ("Constraints provide a general control surface that allows applications to both select an appropriate source for a track and, once selected, to influence how a source operates.").  In the case of ImageCapture, the source MST has already been created and used for the ImageCapture constructor.  Ergo the constraint model is not applicable.

All - I'm still interested in understanding whether the ContrainablePattern has been implemented. I recall active discussion on the merits of the model, so I'd like to gauge where we stand in terms of implementations now to see what would be the preferred means for depth extensions.

Thanks,

-Anssi

Received on Wednesday, 25 March 2015 16:45:08 UTC