Re: Questions about the MediaStream Image Capture API proposal

Hi Giri,

> Thanks for your feedback.  I will get out a revision of the spec soon.

Awesome.


> Couple of things to note:
>
> 1. Yes, the link on the spec to what would be the W3C Mercurial
instance is broken. Regarding Mercurial, I have only uploaded here so
far:
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/ImageCapture.html.
As was said previously, when this progresses to FPWD then we could also
have a version available at http://www.w3.org/TR/image-capture/.
Regardless, I'll correct this in the spec in the next version to avoid
confusion.

Fair enough.


> 2. I have eliminated all references to frameGrabber (there was one
left in by error) on the Mercurial version. As Adam pointed out, we have
decided not to have this. If you want such a feature,
setInterval(track.getFrame(), time_interval) or setTimeout
(track.getFrame(), time_lag) is your best bet. If the capture device is
not ready to return a fresh frame, then an ImageCapture error event can
be fired with the code set to FRAME_GRAB_ERROR.

OK.


> I guess you could define an onloadeddata event handler, but near as
> I  can tell there would have to be a corresponding DOM element for the
media. The intention of the ImageCapture spec was to avoid creation of
DOM elements for the API (in contrast to the previous approach in Media
Capture and Streams - see the photo example in
http://www.w3.org/TR/2012/WD-mediacapture-streams-20120628/#examples).

Fair point about having a MediaElement in the DOM.

I also ran some tests using onloadeddata but it doesn't work as I had 
assumed 8( It's not a repeating event. So I guess I'll just stick with 
setTimeout/setInterval.

It just seems a shame to only have this type of polling style model when 
generating streams from a video source really could/should be event 
driven as each unique new frame arrives.  Otherwise it's quite possible 
we could end up duplicating frames or re-processing frames that are 
effectively identical in the Media Capture pre-processing scenarios 
(e.g. Facial Recognition, Augmented Reality, etc.)


> 3.  Now that we have a new WD of the Media Capture and Streams spec, I also need to modify the constructor to take in a VideoStreamTrack.  I will be doing so in the next version of the spec, which I plan on sending out next week.

Cool.


Thanks for the responses.

roBman

Received on Friday, 31 May 2013 10:19:52 UTC