Re: Synchronous getUserMedia proposal

On 2012-11-02 19:32, Martin Thomson wrote:
> In its simplest form:
>
> MediaStream getUserMedia(MediaConstraints constraints);
>
> This returns a stream that provides no content (open option: a tainted
> stream that can only be displayed locally).
>
> Consent is indicated with a new onconsent event on the stream; failure
> reuses the onended event.  A new reason parameter is added to the
> onended event indicating the reason (this includes all existing onended
> reason codes, if any, plus all getUserMedia error codes).
>
> The major complaint with this is that it leads to an
> inaccurate/misleading expectation about the usability of the stream.
> That expectation can lead to the assumption that consent is granted,
> which would be a bad assumption.

This approach is not flawless, but to me it seems like the most 
reasonable one at the moment.

We already have the concept of a stream that is dispatched to JavaScript 
but the source is not ready to provide data yet. This currently happens 
when you receive a stream over a PeerConnection and all the tracks are 
muted until data arrives over the network. I think gUM() with a return 
value could be treated similarly, and local data is suspended until the 
user grants permission.

In the network case, a media description is used to create the stream 
and the receiving side and it's pretty capable of describing future 
stream content. In our local case, the user may only grant one media 
component. Perhaps ended track state is good enough to solve this.

I think we'll freak people out if a tainted stream is delivered at once. 
Even though page authors can't access the content or transport the 
stream, they can mix the camera view into the page content and that may 
make people uncomfortable (depending on the page they're visiting).

/Adam

Received on Monday, 5 November 2012 10:42:14 UTC