- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Mar 2020 08:44:39 +0000
- To: public-webrtc-logs@w3.org
> We can do a lot of things, but I think we need to start with problems we want to solve. The problem we want to solve here is removing label info either entirely or for devices not used by the given web page. > Also, that's just one use case (needing to replacing a source with another). The general use case is adding a second source. The latter more general use case supports the former. I am not sure how common it is to add a second source of the same device type. Can you be more specific about the use case? Anyway, let's say we want that. The way we are doing this right now (and this proposal does not change anything) is for the web app to call getUserMedia a second time to pick a second device, potentially using enumerateDevices information to pass some specific constraints, like a deviceId. It seems one underlying goal that you might have is to allow a user agent to only expose granted devices as part of enumerateDevices. This is a fine goal and maybe we can go there one day. We probably want to expose some information anyway to let know the page that other devices can be used for instance. This would need more effort and can already be experimented by user agents by gradually exposing enumerateDevices information instead with the devicechange event. > 1. User agents decide the units exposed as unique media input devices OK > 2. Apps express their constraints for a media input device it wants This is the current model. I would rephrase it to: "apps express the constraints for a media input data it wants, not a media input device". Most apps do not care about a particular device as long as it provides audio or video the user actually wants to use. Some apps might want to select the same device as last time. Current API allows that. In general, I think the user agent is best suited to do that job. > 3. User agents pick device within those constraints > 4. A (source) device is shared as one or more tracks. > 5. _"Once selected, the source of the MediaStreamTrack [MUST NOT change](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-same-permission)."_ As long as the user gives consent to use the new device, I do not see any real issue here. Can you be more specific about what will break here for the user? Or the web page, given the web page asked to change the source? On the phone, several apps have a simple button to switch from the user facing camera to the environment facing camera. From the user point of view, the feed remains the same and is expected to go wherever it goes, only the source is changing. > 6. A track's label _"[MUST return the label of the object's corresponding source](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastreamtrack-label)"_ Sounds fine. Aren't we somehow trying to deprecate label though? > 7. Tracks can be cloned Similar to 4 somehow, I do not see any difference between two cloned tracks and two getUserMedia tracks using the same underlying device. > 8. (Cloned) tracks may manipulate (output from) the source through _applyConstraints_ (but not change source) 'but not change source' seems like an artificial limitation. As long as a web page is granted access to both devices and they have the same media type, I do not see any real issue in changing the underlying source, at least when web page is aware of the change. For a phone, a user agent can decide to expose one camera device, supporting both environment and user or two camera devices. Why shouldn't the user agent be allowed to have some UI allowing the user to switch cameras on the fly outside of the web page control? Also, if the page is capturing with both devices, there is no difference between applyConstraints(use_the_other_source) and clone-the-other-source-track-then-applyConstraints-then-replace-track-wherever-needed. > 9. Tracks can end (which may terminate a permission envelope) OK. > What you describe sounds like an entirely different model. That's fine, but I think I'm going to need a convincing problem we don't solve today, to justify spending time considering a new model at this point. Maybe I am missing how different this model differs from today's model. Can you be more explicit? This change seems to me like an incremental change, which targets the issue of 'removing that offending label' or 'removing that device picker'. In particular, this does not require existing web sites to change anything about their current flow to enter a call, grant the prompt... The only adoption needed is in the 'device picker' pane, which might be less crucial. The other problem that it could solve is the fact that, apparently, user agents are not allowed to change the source of a capture track. I question this limitation. A web page might actually want to opt-in to a behavior where the audio input source matches the audio output so that plugging in a headset would automatically start using the headset microphone if audio output goes to the headset speakers. This change also has a potential good story for migrating web sites. First implement it, then sanitize labels for not granted devices to things like microphone1, camera2... -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/669#issuecomment-604884052 using your GitHub account
Received on Friday, 27 March 2020 08:44:46 UTC