Re: Video preview proposal: grabPreview

On 27 October 2014 07:26, Harald Alvestrand <harald@alvestrand.no> wrote:
> Either you get to capture output from the device, or you don't.

So the creepy factor is that random websites turn on your camera,
albeit briefly.  The data is not made available to the site, it's just
made available to the browser, but noticing the light come on is a
risk.

A browser is permitted to synthesize an image instead to avoid the
light coming on.  Maybe I needed to be clearer in the proposal, but I
thought that was fairly straightforward.  I can imagine Firefox
generating an SVG with the label of the camera and either a captured
frame or a generic logo, depending on what we decide regarding the
first item.

> I don't see the scenario where this is valuable enough to include.

Many applications want to provide in-application UX for selecting
cameras.  This allows them to create an in-app selector with preview
images.

> - We're trying to stabilize the spec. This is a new feature.

Fair point.  I will hold this until the spec is released or something.
I'm not entirely clear on how you intend to manage the spec.  You
could freeze out all innovation for some period, I suppose.  Maybe you
can articulate your plan.

> - It introduces a normative dependency on imagecapture, which still has
> some time to go.

Yeah, that much was clear when I put this together.

> One thing that it does as a side effect is to change the type of API of
> MediaDeviceInfo from "dictionary" to "interface". If we make this
> change, it becomes simple to add that type of functionality in the
> future - but at the price of not being able to assure people that "this
> is a dictionary".

I don't think that is a problem.

Received on Monday, 27 October 2014 16:39:56 UTC