24015 2013-12-06 01:31:48 +0000 Add callback to indicate when available media devices change 2014-06-10 14:37:09 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified All All RESOLVED FIXED P2 enhancement --- 1 juberti public-media-capture adam.bergkvist harald praveen.j public-media-capture stefan.lk.hakansson oldest_to_newest 97227 0 juberti 2013-12-06 01:31:48 +0000 Forked from https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263. The idea here is to have a callback that apps can register for to learn when a new device becomes available (or is removed). The main use case here is for a Bluetooth headset - if one shows up, the app may want to display a button indicating the call can be transferred to the headset, and remove that button if the headset disappears. Currently this would require the app poll the getMediaDevices API on a regular basis, which is inefficient at best. I suggest the name navigator.onmediadeviceschange for this API. 97741 1 stefan.lk.hakansson 2013-12-17 13:08:33 +0000 When this was last discussed, it was deemed that it was sufficient to poll for new devices. 97756 2 juberti 2013-12-17 20:07:09 +0000 Agreed, but after actually working with the API I think that polling is clumsy; to get the behavior described below, you would have to poll the API about every second for the entire lifetime of the call. 105675 3 praveen.j 2014-05-12 05:42:26 +0000 Implementations like navigator.geolocation.watchPosition makes sense when there is a continuous update as in case of location co-ordinates(ex: travelling in a car). Also, these attributes have wide range of values. In case of WebRTC calls, you have limited no. of media input/output devices and they are either plugged or unplugged. Polling mechanism in this scenario will be a burden on overall system. Callback mechanism should be fine. 106788 4 harald 2014-05-26 10:08:03 +0000 Discussed at the Media Capture TF on May 19. Consensus that this is needed. Suggestion (made later in the meeting): Create a Navigator.mediaDeviceHandler object that can hold the ondevicechange handler event, as well as a possible getUnderstoodConstraintNames function that was suggested in another context. A concrete proposal is expected. 106793 5 adam.bergkvist 2014-05-26 12:04:07 +0000 Here's a proposal. Regarding the name, I don't think the -handler or -manager suffixes add much. The sibling object for geolocation is simply called "geolocation" so I suggest MediaDevices, UserMedia or something. partial interface NavigatorUserMedia { // kept for legacy purposes void getUserMedia (MediaStreamConstraints? constraints, NavigatorUserMediaSuccessCallback successCallback, NavigatorUserMediaErrorCallback errorCallback); readonly attribute UserMedia userMedia; }; Navigator implements NavigatorUserMedia; interface UserMedia : EventTarget { // this belongs there void getUserMedia (MediaStreamConstraints? constraints, NavigatorUserMediaSuccessCallback successCallback, NavigatorUserMediaErrorCallback errorCallback); attribute EventHandler? ondevicechange; void enumerateDevices (MediaDeviceInfoCallback resultCallback); // place future function for constraint name probing here }; MediaDeviceInfoCallback is already in the spec. The function enumerateDevices() replaces the current async getMediaDevices() function. The new function could be synchronous (as in Martins proposal) if we do the work of preparing the return value in advance every time the device list changes. I don't have a strong opinion about it. We don't need a new event type since the event only notifies that there's new info available elsewhere (accessed by querying an other function). If the app wants to know about changes, it has to keep a reference to an old list and compare. Once we have settled for a first version name, I think we can start editing this into the spec. 106913 6 adam.bergkvist 2014-05-28 12:37:20 +0000 Proposed fix: https://github.com/fluffy/webrtc-w3c/commit/de3bdaf83d2cc1350cc3be970baf1d11219add1d