* fix(webcam): client failing to apply virtual background effect
* fix: check for already dispatched background
* fix: make webcam start up with last selected virtual background
Enables the presenter to share a camera in the presentation area.
The shared camera automatically uses a pre-defined, fixed and hidden camera.
Profile defined in the settings.yml file.
It is currently using the screenshare's backend.
tl;dr: switching camera profiles in video-preview fails intermittently
in Chrome/Edge.
Long version: Chrome/Edge sometimes bork gUM calls when switching camera
profiles. This looks like a browser bug (issue TBD). Track release not
being done synchronously -> quick subsequent gUM calls for the same
device (profile switching) -> device becoming unavaible while previous
tracks aren't finished.
Since track stop is not "awaitable", this commit adds a retry procedure
that re-runs gUM up to 5 times (200 ms delay) only if error.name is
NotReadableError and browser is either Chrome or Edge.
The 'inactive' event is fired whenever the stream gets inactive (ie it
cannot be used anymore), and there are scenarios where that is
unexpected behavior and must be handled accordingly.
The main example of that is when gUM permissions are revoked by the user
via the browser's permission management panel.
Since MediaStream/Track inactive events aren't being handled in such
scenarios, what actually happens is that the camera just freezes without
further indication why.
This commit handles those scenarios in both video-preview and
video-provider by:
- 1) correctly stopping the camera (provider)
- 2) surfacing a toast (provider) or error indication (preview)
Changes (maybe not a complete list):
- Disable virtualbgs by default
- Move the virtualbg selector in video-preview to the side below the
profile selection
- Restore old video-preview sizes
- Add a wrapper class for MediaStreams (BBBVideoStream)
- Centralize virtualbg services and business logic code into BBBVideoStream
- Refactor and centralize virtualbg constant fetching
- Refactor and centralize virtualbg config fetching
- Organize virtualbg type definitions
- Remove added states in video-provider to prevent further bloat
- Remove added states in video-preview to prevent further bloat
- Lock virtual bg switching while video-preview itself is locked
- Add proper virtualbg error surfacing via toasts
- Refactor iOS availability detection to use centralized UA checker
- Avoid calling gUM when toggling virtualbgs on/off
- Make virtualbg video-list-item action a toggle instead of a
state-aware action
- Make virtualbg switching work in video-preview for cameras that are
already shared. Especially useful when there are multiple source
cameras, and will be important in the near future
- Add Derivative Work notices in files that are partially copied from
jitsi-meet
- Simplify track replacing in video-provider
- Split video-preview UI code for virtualbgs into a separate functional component
Firefox doesnt fire the ended evt/onended callback for live video mediastreamtracks. That caused the stream storage to not run the cleanup procedure in some scenarios
Manually emit the ended event which works with the onended callback when a track is stopped
Shave off the number of calls in video-preview and video-provider by
using a stream storage
We don´t call an upfront gUM in video-preview anymore to lift the
fingerprinting barrier on device labels and IDs. Flow has been reversed:
upfront enumerate, load first preview, then check if previous
enumeration was obfuscated.
Add a stream storage in video-preview`s service to avoid re-fetching
them in video-providerj
Remove some unneeded video-preview container props
Improve some of video-preview`s error locales
Some browsers seem to (occasionally) not return the getUserMedia promise call and the
user gets stuck in this state unable to share her/his webcam.
Since enumerateDevices still works even on a gUM rejection this includes a racing
timeout that skips gUM. Configured at settings `gUMTimeout`.
Reproduced with Windows 10 Chrome 87.
