Re: getUserMedia and disconnecting devices

This discussion belongs the the media-capture TF; I'm putting that list 
as "to:", and webrtc as cc. Please continue this discussion on the
public-media-capture@w3.org list.

Br
Stefan

On 05/14/2012 06:50 AM, Alexey Aylarov wrote:
> Hello,
>
> I think it's better to make it as flexible for developers as possible.
>
> PERMISSION_DENIED has to be presented to let developers handle this event
> and it's a good idea to let them re-ask the access again if user denied it
> accidentally. Probably it's already implemented in this way.
>
> NOT_SUPPORTED_ERR sounds like reasonable event for the case when there are
> no audio/video recording devices at all.
>
>
> DEVICE_NOT_AVAILABLE could be a good event for the case when device is
> presented, but by some reason is unavailable while access request.
>
>
> BR,
> Alexey Aylarov
>
> 5/11/12 7:38 PM пользователь "Marcin Simonides"<msimonides@opera.com>
> написал:
>
>> Hello,
>>
>> I wish to clarify how errors should be reported by getUserMedia in case
>> no devices are available or when a device is disconnected.
>>
>> Let's assume there is a PC with USB camera that may be attached and
>> detached and
>>
>>    getUserMedia({ video: true }, success_callback, error_callback)
>>
>> is called. (an analogous situation could arise with the use of other
>> devices like a Bluetooth headphone)
>>
>> Case 1: no camera attached.
>> When there's no camera at all there are two possibilities: throw a
>> NOT_SUPPORTED_ERR exception or call error_callback with the only
>> available error code: PERMISSION_DENIED.
>>
>> NOT_SUPPORTED_ERR sounds like a more appropriate error than
>> PERMISSION_DENIED when there is no device but step 9 of the algorithm[1]
>> says "...due to platform limitations, jump to the step labeled failure
>> below."
>> The "failure" step says that the error_callback should be called.
>>
>> Case 2: camera attached when calling getUserMedia but detached before
>> the user has granted permission for its use.
>>
>> In this case a sensible way to handle the error is to abort the UI for
>> asking user consent and call the error_callback. Again, the only
>> possible error code is PERMISSION_DENIED.
>>
>> Case 3: camera is attached and the user grants permission for its use,
>> success_callback is called with a LocalMediaStream object and then the
>> camera is detached.
>>
>> In this case the LocalMediaStream should be stopped when the camera is
>> disconnected and an ended event should be dispatched.
>>
>>
>> In cases 1 and 2 the best approach seems to be calling the
>> error_callback with PERMISSION_DENIED but this code doesn't sound
>> appropriate.
>> Therefore I suggest to introduce a new error code, e.g.
>> DEVICE_NOT_AVAILABLE.
>>
>>
>> Alternatively, since distinguishing between PERMISSION_DENIED and
>> DEVICE_NOT_AVAILABLE is of little value to the web developer (other than
>> maybe displaying an appropriate error message), the PERMISSION_DENIED
>> error code could be renamed DEVICE_NOT_AVAILABLE or something else that
>> is general enough to cover both cases.
>> --
>> Marcin Simonides
>>
>> [1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#local-content
>> --
>> Marcin Simonides
>>
>>
>
>
>
>

Received on Monday, 14 May 2012 06:50:58 UTC