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.
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.
Video streams can be sorted by voice floor activity in the client according to FreeSWITCH´s floor events. The feature works together with pagination, essentially giving an Last-N like experience while not disrupting too much
Made video stream sorting extensible in a way. The sorting modes for pagination and unbounded can be configured in settings.yml and new sorting modes can be added to the stream sorting util under video-provider. Inline docs explain how to do that
Changed how the stream ID attribute from video-streams collection was passed to downstream components; we had an array map that was executed every change just to map stream to cameraId, which is bizarre. So I changed the cameraId usage in downstream components to be conformat with the collection attributes and shaved off the map where it wasnt needed
Add better selectors to video-list-item container´s VoiceUser fetch
New config called paginationThreshold defines classes of page sizes that depend on the number of participants of a meeting
The rationale is pretty much the same as the cameraQualityThresholds, but the thresholds are users here and the ceilings are the page sizes
Problem: setReconnectionTimeout was being called in the first candidate generation to set the negotiation/reconnection timeout up. That caused some browsers or specific scenarios (mainly envs without STUN) to establish the negotiation (playStart) before generating any useful out-of-band candidates (relay). That would cause the timeout to be set AFTER it is supposed to be cleared due to success (playStart), making the webcam drop after a while
So I moved the setReconnectionTimeout call to a safer spot: right after the first negotiation requisition goes out to bbb-webrtc-sfu
There's some scenarios that video errors triggers multiple toast notifications
that don't have any mapped defined message feedback so they all drop to the default
permission error. This leaves the impression that something is broken at the toast
container.
Since those messages don't bring up much information about the problem we can avoid sending
them until we don't have a more informative one to notify the user.
When multiple actions were bolted in the dropdown (mirror, focus), keys were getting duplicated with cameraId. Make them unique based on the action`s name
Recent fix to the stop all cameras behaviour exposed a bug where the local camera connecting state wasnt being cleared up when a camera timed out before being successfully shared
Video provider's service for local stream control was wrongly setting the disconnected
state when a multiple webcam user tried to stop a single cam. The `stopVideo` method
was inconsistent when called multiple times for the same `cameraId`.
Included a better testing scope for event dispatching and disconnected state handling.
BigBlueButton already allows mirroring the users own webcam as a global
setting set by administrators. Users have no way of choosing this on
their own.
This patch turns this functionality into a user setting for all webcams.
Every camera menu now gets a “mirror” entry.
The global setting is still used as a default value, keeping the current
behavior as it is to not confuse users.
This is a very simple patch improving the support for 16x9 cameras.
In mixed mode – if 4x3 and 16x9 cameras are present – everything looks
like it did before but if only 16x9 (or wider) cameras are present,
BigBlueButton will drop the letter boxes and show a 16x9 video
container.
