- From: gmandyam via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Dec 2016 00:54:58 +0000
- To: public-media-capture-logs@w3.org
@stefhak I did provide my view on applicability of constraints to ImageCapture in the discussion on https://github.com/w3c/mediacapture-image/issues/73. In addition, I would note the following. Apologies for any clumsy wording. a) The contraints mechanism is already leveraged in ImageCapture, as the constructor (https://w3c.github.io/mediacapture-image/#ImageCaptureAPI) uses a track to which constraints have been applied. b) That being said, constraints (in my opinion) add value when there is some form of contention. By 'contention', I am describing a situation where for instance multiple tabs in the active browser context require media capture, each with their own individual requirements. However, for ImageCapture this kind of contention is not applicable as the ImageCapture object is constructed using a track that has already been created based on the browser constraint resolution. c) It is still unclear (to me at least) whether developers have fully understood the constraints concept in the context of MediaStreams and actually found value in using them. In that respect, I am concerned about causing developer confusion by adding a constraints-on-top-of-constraints mechanism. For instance, developers may ask why they cannot apply image capture constraints directly to the media stream itself. -- GitHub Notification of comment by gmandyam Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/124#issuecomment-267204437 using your GitHub account
Received on Thursday, 15 December 2016 00:55:05 UTC