Makes clicking the camera button always open the video preview modal
when a camera is already shared on a mobile endpoint even when
skip_video_preview is true.
This allows mobile users to change virtual backgrounds.
Video preview modal opens when user clicks on the webcam selector
button/chevron even if the client is set to skip video preview
(userdata-bbb_skip_video_preview=true).
Added extra proptypes validation to video-list-item
Made sure to add extra ?. checks to voiceUsers as well because... who knows?
Removed unused user role prop from video-list-item
The base peer object reference was moved from the component to service for _reasons_
That caused an issue where the component lifecycle would mess up that
centralized reference dictionary on certain conditions. That could cause viewing
sessions to fail intermittently
This reverts the location of the base dictionary reference back to
video-provider/component
Fix a problem that username in video container isn't wrapped if it's too long.
Fix a problem that can cause the audio indicator to disappear.
Fix some problems with the overflow property.
Refactor in css for the talking indicator be more centralized
- forceRelayOnFirefox: whether TURN/relay usage should be forced to work
around Firefox's lack of support for regular nomination when dealing with
ICE-litee peers (e.g.: mediasoup).
* See: https://bugzilla.mozilla.org/show_bug.cgi?id=1034964
- iOS endpoints are ignored from the trigger because _all_ iOS browsers
are either native WebKit or WKWebView based (so they shouldn't be affected)
Add the <ButtonEmoji/> to the webcam button. Now it
is possible to change the webcam settings and change
your settings without having to turn off sharing.
Modifies the <ButtonEmoji/> component so that it can
receive an onClick per props.
It is possible to disable this feat in the settings.yml
ICE lite servers (eg mediasoup) dont need candidates signaled out-of-band; neither does KMS in certain scenarios
Disable their signaling saves us some ticks in bbb-webrtc-sfu and some bandwidth all around
There could be a race condition where a peer creation (async) would resolve after the provider was unmounted
That would lead to a state inconsistency which could generate all sorts of cryptic problems
Applies to video, listen only and screen sharing
New metadata values: media-server-video, media-server-listenonly, media-server-screenshare; parameter is a String
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.
We now retrieve update information about active video peers, and calculates
download and upload rates. These rates are the sum of data transfered in
all video peers.
Screenshare stats is not being added to the sum, yet.
Let the server generate subscriber offers so that it becomes easier for us to
do payload type normalization between publishers and subscribers
Also split peer creation for pubs and subs into separate methods for clarity
Should fix an issue with the recent Chrome 92 intervention that limits
the number of concurrent WebMediaPlayers (an inner element of
HTMLMediaElements) to 75/40.
Webcam video elements were being left dangling in paused state despite
the elements themselves being cleaned up from the component. That
generated a skewed accounting of WebMediaPlayers in the session.
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
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
Remove parts of a previous connection monitor.
To add some context (as far as my memory goes) to the multiple connection
monitor features the product has, `stats` (currently named `connection status`)
was introduced at the Flash client back in ~2016. @fcecagno and I did it
as a BigBlueButton's Summit activity. Our work was squashed into a single
commit in 92554f8b3e :).
I'm not sure about the whole story behind `network information` (the late
connection monitor added to the HTML5 client) but I assume it should work
as a collector for a bunch of different connectivity monitors. I remember
when it was introduced but I don't know why it wasn't adopted. My best guess
would be because of some performance issues the `user list` had back then.
To follow on why `connection status` replaced `network information` at the
HTML5 client, when I did the `multiple webcams` feature I had to refactor
a big chunk of the `video provider` (#8374). Something that wasn't really
helping there was the adaptation of `stats` that was made to show local
feedback for each webcam connection. Although this feature wasn't being
used anymore, `network information` did rely on that to build up data. With
this monitor gone I assumed it was my responsibility to provide an alternative
so I promoted Mconf's port of the Flash `stats` monitor to BigBlueButton's
HTML5 client (#8579).
Well, that's my perspective on how things went for those features. If
anyone would like to correct me on something or add something else on
that history I would appreciate to know.
