Another image capture API proposal (Re: Fwd: Re: Re: Proposed resolution for open items)

Changing the subject line in order to make this thread findable....

On 05/15/2012 09:11 AM, Randell Jesup wrote:
> Regarding the "simple capture API":
>
> Robert O'Callahan had indicated he'd propose an alternative.  Here's a 
> possibility he came up with.  Note as he mentions we've already landed 
> in Mozilla nightlies media_element.src = stream.   Note that this 
> would NOT work well with createObjectURL, especially if the "avoids 
> leaks better" option for a single use is in play.  (It's retrieving 
> the mediastream from media_element.src.)  To work at all with 
> URL.createObjectURL there would need to be a URL.objectFromURL or some 
> equivalent.  (Another example of why .src = stream is a good idea, and 
> createObjectURL is clumsy.)
>
>   Randell
>
> This is about an app grabbing a preview stream and then, when the user 
> presses a "take photo" button, firing the flash and grabbing a 
> high-res snapshot, right? Here's a thought experiment:
>
> <video id="preview" onclick="takePhoto(event)"></video>
> <script>
> function onsuccess(stream) {
>   document.getElementById("preview").src = stream;
> }
> function blobCallback(blob) {
>   // This blob contains the image data; do whatever needs to be done 
> with it
> }
> function takePhoto(event) {
>   var stream = event.target.src;
>   var videoTrack = stream.videoTracks[0];
>   videoTrack.takeSnapshot({}, blobCallback);
> }
> navigator.getUserMedia({video:true}, onsuccess);
> </script>
>
> Apart from allowing HTMLMediaElement.src to be a MediaStream (already 
> on mozilla-central!), 
Actually this shows that HTMLMediaElement.src can be fetched, not just 
written to.. I hadn't realized that part of the proposal.

> the only new API here a VideoMediaStreamTrack subclass of 
> MediaStreamTrack, with a takeSnapshot method on it. I've given that 
> method a blob callback to asynchronously return the snapshot image, 
> and an options object. By default I think the snapshot should 
> autofocus, autoflash, etc, but you could provide options to override 
> all of those things. I'm not enough of a domain expert to say what all 
> those options should be. By default, takeSnapshot should obtain the 
> best quality and highest-resolution image the hardware can provide.

Like the SendDTMF function on the LocalAudioStream (not yet sure how to 
specify all this subclassing in WebIDL), this seems reasonably natural 
to me.

A quick implementation would copy out the framebuffer (if there is such 
a thing in the implementation); a more advanced implementation could do 
what's written above.

I do miss an option to set the format of the image, but I assume that is 
either a natural format for the platform (the same thing as being picked 
out of a Canvas?) or an option (constraint?) on the takeSnapshot call.
>
> Rob
>
>

Received on Tuesday, 15 May 2012 10:46:47 UTC