Re: Proposed new text for noaccess

On 05/11/13 22:36, Jan-Ivar Bruaroey wrote:
> On 11/5/13 2:11 PM, Stefan Håkansson LK wrote:
>> On 05/11/13 17:39, Jan-Ivar Bruaroey wrote:
>>> In my mind, a 'noaccess' stream and a stream awaiting user-permissions
>>> are similar and could work the same:
>>>
>>>    1. getUserMedia returns quickly.
>>>    2. If the website shows the user a local view of their stream at all
>>>       (and many sites will not), the user sees either:
>>>         * Black,
>>>         * Local video, with dimming or water mark or "Relax, not live!"
>>>           don't-show-me-this-again warning workflow,
>>>             o (or any other fancy way to communicate audio/video-muting,
>>>               as browsers are good at innovating UX)
>>>         * Local video,
>>>         * "Click to play?"
>> I don't really understand if there would be a difference in the consent
>> dialogue if the app shows a local view or not
>
> There would be no difference.
>
>>    - is "Click to play" the same dialogue on both cases?
>
> Sorry, I was trying to rattle off things a browser might implement here
> - please ignore it if it is confusing. "Click to play?" refers to how
> Firefox disables Firefox-plugins by default; the user may click on the
> gray area where, say, the flash video would otherwise have appeared, to
> make it appear. - My main point here was to suggest that what to show
> locally when no permission has been granted is between the browser and
> its user.
>
>>>           And this would depend on /browser settings/ and user comfort
>>>           level (let browsers handle defaults here).
>>>
>>>    3. If stream is 'noaccess' then stay here. If app ever lifts
>>>       'noaccess', goto 4.
>>>    4. If browser ever returns that user-consent has been granted, then
>>>       unmute/promote stream to full access.
>> I sort of like this. If it also came with the info that also a
>> "noaccess" MediaStream can be attached to a PeerConnection (but would
>> never let any RTP packets, or only silence/black-RTP, go out on the net)
>> it could be used to get the negotiation going immediately (since gUM
>> returns quickly).
>
> Exactly, it takes permissions out of setup.

Thinking a bit more about this: it would work fine when the user returns 
(using the same HW) since the app can do gUM with sourceId - and the UA 
could go ahead and return a MS immediately (and that MS could be used to 
start negotiation).

But the first time the user is at a site, isn't there a two stage thing 
with this model: first select _which_ camera (as Harald has pointed out 
there it may be difficult to start negotiating before the device is 
known), and second the user would have to grant access to it.

I guess the result would that the first time at a site gUM would not 
return (unless the UA magically knows which devices to use without user 
involvement) until the user has been involved.

Stefan
>
> .: Jan-Ivar :.
>
>

Received on Wednesday, 6 November 2013 09:44:11 UTC