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

Re: Constraints and capabilities: revised proposal

From: Paul Neave <paul.neave@gmail.com>
Date: Tue, 24 Apr 2012 10:58:47 +0100
To: Dan Burnett <dburnett@voxeo.com>
Cc: public-media-capture@w3.org
Message-ID: <0A074806566E45E6BBB78DFD537B20AC@gmail.com>
Thanks Dan, good work. This is coming along nicely!  

> … Example:
> navigator.getUserMedia(
> {mandatory:[{videoMinHeight:600}, {videoMaxBandwidth:500}],
> optional:[
> {videoMaxAspectratio:1.333333333333},
> {videoMinTimebetweenrefframes:20},
> {videoMinFramerate:30},
> {videoEnumAutowhitebalance:on}]},
> gotStream, didntGetStream);

This request seems rather verbose with many objects and arrays declared. Is this how you intended it? A more simpler API might be something like this:

        mandatory: {
            videoMinHeight: 600,

            videoMaxBandwidth: 500
        optional: {
            // etc

with the first parameter consisting of an object of two objects, 'mandatory' and 'optional'. Personally I prefer the two separate callbacks for handling success and error rather than dealing with both cases in a single callback.

Also, where does the call for 'video: true' appear in this request? Is it inserted into the mandatory object?

> … This example requests a video stream with the properties shown. Note that if the browser can satisfy either a minimum time between reference frames of 20 or a minimum framerate of 30 but not both, then it will satisfy the former. Also, if the browser cannot, at the least, provide a video stream with a minimum height of 600 and a maximum bandwidth of 500, then the call to getUserMedia will fail.
In this case, I assume the error object returned to didntGetStream() would be filled with information about why the call failed and why, correct? Do you have any definitions for this?

> … Example:  
> [{id:camera001,
> capabilities:{
> videoEnumProvide: true,
> videoMinWidth: 800,
> videoMaxWidth: 1024,
> videoMinHeight: 600,
> videoMaxHeight: 768,
> videoMinAspectratio: 1.333333333333,
> videoMaxAspectratio: 1.333333333333,
> videoMinFramerate: 24,
> videoMaxFramerate: 60,
> videoMinPixelrate: 15,
> videoMaxPixelrate: 47,
> videoMinTimebetweenkeyframes; 20,
> videoMaxTimebetweenkeyframes: 40,
> videoMinBandwidth: 1.5,
> videoMaxBandwidth: 3.5}},
> […etc]

A couple of spelling issues here - camelCase seems to be missing in some names. Such as videoMinAspectratio should be videoMinAspectRatio, videoMinFramerate to videoMinFrameRate, videoMinPixelrate to videoMinPixelRate, videoMinTimebetweenkeyframes to videoMinTimeBetweenKeyFrames etc (and 'key', not as written earlier as 'ref' - videoMinTimebetweenrefframes)

Another issue I can foresee is defining the aspect ratio as a decimal figure. 1.333333333333 may cause a rounding problem, especially if the ratio is something like 1.777777778 for 16:9 (with the 8 at the end). UAs may struggle to implement this correctly. Perhaps this parameter for aspect ratio could be a number *or* a string, in the format 'X:Y', such as '4:3' or '16:9' etc?

> 9. videoEnumCameraDirection
> Definition of this constraint:
> Allowed values for this constraint are: "user", "environment"
> When returned as a capability: the browser MUST return the direction the camera device faces (the user or the environment)
> When used as a constraint: This constraint is satisfied if and only if the browser returns any video stream which faces in the direction given by the value.

This is a tricky one as technically there are could be multiple cameras connected to the user's computer. I assume this terminology is due to the more common use case in mobile devices with a front (user) and rear (environment) camera. However if a user attaches a USB camera to their laptop which already has an inbuilt (user-facing) camera, is this new camera a 'user' or 'environment' camera?

Perhaps other terminology could be used, such as 'front', 'rear' and 'external'? If the direction cannot be determined, 'external' camera is assumed.

Received on Tuesday, 24 April 2012 09:59:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC