W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

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

From: Arve Bersvendsen <arveb@opera.com>
Date: Fri, 04 Dec 2009 13:24:58 +0100
To: "Robin Berjon" <robin@robineko.com>
Cc: "Ilkka Oksanen" <Ilkka.Oksanen@nokia.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <op.u4ex3wvabyn2jm@galactica>
On Fri, 04 Dec 2009 12:59:12 +0100, Robin Berjon <robin@robineko.com>  
wrote:

> On Dec 4, 2009, at 12:33 , Arve Bersvendsen wrote:
>> On Fri, 04 Dec 2009 12:26:09 +0100, Robin Berjon <robin@robineko.com>  
>> wrote:
>>> The code is simple enough, and typical enough, but my concern is  
>>> whether this approach can scale to controlling the video. So in the  
>>> above I've embedded the captured video in the page, but this assumes  
>>> that it's already been recorded. How do I grow that into something  
>>> that could stream it (streaming is hard enough already, I'm not sure  
>>> how it marries to the form metaphor)? How do I grow that into  
>>> something using which I could control the capture from within the  
>>> document?
>>
>> If the intent is actually grabbing the video stream, and embedding it  
>> in content, here is my proposal:
>>
>> <object src="protocol:identifier/for/some/camera/">
>>  <param name="aperture-value" value="1.4" />
>>  <param name="shutter-speed" value="1/30" />
>> </object>
>>
>> Implement File and FileReader on the <object> interface.
>>
>> <object> (Or even <video>) could implement an interface for setting  
>> properties on the device
>
> 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  
> http://www.w3.org/mid/AB072C1D-8194-45A8-968E-5E44D3B8F96E@robineko.com  
> 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?

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

Some questions:

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).

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?

-- 
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/
Received on Friday, 4 December 2009 12:25:39 GMT

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