Re: Capture API question

Hi Robin,

On Fri, Jun 11, 2010 at 3:51 PM, Robin Berjon <robin@robineko.com> wrote:
> Hi Andrei,
>
> On Jun 11, 2010, at 12:21 , Andrei Popescu wrote:
>> No, we're not implementing the ViewFinder interface. We're just
>> hooking the camera to the file picker. The only extension we're
>> considering is to allow the author to invoke the camera directly using
>>
>> <input type="file" accept="image/*;source=camera">
>>
>> UAs that don't know what "source=camera" is will just pop up a regular
>> file picker.
>
> That does indeed provide for a nice fallback strategy. It would seem to me that no matter how simple, the source parameter could use being put in a spec. I'm guessing you have something like the following?
>
>  - image/*;source=camera
>  - video/*;source=camera
>  - audio/*;source=microphone
>

Yep, except video should maybe use "source=camcorder".

> Would it make sense to make it source=device for all three?
>

Maybe, but I am not sure this saves us much typing while potentially
losing some clarity for Web authors.

> Question: are you looking just at stills now or also AV content (seems to me like both)?

Both.

> I ask because with AV there could be value in letting the user select one compound input device (e.g. "My WebCam") but have separate access to the audio and video afterwards. But that might be a future refinement.
>

Yes, I think for v1 we won't provide separate access to audio and
video. We can revisit this for v2 depending on feedback.

> Also: browsers tend to like exposing a native UI for file pickers as that's a whole lot more natural for users, but on many platforms they don't have an option to pick from an input source. I can see how you could address that on Android, but I'm curious as to how you plan to handle it with other platforms.
>

True, but I don't see it as a roadblock: I think it's possible for
most UAs to detect the installed input sources and present the user
with a selection dialog that has a natural look&feel for the user's
OS.

> If developers and implementers are happy with an approach even simpler than the one we currently have, I (personally) would be happy to specify just that. We can separately write a "Trusted Capture" specification for non-Web environments that builds atop it.
>

That's good to hear, although is the separate JS API really that much
better / easier to use? I am thinking it is extra cost to developers
to learn and adopt a new API when they can achieve the same effect
using APIs they're already familiar with.

>>> *are you implementing an additional set of methods on top of the File
>>> API for media objects?
>>
>> Not for now but we are considering exposing the properties of the
>> captured media (e.g. dimensions, duration, encoding, etc) using a
>> subtype of File, like MediaFile in your spec.
>
> If you're going to use something "like MediaFile", how about we chat about what you'd like to put there and see if we can't just align?
>

For now, it seems like MediaFile is pretty much what we need. We were
thinking of adding an 'encoding' parameter (e.g. following rfc4281),
would that make sense to you?

Thanks,
Andrei

Received on Friday, 11 June 2010 17:46:10 UTC