W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

CaptureAPI initial comments

From: Rik Sagar <org.whatwg@sagar.org>
Date: Tue, 23 Mar 2010 17:32:44 -0700
Message-ID: <c14a2ba71003231732k60d8aa4esf937a02da6825836@mail.gmail.com>
To: public-device-apis@w3.org
Hi all,

I just found http://dev.w3.org/2009/dap/camera/.  I had a couple of initial
comments, based on what I've implemented in the capture APIs on our
product.


MIME-TYPE
I noticed the format is specified in the form of a mime-type.

A mime-type like video/mp4 is not sufficient detail for some formats.  You
must take into account the combination of container/file-format and CODECs.
For example, a video captured in "MP4" could use one of several profiles
(baseline, main, standard) and .mp4 doesn't tell you which.

Equally, audio capture applications that save WAV files could be writing
PCM, AMR, ADPCM, ...

We need to consider either a richer vocabulary to specify the encoding (and
allow an application to enumerate the encoding options).  For example,
something including bitrates, audio channels, codecs, in addition to a
simplified API that is at a higher level, e.g.,
   compression=low|medium|high


CAPTURE IMAGE CALLBACKS

The captureImage() call takes callbacks for success and error.  In a camera
API I implemented recently I went with the event listener model, i.e.,
camera.addEventListener('save',
callback, bubble);

This is more consistent with the audio/video playback APIs
(HTMLMediaElement) in HTML5 (and lots of other Javascript development these
days).

Regards,
Rik.




Rik Sagar, San Jose, CA 95124
Visit : http://sagar.org/
Received on Wednesday, 24 March 2010 06:54:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT