Re: Proposal to add defaultDevice attribute to getMediaDevices.

Most of the folks are silent on this proposal... is that silence means
supports or oppose... ?
I welcome your inputs.


On Fri, Mar 14, 2014 at 2:07 PM, Kiran Kumar <g.kiranreddy4u@gmail.com>wrote:

> Gili,
>
> AFAIK app will not have any control on selecting another device, in case
> of unavailability of the selected device.
> For example., If 3 devices are available and App is showing 1 as default
> (according to its previous selection), 2 is the device selected by user,
> and 3 is the default device according to browser platform. In this case if
> user selects device-2 and if it is not available, then browser will get the
> access for device-3 and not device-1 as shown by app. App will fail in this
> case.
>
> Another scenario is, if the previously selected device is not available in
> the list of devices (in case if that user moves from home to office where
> he has used some external device etc .. ) App can not judge a default
> device.
>
> If App is really willing to show the default as that corresponding to
> previously selected one, then it can choose it with default selection but
> highlight the browser specified default device to indicate that the
> highlighted device will be selected in case of unavailability of selected
> device. (Since this specification does not have any control on app
> implementations, this is just my suggestion as one way for implementing
> App).
>
>
>
> On Fri, Mar 14, 2014 at 11:50 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
>>  The concept of a "default" device without a context seems like a losing
>> proposition. As Harald mentioned, there is no objective "default" when
>> choosing between front and back cameras on a phone. I suggest that the
>> "default device" should really corresponds to the last selected device in
>> some application-defined context. Meaning, applications will probably want
>> to default to the last device used and expect different "defaults"
>> depending on the context (e.g. microphone plugged in, or not).
>>
>> Gili
>>
>>
>> On 14/03/2014 1:11 AM, Kiran Kumar wrote:
>> >
>> >
>> >
>> > On Fri, Mar 14, 2014 at 2:34 AM, Harald Alvestrand
>> > <harald@alvestrand.no <mailto:harald@alvestrand.no><harald@alvestrand.no>>
>> wrote:
>> >
>> > On 03/13/2014 01:32 PM, Kiran Kumar wrote:
>> >> Dear Harald, Please find my comments inline.
>> >>
>> >>
>> >> On Thu, Mar 13, 2014 at 2:48 PM, Harald Alvestrand
>> >> <harald@alvestrand.no <mailto:harald@alvestrand.no><harald@alvestrand.no>>
>> wrote:
>> >>
>> >> On 03/12/2014 12:32 PM, Kiran Kumar wrote:
>> >>> Hi, I would like to add this to bug list. Please let me know if
>> >>> you have any comments.
>> >>
>> >> I would like to not add it.
>> >>
>> >> As has been noted, there isn't always an obvious default device. So
>> >> if the flag is added, the JS must be written to handle the
>> >> condition where no default device is in the list. But since this
>> >> may be a rare case, JS apps might choose to ignore this possibility
>> >> - which is bad for app portability.
>> >>
>> >>
>> >> [Kiran] It is not obvious to have a defaultDevice but most of the
>> >> mobile devices have default devices like front camera or back
>> >> camera... Any new thing will increase the processing, but I don't
>> >> agree addition of this attribute will result in too much complexity
>> >> for checking. Generally most of the devices have a single device.
>> >
>> > Actually you illustrate my point. Which of the front and back cameras
>> > on my phone is the "default" camera?
>> >
>> > *[Kiran]* This attribute helps in determining that.
>>
>> >
>> >
>> > Also, the moment you plug a Bluetooth or USB headset into a device,
>> > it has multiple audio devices. I think the theory that most devices
>> > have a single device (of each type) is a weak one.
>> >
>> > *[Kiran]* Agreed.
>>
>> >
>> >>
>> >>
>> >>
>> >> If the JS wishes to get a device, and it doesn't care about which
>> >> one, it could just getUserMedia(). Which one is returned may vary
>> >> depending on configuration parameters, constraints, or whether some
>> >> other program has opened the device (for OSes that do exclusive
>> >> device access).
>> >>
>> >> [Kiran] This will be helpful to give the judgement to user,
>> >> ofcourse getMediaDevices() itself is meant for that. But in some
>> >> applications, we can have a use case like if the selected device is
>> >> not available, then go for the default device, instead of resulting
>> >> in error.
>> >>
>> >> [Kiran] For example, my laptop is having a built-in-camera, when I
>> >> want to chat with my friend, I will attache a webcam that supports
>> >> high definition/ with higher pixel number. I prefer to access the
>> >> external webcam attached, but if I am not able to access that in
>> >> any case, instead of resulting in failure it will select the
>> >> default built-in-camera.
>> >
>> > That's how it's supposed to work if you give the ID of your attached
>> > webcam as an optional constraint: If it's not available, you'll get
>> > another one.
>> >
>> >
>> > *[Kiran]* If the devices is enabled with 3 devices, as you specified
>>
>> > above like through Bluetooth or any other means, and if the device
>> > selected by user is not available, then out of the 2 remaining
>> > devices, how the user can come to know which one it will be selected
>> > by default ?
>> >
>> >>
>> >> The only use case I can see is to preselect the default device in a
>> >> list of devices, so that the user can tell which device will be
>> >> opened if he doesn't select one - and as seen above, this is not
>> >> guaranteed to be the device that actually gets selected (some other
>> >> program may have grabbed it before the user selects a device).
>> >>
>> >> [Kiran] I agree.
>> >>
>> >> I see increased complexity, without a corresponding size of
>> >> benefit. So I'd like to not do this.
>> >>
>> >>
>> >> [Kiran] I see more benefit as  I explained in the above example.
>> >> What do you say ....
>> >
>> > *[Kiran] *I can say one more use case here, that instead of just
>>
>> > default selection. 1. An app can provide the default selection for
>> > the high resolution camera or sophisticated mic and highlight the
>> > default devices, so that if the selected device is not available,
>> > then highlighted device will be selected. 2. If user selects a third
>> > device instead of default selected device and the platform default
>> > device, then in case of in-availability of selected device, it should
>> > select the default device.
>> >
>> > I'd like more opinions...
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>> On Mon, Mar 10, 2014 at 3:43 PM, Kiran Kumar
>> >>> <g.kiranreddy4u@gmail.com <mailto:g.kiranreddy4u@gmail.com><g.kiranreddy4u@gmail.com>
>> >
>>
>> >>> wrote:
>> >>>
>> >>> It is not universally true for all,
>> >>>
>> >>> When I connect an external webcam to my desktop PC, which has no
>> >>> camera, Mozilla is displaying its names as YUV-xxx-camera.
>> >>> Laptops are also not showing "default" prefix in the names.
>> >>>
>> >>> I am not sure which devices/SO's are showing the "default"
>> >>> prefix.
>> >>>
>> >>> Thanks, Kiran.
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Mar 10, 2014 at 3:19 PM, Iñaki Baz Castillo
>> >>> <ibc@aliax.net <mailto:ibc@aliax.net> <ibc@aliax.net>> wrote:
>> >>>
>> >>> 2014-03-10 6:51 GMT+01:00 Kiran Kumar <g.kiranreddy4u@gmail.com
>> >>> <mailto:g.kiranreddy4u@gmail.com> <g.kiranreddy4u@gmail.com>>:
>>
>> >>>> I would like to propose adding a defaultDevice attribute which
>> >>>> indicates which device is the default device out of the list.
>> >>>>
>> >>>> dictionary MediaDeviceInfo { DOMString       deviceId;
>> >>>> MediaDeviceKind kind; DOMString       label; DOMString
>> >>>> groupId;
>> >>>>
>> >>>> bool            defaultDevice; };
>> >>>>
>> >>>> This will allow a default value checked while displaying the
>> >>>> list of devices.
>> >>>
>> >>>
>> >>> Correct me if I'm wrong, but AFAIK the multimedia subsystem in
>> >>> some SO's report a "default sound card", "default mic" and
>> >>> "default webcam".
>> >>>
>> >>>
>> >>> -- Iñaki Baz Castillo <ibc@aliax.net <mailto:ibc@aliax.net><ibc@aliax.net>
>> >
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>