Re: CaptureAPI initial comments

* >Do you have any existing vocabulary in mind which we could re-use here?*

I've skirted round the issue until now by only offering capture in one
resolution.  This is "OK" for pictures and video being saved on device, but
for third party apps, the needs are more varied.  As you suggest, a voice
recorded app needs low bitrate 4kHz, while a music recognition service wants
16kHz.

I want to balance flexibility for the developer while minimizing how much we
need to express in the *supportedFormats *information.  I was thinking the
supportedVideoFormats should return a list of pre-canned capture settings
targeting the needs of most developer.

I was thinking it would be an array something like the following, containing
a list of (device specific) encoding formats:
   [
      {width:320, height:240, vcodec:"h263", acodec: "amr", container:
"3gp", bitrate: 200000},
      {width:640, height:480, vcodec:"h264", acodec: "aac", container:
"mp4", bitrate: 400000},
      {width:640, height:480, vcodec:"h264", acodec: "mp3", container:
"mp4", bitrate: 500000},
      {width:176, height:144, vcodec:"xvid", acodec: "amr", container:
"3gp", bitrate: 64000}
   ]

An app developer would iterated through the array to find the format that
best matched their needs.

For example, an app that wanted to stream video to a server might iterate
the list looking for a bitrate <128K.  An app looking to capture video
locally might choose the largest capture resolution and not worry much about
the file format.

The list might be ordered according to the device manufacturer's thoughts on
what is best for this device.

The list in that example is expressed as an array of JSON objects, as this
format makes most sense to a Javascript app, i.e., it is easy to parse.  I
suppose it could be also an array of DOMString, provided the format in the
string was easy to eval() for a JS app, e.g., "width:x,height:y,...".

On the events front:  I use events to indicate things like *capture start*,
*preview active*, *save complete*, *error*.

I have the impression - after re-reading this CaptureAPI spec. - that it's
targeting an model where an application is 'cross-launching' a separate
camcorder or audio recording application.  Is that a valid assumption?  In
contrast, I was capture objects would be something included in the app,
similar to how we now embed a HTMLAudioElement , via new Audio(), or
HTMLVideoElement.   That may be why I have a longer list of events I want to
expose.  In my scenario, specifying a callback for each when calling
captureVideo() does not seem feasible.

What are your thoughts?

Rik.





Rik Sagar, San Jose, CA 95124
Visit : http://sagar.org/


On Thu, Mar 25, 2010 at 4:08 AM, Ilkka Oksanen <Ilkka.Oksanen@nokia.com>wrote:

>  Hi Rik,
>
> Thanks for you comments. They will be considered.
>
> On 24.03.10 02:32, ext Rik Sagar wrote:
> > 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
> >
>
> Do you have any existing vocabulary in mind which we could re-use here?
> I think specifying new one from scratch might not be very
> straightforward. Maybe single compression option would suffice. It
> could be a hint for the native implementation either to optimize for
> quality or file size. I believe the application is mostly interested on
> file size, especially in cases where media file is uploaded to a remote
> server.
>
> > 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);
> >
>
> Capture API follows the same convention that is used in the other DAP APIs
> including System Info, Calendar, Contacts, Gallery, and Messaging. In
> general DOM events have also been considered. The problem identified was
> options parameter that can't be part of addEventListener(). How did you
> solve this in your API?
>
>             -ilkka
>