Re: Why does media capture require a browser?

Jim Barnett wrote:
> So the problem is that using the takePhoto API might have a loop where they
> grab a frame, process it, and then ask for another frame.  If their
> processing is fast enough, they might get the same frame again.  With the
> current API, they'll just have to be careful and use timers to avoid that.

Yes, this is the problem I'm suggesting could be solved with a 
requestAnimationFrame()-style API. The current proposal is described 
more like Canvas's getImageData() which requires polling and, like you 
said, careful use of timers. The problem with timers is that even the 
people who wrote the examples of how to use the getImageData() API 
couldn't be bothered to use them, and even if they had, setTimeout() is 
not something that can be set to be called at an exact interval (you 
specify a delay instead, which is merely a minimum). That means if you 
really do want all the frames and are on a machine fast enough to 
process them, you need a bunch of complicated clock-drift management 
code, or you will still miss some (not to mention it introduces up to a 
frame of latency).

> I suppose that we could add a requirement on the UA that consecutive calls
> to takePhoto must return distinct frames. I don't know how much of a burden
> on the UA that would be. From what I understood of the discussion, it seems

Yes, I think that's basically all that's needed. The other thing to 
consider is the interaction with blocked streams (e.g., a video track 
that's sourced by a <video> element that's paused).

> If there are use cases where developers want a stream of frames (each frame
> as it's available, or a frame every n milliseconds, etc.), we could extend
> the recording API to cover it. It seems  to me that the basic difference

I think the distinction between the two APIs is that the recording API 
should always attempt to deliver all the frames, even if that means it 
has to buffer some and introduce some latency.

Received on Tuesday, 26 February 2013 14:55:50 UTC