- From: Henrik Boström <hbos@google.com>
- Date: Thu, 6 Sep 2018 11:28:22 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: silviapfeiffer1@gmail.com, public-webrtc@w3.org, public-media-capture@w3.org
- Message-ID: <CAEbRw2x1-2bASJymp8zDc9HyRPU75+dc0OPP5=fxJ-+qbrpBfg@mail.gmail.com>
On Thu, Sep 6, 2018 at 1:57 AM Martin Thomson <martin.thomson@gmail.com> wrote: > On Wed, Sep 5, 2018 at 11:24 PM Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: > > > > We definitely want the audio of the shared screen be able to be added > > to the screenshare stream. However, the audio of the user should be > > excluded because that makes the audio unusable if you already have a > > video call going and add the screenshare. The more separate streams > > there are, the easier it is to control and add them individually. > > Typical conference applications don't play local audio back, so > capturing a tab (or the entire system) should be sufficient for that > use case. > The problem isn't including the microphone's noise in the screen sharing but if the remote participants are talking and that is played out at the person who is screen sharing, included in the screen sharing stream. The remote participants would hear themselves (and other participants twice!) when they receive the screen share. Echo cancellation would not work in this case (too loud + other participants not just microphone). > The intent with the spec was to avoid excluding audio, though we > certainly should have text in there that does a few things: > > 1. acknowledge the possibility > 2. note that the default is no audio (you have to explicitly request it) > 3. note that the browser chooses how much audio comes with any given > share (for instance, platform limitations might make it impossible to > capture audio from the entire system, or it might be impossible to > separate audio from a single app). > 4. observe that the UX considerations around sharing audio capture > complicate permissions interactions more > > I think that's all I have. I'd be interested in seeing pull requests > on the spec for those changes (ideally in parts). >
Received on Thursday, 6 September 2018 09:29:02 UTC