W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2013

Re: Questions about the MediaStream Image Capture API proposal

From: Rob Manson <roBman@mob-labs.com>
Date: Thu, 30 May 2013 17:18:15 +1000
Message-ID: <51A6FD37.60600@mob-labs.com>
To: public-media-capture@w3.org
Thanks Stefan.

Hopefully this will include some looping mechanism for stream processing 
like frameGrabber() sounded like it was intended to be 8)


On 30/05/13 17:05, Stefan Håkansson LK wrote:
> 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:18:43 UTC

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