- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sat, 24 Mar 2012 16:49:21 +0100
- To: public-media-capture@w3.org
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 Saturday, 24 March 2012 15:49:50 UTC