LGTM1 On Tue, Jun 14, 2022 at 4:11 AM 'Andy Paicu' via blink-dev < [email protected]> wrote:
> Sounds good, thank you for the clarifications. > > Kind Regards, > Andy Paicu > > > On Mon, Jun 13, 2022 at 8:18 PM Elad Alon <[email protected]> wrote: > >> 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 >> >> On Mon, Jun 13, 2022 at 8:02 PM Andy Paicu <[email protected]> wrote: >> >>> 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 >>> >>> On Wednesday, June 1, 2022 at 9:40:02 AM UTC+2 Elad Alon wrote: >>> >>>> 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. >>>> >>>> On Wed, Jun 1, 2022 at 8:42 AM Yoav Weiss <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Wednesday, May 25, 2022 at 2:44:01 PM UTC+2 Elad Alon wrote: >>>>> >>>>>> Contact [email protected] >>>>>> >>>>>> 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 componentBlink >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >>>>>> >>>>>> TAG reviewN/A. This is just an addition of a single flag to an >>>>>> existing dictionary, following well-known patterns. >>>>>> >>>>>> TAG review statusNot 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! >>>>> >>>>> >>>>>> >>>>>> *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 >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ?No >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> No milestones specified >>>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5201258309746688 >>>>>> >>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cANVKeNMHyE >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYiUCZ_En3oei9xgn9T5CH9t%3D4FNb50RzHDdg%3DE69mL62A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8ndgggdgHPg7p24PHqhQw6qwrnMrBVtnQk_h5ExacBgQ%40mail.gmail.com.
