* feat(screenshare): Option to show disabled screenshare button for non presenters
* Update bigbluebutton-html5/imports/ui/components/screenshare/service.js
---------
Co-authored-by: Ramón Souza <contato@ramonsouza.com>
* Refactor: Make bundle using webpack
* Fix: restore after install codes and a few settings
* Fix: build script folder permission
* Refactor: Remove support to async import on audio bridges
* Upgrade npm using nvm
* Avoid questions on npm ci execution
* Let npm ci install dev dependencies (as we need the build tools here)
* Fix: enconding
* Fix: old lock files
* Remove: bbb-config dependency to bbb-html5 service, bbb-html5 isn't a service anymore
* Fix: TS errors
* Fix: eslint
* Fix: chat styles
* npm install with "lockfileVersion": 3 (newer npm)
* build: allow nodejs 22
* node 22; drop meteor from CI and bbb-conf
* TEMP: use bbb-install without mongo but with node 22 and newer image
* build: relax nodejs condition to not trip 22.6
* build: ensure dir /usr/share/bigbluebutton/nginx exists
* init sites-available/bbb; drop disable-transparent-
* nginx complaining of missing file and ;
* TMP: print status of services
* WIP: tweak nginx location to debug
* Fix: webcam widgets alignments
* akka-apps -- update location of settings.yml
* build: add locales path for nginx
* docs and config changes for removal of meteor
* Fix: build encoding and locales enpoint folder path
* build: set wss url for media
* Add: Enable minimizer and modify to Terser
* Fix: TS errors
---------
Co-authored-by: Tiago Jacobs <tiago.jacobs@gmail.com>
Co-authored-by: Anton Georgiev <anto.georgiev@gmail.com>
Co-authored-by: Anton Georgiev <antobinary@users.noreply.github.com>
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.
Camera as content and screenshare are 2 features that are mutually exclusive
because they share the same space in the UI. This commit adds the behavior
that when one this features is started, the other one is closed if it is
running.
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.
Turns the screenshare component into a generic component, so that it can be
used both for screenshare and camera as content fetures.
Also changes specific locales and icons for the camera as content feature.
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.
The media monitor responsible for triggering the reconnecting view in
the screen sharing component was maintaing the previous state (eg
flowing) in cases where the peer just failed before media stopped
flowing. That triggered an error in the bps calculations that caused the
previous state to be preserved - eg stuck in flowing while it should be
not_flowing.
These changes make it so that if there's not peer to fetch stats from,
them the bps calculations will correctly return 0 (which translates to
not_flowing).
Smart layout (et al) presumes screen sharing will always use 100%
width of the media area. That causes cameras to always be positioned on
top, which is not always the optimal position depending on the viewport
and stream aspect ratio/resolution - so space is wasted.
This commit uses the actual screen sharing video size as provided by
HTMLVideo's videoWidth/videoHeight properties. The calculation uses the
same logic as the one used for presentation/slides, which should make it
a bit familiar.
There's also a handler for HTMLVideo's `resize` event for those browsers
that support it - which enables handling of variable-sized screen
sharing streams. That handler is debounced at 500 ms to prevent
excessive CPU use.
Extra testing is needed with the widest range possible of
browsers/environments and feature combinations.
There could be a race condition where the local getDisplayMedia stream ends
(eg via Chrome`s stop sharing toast) while the broker hasn't finished starting.
That would lead to a scenario where the broker wouldn't emit an end event,
causing screen sharing to be flagged as started with a blank/invalid stream.
Screen streams were only deemed unhealthy when the transport's ICE state
transitioned to failed. That was as good as nothing because the stream would
stay frozen with no visual UI feedback until it reconnected. Bad UX.
This commit addresses that issue via two changes:
- A stream is deemed *potentially* unhealthy now if the transport's
state becomes disconnected
- If a stream is deemed potentially unhealthy, a monitor probe is
started to check whether there is media/packet flow (every 500ms).
If there's no packet flow, the stream is flagged is factually unhealthy and
UI feedback about that is rendered.
It's still not as good as it could be - relying on disconnected still
leaves a couple of seconds of silence to be dealt with. For that to be
addressed the prober would have to run nonstop, but that's for later.
I have growing concerns about gain node`s effect on audio quality the way it
was implemented, so I opted to fall back to HTMLMediaElement`s volume control
for the time being until we can gauge quality impacts properly later on
Add a new configuration flag enableVolumeControl, false by default while the
feature undergoes a field trial
Splits screenshare stream into video and audio and adds gain node to audio
stream in order to permit volume control by the user. Volume is normalized
between [0, 2](muted and 2x boost).
Added support for getStats in screenshare's service. This works similar
to the getStats for video provider, and the information retrieved from
screenshare is added to the video information for cameras.
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
If the presenter gets changed while the user kept the getDisplayMedia browser picker open, accepting the getDisplayMedia prompt might get the previous presenter´s client-side state inconsistent as if they were sharing. The screen sharing is a no-op though
This adds a check after gDM resolves to see whether the user is still the presenter; if they aren`t, just clean up the gDM stream and make it a full no op
