Need for 'zoom' constraint in Media Capture and Streams Specification

Request:
----------
Add a 'zoom' constraint to the Media Capture and Streams specification.

Background:
--------------
The current specification has specified constraints in the VideoStreamTrack constructor (see http://www.w3.org/TR/mediacapture-streams/#idl-def-VideoStreamTrack).  The current constraints defined (http://www.w3.org/TR/mediacapture-streams/#iana-registrations) that are video-specific are width, height, frame rate, aspect ratio, and facing mode.  These constraints are meant to apply to the video source, where a "source can be a physical webcam, microphone, local video or audio file from the user's hard drive, network resource, or static image."  Since a "physical webcam" would be the most likely video source for web applications leveraging the Media Capture and Streams specification, for the purposes of this discussion it is assumed that all constraints specific to the creation of a VideoStreamTrack would be applied to a webcam.  Since "webcam" is not defined in the current Media Capture and Streams specification, it is also assumed that a valid webcam could be an embedded camera in a smartphone (as opposed to only an embedded camera in a PC or a stand-alone camera).

As the work in the Media Capture Task Force has progressed, there have been new classes of devices that have launched without a W3C-standardized capture API that have been deployed with proprietary API's.  For instance, the mozCameras API associated with Firefox OS (https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozCameras) was developed, but acc. to the online documentation it "should be removed when the WebRTC Capture and Stream API<http://dev.w3.org/2011/webrtc/editor/getusermedia.html> has been implemented"  Note that this API lists 'zoom' among the defined camera control parameters (see https://developer.mozilla.org/en-US/docs/Web/API/CameraControl).

There is an Image Capture API (http://gmandyam.github.io/image-capture/) being produced by the Media Capture TF that is currently in draft mode that entails many necessary camera settings that do not have to be satisfied with the constraints mechanism in the VideoStreamTrack constructor.  However, this API leverages the VideoStreamTrack object and therefore 'inherits' any constraints applied in the creation of the VideoStreamTrack.

Problem:
----------
On first glance, 'zoom' might make more sense as a setting for Image Capture.  Since the Image Capture specification is in early stages without existing implementations let alone web applications making use of it, it may be possible to add this feature without much disruption.  However, camera preview leveraging a VideoStreamTrack is an issue.  Given how the VideoStreamTrack constructor is currently defined, it is not clear that settings provides in using the Image Capture API would be reflected in the VideoStreamTrack - this is certainly not required by either the Media Capture and Streams spec or the Image Capture spec.

A camera preview that reflects all camera settings (particularly those defined in the Image Capture spec) using the VideoStreamTrack is not feasible either.  However, adding a 'zoom' constraint to the VideoStreamTrack would provide a reasonable preview track suitable for image capture purposes without defining a new type of MediaStreamTrack.

Alternatives for camera preview if 'zoom' is not adopted as a constraint for VideoStreamTrack
------------------------------------------------------------------------------------------------------------------
This list is probably not exhaustive:


a)      Define an image-capture specific VideoStreamTrack.  There are examples of this (see https://developer.mozilla.org/en-US/docs/Web/API/CameraControl.getPreviewStream and https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html#picturedevicetrack-interface).  However, this was an approach that the Media Capture TF has already rejected.

b)      Add a 'zoom' setting and leverage the grabFrame() method defined in the Image Capture API (http://gmandyam.github.io/image-capture/#widl-ImageCapture-grabFrame-void) to create a frame-by-frame preview via drawing the captured ImageData objects directly to a canvas object.  The performance of such an approach, particularly on handheld devices, is unclear.

c)       Let 'zoom' adjustment only be possible via an end user's direct interaction with the capture device (e.g. pressing dedicated zoom buttons for the camera).

Look forward to any corrections, counter-arguments, and general comments.

-Giri