W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2011

RE: Mobile Firefox handling of camera input

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Wed, 20 Apr 2011 07:16:11 -0700
To: Dominique Hazael-Massieux <dom@w3.org>, Kyle Huey <me@kylehuey.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D325EC2BC35D@orsmsx501.amr.corp.intel.com>
Also as a note, I found this article on Honeycomb implements the Device API's Media Capture as:

http://davidbcalhoun.com/2011/android-3-0-honeycomb-is-first-to-implement-the-device-api


I haven't verified this since I don't have Honeycomb

Thanks
Dzung Tran

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Dominique Hazael-Massieux
Sent: Wednesday, April 20, 2011 5:50 AM
To: Kyle Huey
Cc: public-device-apis@w3.org
Subject: Re: Mobile Firefox handling of camera input

Le mercredi 20 avril 2011 à 08:41 -0400, Kyle Huey a écrit :
> I'll preface this by saying that I don't think we plan to ship capture
> functionality in the next version of Firefox Mobile.

OK, thanks for that clarification; I guess that's what the P2 rank in
https://wiki.mozilla.org/Features/Mobile indicates, I should have read
that more carefully :)

> What you're looking at is an implementation detail.  The "moz-device"
> scheme is hooked up internally to the appropriate platform specific
> glue layer (gstreamer on Linux, DirectShow on Windows, etc.) and
> provides a URI from which a feed from the camera (or other device) can
> be loaded.  moz-device URIs can only be loaded by "chrome" code (the
> browser's privileged XUL and JavaScript).  Using this, we can set up a
> capture dialog that has a <video src="moz-device?...."> (and whatever
> else we want) and we have our capture/preview UI. 

OK, I understand better the role of that URI scheme now. I assume this
means this moz-device: scheme won't be interpreted outside of the chrome
(for the time being, at least).

> The API that would be exposed to content from this setup is roughly
> what Hixie describes in
> http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0095.html.  If the accept attribute is a type that we can capture we will provide the user the choice between getting media from the file system or from the device.
> 
> We're not really sure how a capture attribute/MIME type parameter
> that's supposed to provide a hint to the UA will play into all of this
> yet, especially given that some of the file picker or capture dialogs
> may be native.  Our UI story on all of this still needs a lot of work,
> which is one of the reasons I don't think we'll be shipping this in
> the immediate future.

We're very keen on getting feedback on whether this additional hint is
useful or not, so I hope you'll bring your input to the group once this
gets clearer.

Thanks again for the quick turnaround :)

Dom



Received on Wednesday, 20 April 2011 14:16:54 GMT

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