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