This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is the formalization of a proposal made on the mailing list on Sept 9. Proposal: Add output devices to the GetSources call, and add a "group" attribute for device grouping. Rules for attribute visibility should be as for GetSources. Example output: { { 1234, "video", "First camera", group=42}, { 7654, "audio", "First camera microphone", group=42}, { 2345, "audio", "Headset microphone", group=17}, { 3697, "audioOut", "Headset speakers", group=17} } Here, the headset microphone and speaker are part of the same device. WebIDL changes: - Change name of call to GetDevices - Rename "SourceInfo" dictionary to "DeviceInfo" - Add an attribute of type DOMString called "group" - Add "audioOut" and "videoOut" as legal values for the "kind" attribute
Per Sept 24, the suggestion has been made to drop videoOut from the list, because it is not well defined, so it's not clearly useful. The editors will add this to the spec. (boilerplate: This doesn't mean that it's definitely approved, but it does mean that someone has to suggest that it be removed in order to take it out again.) Assigning to Adam for implementation.
I think we also agreed to move get[User]Devices to navigator. Adam, do you have an ETA for landing this? We'd like to get this wired up as soon as possible. Harald, wdyt about keeping audio and video as "kind", and adding a separate property to indicate input vs output? "audioOut" feels a bit clunky.
(In reply to Justin Uberti from comment #2) > Adam, do you have an ETA for landing this? We'd like to get this wired up as > soon as possible. Shouldn't be that far away.
Proposed change (rendered snapshot, links not working): http://htmlpreview.github.io/?https://github.com/fluffy/webrtc-w3c/blob/master/getusermedia.html#enumerating-devices
This change looks great. Wdyt about a corresponding .onmediadeviceschange callback to indicate when the list of media devices has changed?
What is the motivation for oldList? If it is just to preserve groupId members within the session, then this looks good as written. OTOH if the intent is also to preserve the internal order of devices on oldList in newList, then in step 4.1 under getMediaDevices, the fragment "move that object to resultList" should read "append that object to resultList".
(In reply to Jói Sigurðsson from comment #6) > What is the motivation for oldList? If it is just to preserve groupId > members within the session, then this looks good as written. OTOH if the > intent is also to preserve the internal order of devices on oldList in > newList, then in step 4.1 under getMediaDevices, the fragment "move that > object to resultList" should read "append that object to resultList". The idea is to have the groupId stable during the session. There's no attempt to, e.g., keep a device at a stable index in the list since devices may come and go during a session. In this context "move" = remove from oldList and append to newList. Does that seem right? Should we clarify? Thanks for providing feedback.
I would suggest changing "move to" to "append to" just so it's clear.
(In reply to Jói Sigurðsson from comment #8) > I would suggest changing "move to" to "append to" just so it's clear. Works for me.
Proposed change: https://github.com/fluffy/webrtc-w3c/commit/970251ff41175e5d02e2a7732ff740c089209e5c
Adam, any more thoughts on .onmediadeviceschange? Do you want us to propose a block of text?