- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 30 May 2013 09:05:58 +0200
- To: public-media-capture@w3.org
On 2013-05-30 08:41, Rob Manson wrote: > Hi Giri (or Stefan/Harald where relevant), > > just wondering if this API is being pursued by the Media Capture Task > Force? This link (http://www.w3.org/TR/image-capture/) at the top of > the document throws a 404 and I couldn't find any links to it except in > the list thread where it was proposed. It is actively being pursued by the Media Capture TF. I think the reason for the link to be broken is that the document has not yet become a Public WD (it is an Editor's draft). At the last teleconf it was decided that some updates should be made to the Editor's draft, and a call for consensus to make it a First Public WD would then be issued. Stefan > > There was also some feedback in the thread of the original proposal > about splitting out settings. > http://lists.w3.org/Archives/Public/public-media-capture/2013Feb/0082.html > > I wondered if this was happening? > > I also have a few other questions about this document. > > 2.2 Methods -> getFrame point 2. mentions "{Note: Unlike frameGrabber(), > getFrame() returns data only once upon being invoked.}". But there's no > reference to frameGrabber() anywhere else. Has this been removed? This > distinction of one-off versus looping still seems very relevant to me. > > If frameGrabber() did exist, would you be able to replace the > "pictureDevice.getFrame();" line in Example 2 and then processFrame(e) > would just be called when every new frame arrives? > > In Example 1, wouldn't pictureDevice.onphotosettingschange's function > never be called because the pictureDevice.setOptions() call had already > happened before this was defined? > > There's also a small typo - the table in 2.2 Methods -> setOptions() has > some broken unicode chars in them e.g. â > > roBman >
Received on Thursday, 30 May 2013 07:06:29 UTC