There's an issue where permission-less sessions of video-preview
fail to change video profiles. Whenever gUM is on prompt mode,
deviceIds are obfuscated, which means getInitialCamera will need to
infer the deviceId based on the current media stream.
Since the virtual bg worker is now called synchronously (e28a595),
it'll be extracted incorrectly from the virtual effect MediaStream
(rather than the original stream) - which causes getInitialCamera to
use the effect's deviceId rather than the original stream's deviceId.
Guarantee that deviceId inference via MediaStreamTrack uses
BBBVideoStream's originalStream (so that virtual effect streams are
bypassed). Also remove the call to updateDeviceId in getInitialCamera
since it's redundant since commit e28a595.
A change in e28a595b52 introduced an issue where the "Share camera as
content" modal always has it's "share" action flagged as disabled. This
is due to a short-circuit introduced in the initial gUM procedure that
does not clear the "disabled" state before exiting.
Properly reset the "disabled" sharing state after the initial gUM in
video-preview when "Share camera as content" is used, thus fixing the
aforementioned issue.
* 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
Prevents the same camera device from being shared twice(webcam and "camera
as content"). The camera device shared using the camera as content feature
is tracked locally and then taken into account in the video-preview modal.
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.
