Sometimes a screen-capture is started without sharing audio, but the user might later want to enable audio for the capture. To support this, a user agent can include a muted audio track from the start if the application requests audio even if the user does not share audio. If the user later enables audio-sharing, the audio track can be unmuted.
This behavior is already allowed according to the screen-capture spec [link]:
If the user agent knows no audio will be shared for the lifetime of the stream it MUST NOT include an audio track in the resulting stream.
This means: If a user agent provides an option to enable audio sharing after the capture has started, it does not know that no audio will be shared for the lifetime of the stream, and it MAY then include an audio track in the resulting stream.
However, for backward compatibility with applications that use the presence of an audio-track to determine if a user shared audio or not, we propose that a hint is added to enable this behavior:
getDisplayMedia({alwaysReturnAudio: “include”});
Initially, the default value for this option should be “exclude”, but as applications are updated to not rely on the presence of an audio track to determine if audio has been shared, it should be possible to change the default value to “include”, and eventually remove this option. The default value for this option can be left unspecified to let each browser vendor decide.
Note: This is a new issue separated out from https://github.com/w3c/mediacapture-screen-share-extensions/issues/4
Sometimes a screen-capture is started without sharing audio, but the user might later want to enable audio for the capture. To support this, a user agent can include a muted audio track from the start if the application requests audio even if the user does not share audio. If the user later enables audio-sharing, the audio track can be unmuted.
This behavior is already allowed according to the screen-capture spec [link]:
This means: If a user agent provides an option to enable audio sharing after the capture has started, it does not know that no audio will be shared for the lifetime of the stream, and it MAY then include an audio track in the resulting stream.
However, for backward compatibility with applications that use the presence of an audio-track to determine if a user shared audio or not, we propose that a hint is added to enable this behavior:
Initially, the default value for this option should be
“exclude”
, but as applications are updated to not rely on the presence of an audio track to determine if audio has been shared, it should be possible to change the default value to“include”
, and eventually remove this option. The default value for this option can be left unspecified to let each browser vendor decide.