Re: Clarification on media capture split between WebRTC and DAP

Ben Strong wrote:
> Randell Jesup wrote:
 >> Rich Tibbett wrote:
>>> 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.).

The HTML Media Capture specification I referred to earlier does provide 
a way to trigger the platform's native photo capture UI directly to 
obtain a still image. That UI happens to provide access to all camera 
settings such as lighting, flash, ISO, resolution, focus, front/rear 
camera toggle, etc. With that spec, the user can obtain a high-quality 
camera snapshot with the following line of HTML:

<input type="file" accept="image/*" capture="camera"/>

..which would result in e.g. 
http://www.w3.org/TR/html-media-capture/#uiexamples

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

Developers are free to obtain an image capture both via the HTML Media 
Capture approach above or as a sometimes useful by-product of the user 
streaming their camera to the web page via the webrtc approach.

Having said that, providing a stream of the camera to a web page is not 
the same as authorizing that web page to stream camera content to a 
remote server. I'd prefer to keep both aspects separate in the user 
authorization model. For example, providing the camera to a web page 
could be used to enable Augmented Reality experiences without the user 
having authorized any Streaming aspects. Any streaming in that use case 
would be a serious violation of that user's privacy.

>
> 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,

It may be possible to tweak the settings of the Stream via the UA's 
interfaces once it has been provided to a web page. However, that would 
be out of scope of defining an API, IMO.

> and
> finer-grained authorization is desirable in both cases.

Since one of the use cases is to stream the camera only to the web page 
for e.g. AR purposes I agree there should be a separate authorization to 
stream that data to a remote server if and when that is required.

- Rich

Received on Tuesday, 16 August 2011 09:21:42 UTC