W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2014

Re: About the Mandatory constraints

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 6 Feb 2014 09:38:52 +0000
To: cowwoc <cowwoc@bbs.darktech.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A0F3@ESESSMB209.ericsson.se>
On 2014-02-06 05:28, cowwoc wrote:
Hi Stefan,

Correct me if I'm wrong, but doesn't the Capabilities API enable developers to query a camera's capabilities, before invoking getUserMedia(), all without triggering a prompt?

No, I don't think so. getCapbilites is available on (Constrainable of) MediaStreamTrack; that track is in turn connected to the camera (as an example).

But to get that MediaStreamTrack you need to call getUserMedia - so without it there is no "getCapabilities".


If so, why do we need mandatory/optional constraints at all? The developer can filter the reads of getCapabilities() and judge for themselves if their desired constraints are met or not. The constraints API is always going to be less expressive than a developer querying and filtering through the Capabilities themselves.

I am expecting something along these lines:


  1.  var capabilities = Camera.getCapabilities();
  2.  var preference = pickBest(capabilities); //application-specific definition of "best"
  3.  If "preference" is undefined, the mandatory constraints were not met. Display a user-friendly error message and quit.
  4.  Otherwise, invoke: getUserMedia(preference); //Provide a specific mode to open the camera in
  5.  If the operation fails (the user disconnected the camera between steps 1 and 3) go back to step 1 and try again.

Gili

On 05/02/2014 1:34 PM, Stefan Håkansson LK wrote:

There has been some discussion about mandatory constraints again lately
in the context of constraints for the MediaStream Recorder.

I think the use of constraints for the Recorder is something we have not
really discussed yet, but I think (though I may be wrong) some mails
tended to question the need for mandatory constraints also for gUM.

Just to be clear: I think we have debated the mandatory constraints for
gUM several times, and we always come back to the same conclusion:
people want them. One use is when the app developer wants to avoid
disturbing the user, or even indicate e.g. that video communication is
possible, if the equipment does not fulfill the requirements the app
developer has.

Some people think it would be more natural to just get access to the
camera (and in the process launch a prompt), then check what it can
fulfill the needs, and if not tell the user that "sorry, your camera is
not good enough". But those developers can skip using mandatory constraints.

Let's not debate if we need mandatory constraints or not for gUM again.
I think it would be much more fruitful if we could have the details in
Constrainable reviewed for use with gUM and MediaStreamTracks. I would
be really happy we could nail a design that fulfills the needs we have
there.

Stefan
Received on Thursday, 6 February 2014 09:39:17 UTC

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