- From: Bryan Sullivan <blsaws@gmail.com>
- Date: Sun, 25 Mar 2012 00:50:45 +0800
- To: Harald Alvestrand <harald@alvestrand.no>, <public-media-capture@w3.org>
Harald, FYI To get your example to work, I had to replace: video.src = webkitURL.createObjectURL(s); With video.src = webkitURL.createObjectURL(stream); On 3/24/12 11:49 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote: >On 03/13/2012 06:55 PM, Anant Narayanan wrote: >> On Mar 13, 2012, at 2:04 AM, Harald Alvestrand wrote: >>> I suspect that most stuff embedded within an application will want to >>>control its own "viewfinder" UI, so that the more common flow will be: >>> >>> getUserMedia(video: true....) >>> <viewfinder code> >>> getUserMedia(picture: true) >>> <process snapshot> >>> >>> Having the "preview to choose picture" dialog be required will make >>>this use case more difficult. >> This API is not targeted towards apps that need a custom viewfinder. If >>the app already has a MediaStream, it has no need to call getUserMedia >>again, rather extending/refining the MediaStreamRecorder object to allow >>for image capture is better (or do something similar to a getSnapshot() >>method proposed by Rich). >> >> The proposed API is targeted solely at applications that only need a >>single picture without much fuss. The use-cases are simple: upload a >>profile picture to Facebook, or take a picture with Instagram and apply >>a filter, upload a picture along with your tweet. Note that cropping the >>picture, applying filters, etc. are done after the image has been >>captured in both of these cases, so a browser preview window is not a >>hindrance. If you look at the Twitter "native" app on Android, when you >>want to attach a picture with your tweet, it bounces you off to the >>default Camera app of the phone (which is the equivalent of the browser >>preview window in our world!), and after you take a picture you are >>returned to the app that asked for it. >> >> I think it is important that we support these use-cases without a >>dependency on MediaStreams, with a dead simple API. >> >> To be more specific I would like for this possible with just these few >>lines of code (renaming the function to avoid confusion with the >>existing meaning of getUserMedia): >> >> navigator.media.capturePicture(function(blob) { >> // do something wit blob >> }, function(err) { >> // show error message, or flash based fallback ;) >> }); >> >> Separately, it is also important to define a similar function for >>capturing a picture from a live MediaStream, if the app already has one >>(currently it is quite clunky: https://gist.github.com/1852070). >Actually I don't think it is completely hopeless, the below works in >Chrome canary: > ><html> ><body> ><video id="v" width="300" height="300" autoplay></video> ><input id="b" type="button" disabled="true" value="Take Picture"></input> ><canvas id="c" style="display:none;" width="300" height="300"></canvas> ><img id="i"> ></body> ><script> > var s; > navigator.webkitGetUserMedia("video,audio", function(stream) { > var video = document.getElementById("v"); > var canvas = document.getElementById("c"); > var button = document.getElementById("b"); > var image = document.getElementById("i"); > > video.src = webkitURL.createObjectURL(s); > button.disabled = false; > button.onclick = function() { > canvas.getContext("2d").drawImage(video, 0, 0, 300, 300, 0, >0, 300, 300); > var img = canvas.toDataURL("image/png"); > image.src = img; > alert("done"); > }; > }, function(err) { alert("there was an error " + err)}); ></script> ></html> > >(I had to twist Anant's example code in a few places to make it run) > >It doesn't do quite what you'd expect, though. I don't know if that's a >bug or not. >> It would be nice if we could reuse the same function signature and name >>for both of these cases, but if that only causes more confusion, then >>I'm OK with them being two separate functions (I do prefer reusing the >>same for both cases, though). >> >> Regards, >> -Anant >> >> >> > >
Received on Sunday, 25 March 2012 07:51:21 UTC