- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Feb 2024 08:50:55 +0000
- To: public-webrtc@w3.org
eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-screen-share-extensions: == Avoid user-confusion by not offering undesired audio sources == User agents may offer audio to be captured alongside video, if the application specifies `{audio: true}`, or maps `audio` to anything else that's different from `false`. But **not all audio is created alike**. Consider video-conferencing applications. Tab-audio is often useful, and can be shared with remote participants. But system-audio includes participants' own audio, and it is NOT desirable to share it back. State of the art? VC applications can ask for "audio", use it if it's tab-audio, and discard it otherwise. This works, but it's sub-optimal. The user is left confused. The user wanted to share system-audio, the user was offered to share-system, the user **explicitly approved** sharing system-audio - and now remote participants are telling the user that they can't, in fact, hear the system-audio. Now how messed up is that?! It'd be better if we allowed the application to **ask for less**. Allow the application to ask for audio only in conjunction with surfaces of type X. (For example, with constraints.) I think we should debate this in order: 1. Desirability. Are we in agreement that it is desirable to allow the application to ask for less? 2. Mechanism. Provided that we agree on no1, how do we want to shape the control surface? Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/7 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 February 2024 08:50:56 UTC