Re: Questions about the MediaStream Image Capture API proposal

Thanks Stefan.

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

roBman

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