- From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
- Date: Fri, 20 Nov 2015 17:26:29 +0000
- To: Media Capture TF <public-media-capture@w3.org>
Hello All, I am sorry I was not able to go through the ImageCapture slides during the last Media Capture TF F2F at TPAC 2015 [1]. However, note that we have one partial implementation (Gecko) and one intent-to-implement (Chromium). This coupled with the progression of the Media Capture and Streams spec means that is a good time to revisit ImageCapture and drive it some level of completion. There are some things to consider: a) grabFrame() method. See slide 4 of [1]. Recall that the original motivation for this feature was to allow developers the possibility of processing frames in real time from the camera. This in my opinion has been somewhat overtaken by events, particularly the Mozilla FoxEye project [2]. Should we remove grabFrame() given the progress in FoxEye? NOTE: If we keep grabFrame(), then we should move to ImageBitMap and not ImageData as the returned object. This should address the issue raised in [3]. b) I gave my take on the constraints extension issue for the MediaStreams spec on slide 5. I do think that overlapping settings/constraints could be a problem in the future, and the group should have a position on it. c) The current spec may be found at [4]. I've recently incorporated 3 relatively minor pull requests to address formatting and WebIDL issues (thanks - Dom and Marcos!). There are other legitimate issues that have been recently raised on the GH repo and will be addressed in the next rev which I hope to put out within the next 2 weeks. -Giri Mandyam, ImageCapture Specification Editor [1] https://www.w3.org/2011/04/webrtc/wiki/images/e/ef/TPAC-2015-MediaCapture-ImageCapture.pdf [2] https://wiki.mozilla.org/Project_FoxEye [3] https://github.com/w3c/mediacapture-image/issues/8 [4] https://w3c.github.io/mediacapture-image/ [4]
Received on Friday, 20 November 2015 17:27:30 UTC