Re: Clarification on media capture split between WebRTC and DAP

On 08/16/11 12:10, Rob Manson wrote:
> +1 for finer grained separate authorisation between streaming to a
> remote server vs. streaming into a<video>  or<audio>  tag.  This is
> essential.
-1.

I have problems with this - it seems to say that when asking for a 
camera, the JS has to specify API parameters that specify what the 
purpose of the stream is - with an as-yet undefined vocabulary.

This also then presupposes that the conceptual stream (remembering that 
the stream is a conceptual object and probably has little relationship 
with the behind-the-scenes realities) has to be tagged with the purpose 
for which it was obtained, and the API will have to have appropriate 
checks and error messages once the ultimate purpose can be inferred from 
the interface. This purpose-tagging even has to be carried through 
elements like the <video> tag - since one can pipe a camera into a video 
tag and use video-tag functionality to manipulate the stream, and then 
extract it again for sending over the network.

Since this is a complexity that seems to be driven by a need to support 
use cases outside of the scope of WebRTC (such as augumented reality 
functions), requiring that the WebRTC APIs satisfy those constraints 
seems likely to delay the WG's work - I would like to avoid that if 
possible.

> It's also important for Augmented Reality that audio can be handled in
> this way too...not just the visual aspect of video (e.g. images).
>
>
> roBman
>
>
> On Tue, 2011-08-16 at 11:21 +0200, Rich Tibbett wrote:
>> 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.
>
>
>

Received on Tuesday, 16 August 2011 13:52:26 UTC