RE: PROPOSAL: Simple image capture API

>-----Original Message-----
>From: Anant Narayanan [mailto:anant@mozilla.com]
>
>On Mar 14, 2012, at 4:40 PM, Robert O'Callahan wrote:
>> I think it would make sense to have VideoMediaStreamTrack (like
>AudioMediaStreamTrack already), and APIs on video tracks to request setting
>of various camera parameters (resolution, focus mode, etc) (async of
>course), and an API to request a snapshot with/without flash and various
>other parameters set momentarily (also async). The snapshot API should
>probably trigger a callback passing a Blob which can be used as an <img>
>source.

It will be interesting to see how the "camera parameters" can be presented
using our contraints/capabilities model being discussed.

>This seems to be along the lines of of what Rich suggested earlier in the
>thread as well.
>
>We've already kicked around the idea of a MediaStreamRecorder to capture
>snippets of video from a stream, we might need a similar object to capture
>images from a stream. I'll come up with a rough proposal for these and send
>them to the list.

+1

I've suspected that we need specific track types in the media stream to be able to 
segregate video and audio-specific APIs. Unless we expect a variety of different 
categories of track types, I think it would be safe to follow HTML5's 
HTMLMediaElement.audioTracks / .videoTracks concept and fork the tracks to make
script processing easier.

Earlier I drafted up a "MediaEncoder" concept [1] that might serve as inspiration for
you (regarding drafting up a rough proposal). Ideally, I would like to see just one 
interface that can handle snapshots as well as video, but there was enough differences 
when I was sketching this out before that having two different interfaces seemed
inevitable. Perhaps you'll have better luck :-)

[1] http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0043.html

Received on Thursday, 15 March 2012 00:02:22 UTC