Re: <input type=photo> etc as Capture API

On Dec 4, 2009, at 13:24 , Arve Bersvendsen wrote:
>> Just as a reality check, do you really think that a solution involving both <object> and a new URI scheme is simpler and more elegant than one relying on APIs and <video>? Say contrasted to the API in for instance?
> So we're clear here : I'm agnostic with regards to the element used, and I'm also being agnostic with regards to the protocol -- aren't there already protocols we can reuse?

I'd be wary of any scheme intended to be used in markup. But yes, I would assume that we can reuse the URN namespace that the File API is working on.

> Also, in looking at your proposal: An API to determine the location of, configure, and start/stop capturing of live data for inclusion into, for instance a video element is probably needed anyway

Yes, but that doesn't require <object>, or in fact adding interfaces to elements.

So, allow me to make the following assumptions:

  1) We have an <input> based approach like the one you are describing (and click events can be synthesised to it).
  2) The name is wrong (as it could work for audio too), but we can paint that shed later; we have an interface like the following, which inherits from File, and is what is returned by <input type=file accept=video/*> in .files when the user has selected a viewfinder (note that this degrades to uploading files, and the UA can also make the video itself separately). Note that it can be extended to have more control over the device:

    interface ViewFinder : File {
        void startCapture(Blob blob);
        void stopCapture();

  3) We have an XHR.send() that can take a blob.
  4) We have some way of synthesising blobs (no big deal).
  5) File has s/urn/URL/ as I believe is the plan.

We take and extend my earlier code to make a complete "Film yourself and upload the video" thing:

<!DOCTYPE html>
<html xmlns='' xml:lang='en' lang='en'>
    <meta http-equiv='Content-Type' content='text/html; charset=utf-8'/>
    <title>Video Capture</title>
      function getVideo (sucCB) {
          var inp = document.createElement("input");
          inp.type = "file";
          inp.accept = "video/*";
          inp.onchange = function () { sucCB(this.files[0]); };

      var blob;
      function setupVideo (vf) {
          document.getElementById("my-video").src = vf.URL;
          blob = navigator.device.makeMeANewBlob();
          document.getElementById("start").onclick = function () { vf.startCapture(blob); }
          document.getElementById("stop").onclick = function () { vf.stopCapture(); }
      function send () {
          if (!blob) {
              alert("You didn't capture anything!")
          var xhr = new XMLHttpRequest();
"GET", "http://my-server/video-upload");
          xhr.onreadystatechange = function () {
              if (xhr.readyState == 4 &amp;&amp; xhr.status == 200) alert("Video uploaded!");
    <button onclick='getVideo(setupVideo);'>Film your face!</button>
    <video id='my-video'></video>
    <button id='start'>Start</button>
    <button id='stop'>Stop</button>

Is this what you have in mind?

> Are there modern enviroments that do not allow viewfinder streaming?  Android 2.0 certainly seems to be able to, desktop applications can.   If memory serves me right, I could even do this in J2ME on a Series 40 phone with Opera Mini 2 (or 3).

Can you do it on the iPhone? All the app I could test seem to rely on something external (and worse, on the Gallery as well).

> If enviroments that do not support live viewfinder data exist, are you planning on falling back gracefully?  Is there a means to do proper progressive enhancement?

The above can be made to fallback gracefully, in that what you get from input.files wouldn't be a ViewFinder but just the File with the content.

Robin Berjon
  robineko  hired gun, higher standards

Received on Friday, 4 December 2009 14:41:30 UTC