RE: Depth image capture workflow proposal for Web

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.

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.

-Giri

-----Original Message-----
From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com] 
Sent: Thursday, March 19, 2015 3:51 AM
To: Harald Alvestrand; Mandyam, Giridhar
Cc: Hu, Ningxin; public-media-capture@w3.org
Subject: Re: Depth image capture workflow proposal for Web

Hi Harald, Giri,

> On 19 Mar 2015, at 10:46, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> On 03/19/2015 09:30 AM, Kostiainen, Anssi wrote:

[...]

>> Harald, Giri - what was the reason for not reusing the MediaStreamTrack.getSettings() accessor? To my untrained eye it looks as if that'd allow us to drop the ImageCapture.photoCapabilities attribute that is specific to image capture, and reuse what MediaStreamTrack has to offer (I'm missing earlier discussions around mediacapture-image, so sorry if this has been discussed before).
> 
> 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.

What is the implementation status of the ConstrainablePattern [1]? Assuming the infrastructure is already in place, reusing it sounds like a reasonable path forward. Also, the mediacapture-main seems to encourage such reuse [2]:

[[

The Constrainable pattern allows applications to inspect and adjust the properties of objects implementing it. It is broken out as a separate set of definitions so that it can be referred to by other specifications.

]]

Unless there are technical reasons, I'd like to see whether we could make [1] work for the mediacapture-image, especially since I'm hearing no implementation has shipped yet.

Giri - what are your latest thoughts on this?

Thanks,

-Anssi

[1] http://w3c.github.io/mediacapture-main/#idl-def-ConstrainablePattern
[2] http://w3c.github.io/mediacapture-main/#constrainable-interface

Received on Monday, 23 March 2015 23:01:40 UTC