W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2012

RE: Proposal for Still Image Capture

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Tue, 21 Aug 2012 21:48:18 +0000
To: Travis Leithead <travis.leithead@microsoft.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A162C48F0@nasanexd01h.na.qualcomm.com>
Hello Travis,
Thanks for your feedback.  You raise a valid concern, but I assume that the burden is on the developer to account for situations where the UA cannot determine the type of media capture devices available to it.  For instance, the camera_select constraint I designated in my example as mandatory can always be made optional if the developer still wants the stream created when the UA cannot determine if the camera present is front-facing.  

I think there is a more general problem with the way gUM is currently defined in that the API has no clean way of handling the situation where there are more than one capture device of a particular type (audio or video).    If we don't want to address this through the use of constraints, then should there be something similar to the mechanism to query available cameras in the old System Info API spec (http://www.w3.org/TR/system-info-api/)?  At least then the developer would know definitively if there are two cameras available on the device without having to invoke gUM with a mandatory constraint setting.

-Giri  

-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Tuesday, August 21, 2012 2:03 PM
To: Mandyam, Giridhar; public-media-capture@w3.org
Subject: RE: Proposal for Still Image Capture

> From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
> 
> Hello All,
> Since the Recording API is on the agenda for the upcoming telco, I'd 
> like to put forward for the group the enclosed proposal for still 
> image capture.  The "Simple image capture API" is still listed on the Wiki under Open Items.
> 
> Please note the following:
> 1. This proposal has commonalities to the Camera API proposed on 
> Qualcomm's developer website:
> https://developer.qualcomm.com/docs/html5/api/camera.html.
> 2.  The "Feature Keys" listed in the enclosed doc are not defined in 
> the doc itself.  Please refer to the above website for a further 
> breakdown of the proposed individual values for the keys and if 
> applicable the returned values if a feature key is set.
> 
> I look forward to feedback.

I had to chuckle at your example code use of constraints:

navigator.getUserMedia({video:{mandatory:{minHeight:300,minWid th:600,cameraSelect:'front'}}, gotStream, noStream);

Naturally, setting a mandatory constraint for a 'front' camera, according to your own document, would limit every device for which the front/back-ness of a camera could not be determined. This is a pretty innocent example, but underscores my point about easily over-constraining getUserMedia. An implementation of this would probably have to tweak the cameraSelect constraint to say that "unknown" was the same as whatever mandatory constraint was requested :) I just don't want to go there.
Received on Tuesday, 21 August 2012 21:48:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:11 UTC