Re: Why does media capture require a browser?

On 18 February 2013 11:22, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> In a case like this, can you iterate steps 3-5 quickly enough to capture
> enough of the video stream?  In principle, we could tweak the recording API
> to return frames rather than encoded Blobs, but I gather that would use up
> so much space that the system might choke to death in a hurry.  Relying on
> takePhoto lets the JS code decide how much memory it is using at any one
> time, but I want to make sure that the calls can be done quickly enough.

I think that the true value of recording is not in the ability to
access the data but in the intersection of both data acquisition and
compression.  I think that the photo API is the right place for
grabbing single images, and when you grab images, it makes sense to be
able to get raw, uncompressed images.

I think that Giri's takePhoto() proposal is the right place to extend
the API for this use case, since it focuses on instants in time,
rather than an entire span of time.

You *might* be able to run steps 3-5 fast enough to record, but more
likely than not, you will be missing the odd frame, and not caring.
These applications are probably not going to be performing compression
and then sending the data up to a server (though that would be cool to
see), that requires far more horsepower than we tend to see on the web
platform currently.  QR scanning and other CV apps will probably work
fine if they miss the occasional frame.

Received on Monday, 18 February 2013 19:29:49 UTC