LGTM2 On Wednesday, June 22, 2022 at 5:41:51 PM UTC+2 Chris Harrelson wrote:
> 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/05fcc18f-d8e7-426a-a04e-d636433cd01en%40chromium.org.
