Intent to Ship: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

[Elad Alon]

Contact emails

elad...@chromium.org

Explainer

https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing

Specification

https://github.com/w3c/mediacapture-screen-share/pull/164/files

Summary

Consider a Web application APP which is display-capturing a tab TAB. We add a mechanism by which APP may control whether the audio playing in TAB would be played out of the user’s local speakers.

Blink component

Blink

TAG review

N/A. This is just an addition of a single flag to an existing dictionary, following well-known patterns.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/641) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2022-May/032252.html) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

Web developers: Positive

• This was requested by multiple Web-dev teams inside of Google.
• External developers have asked for a different change in Chrome, which we'll be able to uncontroversially affect only once this API surface is shipped - see crbug.com/1317964 for some details.

Other signals:

WebView application risks

N/A

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. Supported on all platforms that support getDisplayMedia. (Namely, all desktop platforms.)

Is this feature fully tested by web-platform-tests?

No

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5201258309746688

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/cANVKeNMHyE

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Wednesday, May 25, 2022 at 2:44:01 PM UTC+2 Elad Alon wrote:

Contact emails

elad...@chromium.org

Explainer

https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing

Specification

https://github.com/w3c/mediacapture-screen-share/pull/164/files

Summary

Consider a Web application APP which is display-capturing a tab TAB. We add a mechanism by which APP may control whether the audio playing in TAB would be played out of the user’s local speakers.

Blink component

Blink

TAG review

N/A. This is just an addition of a single flag to an existing dictionary, following well-known patterns.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/641) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2022-May/032252.html) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

Similar to other intents, this doesn't count as an official positive signal. Let's wait a few days to see if one emerges.

 

Web developers: Positive

• This was requested by multiple Web-dev teams inside of Google.
• External developers have asked for a different change in Chrome, which we'll be able to uncontroversially affect only once this API surface is shipped - see crbug.com/1317964 for some details.

That's encouraging!

[Elad Alon]

Similar to other intents, this doesn't count as an official positive signal. Let's wait a few days to see if one emerges.

Thanks. I've set a reminder to ping this thread in one week, as suggested in the other intent thread.

[Andy Paicu]

A question came up when reviewing this, I'm hoping you can help clarify:

How does the capturing web app (i.e. Meet) know what I want to do with audio? Would I not be able to achieve the same result by simply muting the tab or even just muting the device (since it seems unlikely that there are other sounds wanted from the local device when sharing a tab with audio)?

This seems like it would be better under the control of the user instead of being a decision made by the application especially since I don't see a mention of how this would be presented to the user and/or potentially reverted by them.

Kind Regards,

Andy Paicu

[Elad Alon]

Hi Andy,

How does the capturing web app (i.e. Meet) know what I want to do with audio?

 

The capturing application might know that you're in a physical room and "presenting" to the equipment there.

• You use a special user-journey to trigger sharing to a room.
• The application could be "watermarking" audio coming in through the room's speakers.
• You might have indicated a desire to suppress-local-audio through in-content controls the application exposes.

In either case, it is extremely likely that you only want to hear the audio only through one set of speakers. The application would be saving you effort by muting one set of speakers for you.

This seems like it would be better under the control of the user

Users can mute tabs manually. This new API surface will not prevent this.

i.e. Meet

It bears mentioning that Meet is currently using screen-sharing through an API which I am trying to deprecate. That API already hard-codes to always suppress-local-audio on a captured tab. The present new API surface improves on the state of the art by (i) making this conditional and (ii) exposing it to the Web at large.

Thanks,
Elad

[Andy Paicu]

Sounds good, thank you for the clarifications.

Kind Regards,

Andy Paicu

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYiUCZ_En3oei9xgn9T5CH9t%3D4FNb50RzHDdg%3DE69mL62A%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05fcc18f-d8e7-426a-a04e-d636433cd01en%40chromium.org.

[Joe Medley]

When do you hope to ship this?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYiUCZ_En3oei9xgn9T5CH9t%3D4FNb50RzHDdg%3DE69mL62A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05fcc18f-d8e7-426a-a04e-d636433cd01en%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5ad483c-7ad9-7412-df6f-e25be1c15f86%40gmail.com.

[Elad Alon]

When I have an exact date, I will update ChromeStatus and ping this thread with the target. Currently, I only know that it will be before EoY, but no earlier than August.

[Elad Alon]

This is shipping in m109.

[Joe Medley]

Thanks.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.