Re: First stab at the Capture API (aka Camera API)

Dominique Hazael-Massieux wrote:
> Le mardi 01 décembre 2009 à 19:50 -0800, Tran, Dzung D a écrit :
>   
>> It is checked in to CVS as stated below. There is some formatting
>> problems, which I am strap for time to figure out right now. 
>> http://dev.w3.org/2009/dap/camera/Overview.html
>>     
>
> I have fixed the formatting problems, and am fixing bugs and adding
> clarifications as I find them.
>
> Thanks for a great start!
>
> I think the document is quite close to a FPWD, as Robin mentioned; to
> facilitate the discussion on that point (i.e. to evaluate if we cover as
> much as the final scope as we want), here is a list of the requirements
> *it does NOT fullfill* to do at this point:
>       * must enable listing the available cameras 
>       * must enable listing the available audio input devices
>       * must enable listing the available formats and codecs, *per
>         capture device*
>       * must enable choosing preferred aspects of the captured content
>         (e.g. width, height, format, frame rate)
>       * should enable control of the camera's capabilities (e.g. zoom,
>         luminosity, night mode, focus mode)
>       * should enable setting of brightness, contrast, gain
>       * should enable displaying a viewfinder as part of the document
>         (e.g. as a video element [HTML5]) 
>       * should enable setting microphone audio level
>
> Dom
>
>   
I think it would also be useful to note which of the five use cases in
section B are currently supported by the proposed API.

[I'm assuming that the permissible uses of the media URIs return by
captureCB will be defined. For example, can you XHR against them to get
the data?]

Picture Capture and Picture upload: If the issues are resolved, then I
think that this use case is met.

Panorama Image Capture: Doesn't seem likely unless there is a way to get
the data from the media URL.

Video chat: Not possible as there is no way to capture a video stream
and transmit it in real time (audio similarly)

Web cam: Motion of the camera could be via some other API. Motion
detection requires that the image data be available to the app -- so
currently not possible.

Voice memo: There is the same set of issues as for the picture capture
use case.

Thus it appears that we are 0 for 5. The one thing that would improve
the situation will be to able able to get the actual data (preferably in
real time) from the capture process. Specifying that the URI provided in
the captureCB was a websockets capable URI would solve the problem.
Alternately, making sure that XHR can get the data (there are probably
some same origin issues here) would solve most of the use cases.

Philip



-- 
Philip Gladstone                    978-ZEN-TOAD (978-936-8623)
Cisco Systems, Inc                                  Boxboro, MA