RE: Clarification on media capture split between WebRTC and DAP

Doing what Rich proposes for still image capturing is certainly possible with the APIs currently discussed (and is in fact what was used - minus the getImageData part - for the image overlay on stream example I showed at the rtcweb impl. status session in Quebec).

It is on the other hand far from optimal as has been pointed; but IMO an API for still image capturing is not what webrtc should focus on, at least not in the first phase.

Stefan
________________________________________
From: public-webrtc-request@w3.org [public-webrtc-request@w3.org] On Behalf Of Ben Strong [bstrong@gmail.com]
Sent: Monday, August 15, 2011 6:13 PM
To: public-webrtc@w3.org
Subject: Re: Clarification on media capture split between WebRTC and DAP

Randell Jesup wrote:

Francois Daoust wrote:

[snip]

So still image capture is handled implicitly in the web toolchain and
does not need special consideration in either group (unless we end up
not being able to use that toolchain for whatever reason in the final
API..).

Umm... There's an inherent assumption there that <video> won't modify the data that
ends up in the <canvas> - change resolution, run through codecs, etc.  Plus HW settings
for capturing video may be very different (lighting, flash, ISO, resolution, etc) than for
capturing still images, even from the same sensor.  So I'd be very leery of that as a
reasonable alternative.

There are a couple of other problems here:

1) The webrtc approach doesn't allow the browser to use the platform's native photo capture UI, which is the best way to provide device-appropriate controls for all these hardware settings (plus focus, front/rear camera toggle, etc.).

2) The webrtc approach requires the user to provide explicit authorization for the app to access the camera, and at that point the app will have full access to the camera and could conceivably start transmitting a video stream without the user's knowledge. The capture interface, on the other hand, can both skip the authorization step (since taking the photo provides implicit authorization) and avoid giving the app full access to the input stream. To make an analogy to file apis, the webrtc approach is like asking the user to give the app access to the entire file system whereas the capture interface is like showing the system file picker and asking the user to select just those files the app should have access to.

I would also argue that both of these points apply just as much to video recording as to still image capture, since many platforms have native camcorder UIs that expose device-appropriate functionality, and finer-grained authorization is desirable in both cases.

Ben Strong

Received on Tuesday, 16 August 2011 08:12:31 UTC