Re: ISSUE-8: Requirements for [Camera/Caputre API]

Yes -- it was the list of requirements.

The use case is to be able to write a web app that implements a
voice/video chat client. This could be as part of an instant messaging
client, or might be a standalone videophone or 'telephone'. Another
example might be an online 'chat with customer service' link on the
website that downloaded the web app that allowed the customer to do this
directly.

Video output can be handled with the <video> tag. However, video input
is not so easy as there is no obvious way to pass captured video in real
time to the server. You might think that you could use the preview URL
as proposed in one API as a way, but there is no obvious way to pass the
data coming out of this URL down (for example) a websocket.

The approach of rendering the preview into a <canvas> and then scraping
the canvas, re-encoding the data and transmitting it seems too ugly (and
too inefficient) to be useful. The rendering approach also doesn't work
for the associated audio stream. Worse, the preview data stream might
not include the audio anyway.

I think that the ideal approach would be to define a websockets like
interface onto the camera/microphone (it might even be as simple as
defining a method to get a websockets URL for the camera/microphone).
Another alternative (which would cause more upheaval) would be to add
the websocket read/write interface onto XmlHttpRequest and then have the
camera expose an HTTP URL for the full audio/video datastream.

Hope this helps

Philip

Ingmar.Kliche@telekom.de wrote:
> I think the proposed requirement (see below) didn't made it into the requirements document yet. 
>
> @Philip: 
>
> You are referring to "the current API proposal ... ". I guess you are talking about the list of requirements?
>
> Also, could you elaborate more on the use case of a "web application to capture realtime video -- say as part of a video conferencing application"?
>
> Thanks, 
> Ingmar.
>
> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Philip Gladstone
> Sent: Tuesday, October 06, 2009 8:18 PM
> To: Robin Berjon
> Cc: public-device-apis@w3.org
> Subject: Re: Updated requirements document
>
> Hi
>
> For the Camera (aka Capture) API, I would like to propose that the
> requirement "MUST support continuous delivery of realtime audio and
> video". The current API proposal only supports getting access to a
> complete captured video (or audio) object. This does not permit a web
> application to capture realtime video -- say as part of a video
> conferencing application. It might be possible to do this by mapping the
> viewfinder to a canvas, and then rapidly scraping the canvas, but, as
> well as being extremely nasty, it doesn't solve the audio problem.
>
> Philip
>
> Robin Berjon wrote:
>   
>> Hi all,
>>
>> I've updated the requirements document at:
>>
>>   http://dev.w3.org/2009/dap/api-reqs/Overview.html
>>
>> It now contains information for each API, and tries to list a number
>> of issues, though of course more work is needed.
>>
>> I'd like to ask everyone to spend a little bit of time reviewing it
>> before the call. I think that we've gathered enough information that
>> it is worth publishing it officially (as a WG Note, since it's not
>> normative). And ideally that's a decision that we would be able to
>> make on the call this week - so be sure to check it!
>>
>>     
>
>   

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