Re: [mediacapture-screen-share] Capturing audio-only (#100)

The question of use-cases is interesting and I'll get back to that. Quick recap first of the benefits of supporting audio-only, assuming use-cases exist:
* Benefit to the user:
  * Enhance privacy through not having to share more than strictly intended.
* Benefit to the application:
  * Improved relationship with the user - no need to alarm the user by asking for irrelevant permissions. (Users should not be expected to understand that the app cannot capture audio without video.)
  * Improved efficiency (avoid unnecessary CPU/GPU load by unnecessarily maintaining screen- or tab-capturing).
* Benefit to the browser:
  * Improved efficiency (see above).
* Benefit to the Web platform:
  * Better-educated users - make it more common to only share what's strictly necessary.

Clearly an all-round win - provided we have the use-cases. Back to that, then. :-)
* Audio-record meetings into a file. (One app captures another; no integration needed.)
* Record lectures, music, etc.  (One app captures another; no integration needed.)
* Call centers. Assume you're building software that exposes some functionality to the operator - some CRM-like software. Your software imports some functionality by embeding some VC application in an iframe, allowing you to talk to the customer/patient/colleague while interacting with the CRM-like software concerning his call. By recording tab audio, your own software now quickly gets to record the call to a file without having to integrate more closely with the VC software you're embedding. No need to ask them to make changes to accommodate you as a customer, wait for that to happen - you just implement recording of (i) the tab and (ii) the mic and you're all set.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 29 March 2022 11:25:59 UTC