The original BBBVideoStream termination handlers are being overwritten
by screen sharing's service when "Present camera" is started, which
causes the stream not to be dereferenced in the VIDEO_STREAM_STORAGE
map when the camera presentation stops. This breaks subsequent
camera/present camera attempts for the affected deviceId.
The second issue with is that Chrome isn't assigning the
termination handlers for the screen sharing subsystem - which causes
device/permission ejections to be silent.
This extends screen sharing's trackStreamTermination routine to preserve
whatever previous termination handlers were assigned if the stream was
provided beforehand by an external caller - which should fix both of the
aforementioned issues.
This commit removes the wake lock activation toast along with the
enable/disable buttons, implementing the wake lock implicit activation
behavior. The wake lock feature is implicitly activated if the
`defaultSettings.application.wakeLock` in the `settings.yml` file is set
true. For mobile devices that do not support the API or fail when
requesting a wake lock, toasts are raised explaining that calls will be
dropped when the screen turns off.
In cases where `defaultSettings.application.wakeLock` is set false, users
can enable the wake lock manually through the settings menu.
* prevent duplication of presentation menu dropdown when visible
* move presentation options dropdown to the left (out of tldraw UI)
* adjust style menu UI in RTL
The original debounce implementation (lodash) preserved the
caller's context - radash didn't, so it was failing and it wasn't noticed.
The new debounce implementation with the native function seems to preserve caller's context, but as a safety measure this commit binds the method to its appropriate scope.
This is an initial, experimental implementation of the feature proposed in
https://github.com/bigbluebutton/bigbluebutton/issues/14021.
The intention is to phase out the explicit listen only mode with two
overarching goals:
- Reduce UX friction and increase familiarity: the existence of a separate
listen only mode is a source of confusion for the majority of users
Reduce average server-side CPU usage while also making it possible for
having full audio-only meetings.
The proof-of-concept works based on the assumption that a "many
concurrent active talkers" scenario is both rare and not useful. With
that in mind, this including two server-side triggers:
- On microphone inactivity (currently mute action that is sustained for
4 seconds, configurable): FreeSWITCH channels are held (which translates
to much lower CPU usage, virtually 0%). Receiving channels are switched,
server side, to a listening mode (SFU, mediasoup).
* This required an extension to mediasoup two allow re-assigning producers
to already established consumers. No re-negotiation is done.
- On microphone activity (currently unmute action, immediate):
FreeSWITCH channels are unheld, listening mode is deactivated and the
mute state is updated accordingly (in this order).
This is *off by default*. It needs to be enabled in two places:
- `/etc/bigbluebutton/bbb-webrtc-sfu/production.yml` ->
`transparentListenOnly: true`
- End users:
* Server wide: `/etc/bigbluebutton/bbb-html5.yml` ->
`public.media.transparentListenOnly: true`
* Per user: `userdata-bbb_transparent_listen_only=true`