feat(stats): Get audio levels for the top 5 speakers only.
Capture the audio levels only for the top 5 speakers as RTCRtpReceiver#getSynchronizationSources can be expensive when we have too many audio receivers in the call.
Also, capture the audio levels for track that are unmuted if RTCRtpReceiver#getSynchronizationSources is not supported.
Switch Safari to using getStats since its reporting errorneous values, i.e., 0.000001 as audio level for all remote audio tracks.
* fix(TPC): Configure degradation preference in RTCRtpSendParameters.
Properly configure degradation preference on RTCRtpSendParameters instead of RTCRtpEncodingParameters. Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1510.
* feat(JingleSessionPC): Remove ssrcs from remote desc when a user leaves.
Remove the ssrcs (associated with remote sources) from the remote desc along with the removal of the remote tracks when an endpoint leaves the call. The source-remove signaling message from Jicofo will no longer be needed in this case and can be dropped.
feat(browser-support): Add support for WKWebview based browsers.
Apple added getUserMedia support for WkWebview based browsers like chrome and Firefox on iOS 14.3. These browsers behave as Safari does on iOS. Therefore, extend the Safari checks to these webkit based browsers as well.
fix(conference): Do not signal muted tracks on join.
Do not add the muted audio/video tracks to the peerconnection on join. The tracks will be added when the user unmutes for the first time. This reduces the number of remote sources that will be added when a participant joins a large call where everyone joins muted (startAudioMuted/startVideoMuted setting).
* Added video mute participant
* Trigger mute event
* Optimized mute type checks
* Fixed event name
* Fixed some linter issues
* Fixed more linter issues
* And even more linter issues fixed
* And more linter fixes
* Added media type to analytics event
When E2EE is disabled we need just set the last key to `false`. When decoding we
need to check if the last key is not false, otherwise we might try to decrypt
the unencrypted video frames, thus resulting in breakage.
fix(SendVideoController): Apply the sender constraint only when it changes.
There were cases where the bridge was sending the same constraint multiple times causing redundant calls to getParameters/setParameters on the RTCRtpSender.
Translate the 'LastNChangedEvent', 'SelectedEndpointsChangedEvent' and 'ReceiverVideoConstraint' messages into the new 'ReceiverVideoConstraints' message that invokes the new bandwidth allocation algorithm in the bridge that is described here - https://github.com/jitsi/jitsi-videobridge/blob/master/doc/allocation.md. useNewBandwidthAllocationStrategy=true in config.js will invoke the translation in the client.
Fire PERMISSION_PROMPT_IS_SHOWN when none of the devices have a label
Fire a new SLOW_GET_USER_MEDIA event if the timeout for getUserMedia is exceeded
Update JitsiMeetJS.createLocalTracks to include the options for firing the above events
in the provided options argument. Deprecate the firePermissionPromptIsShownEvent flag in
method's signature
ref(QualityController): Split send and receive video constraints handling.
All the send video constraints for the client, i.e., what simulcast streams will be enabled based on constraints received on the bridge channel, will be handled by the SendVideoController class.
The receive video constraints like lastN, selectEndpoints and receive video resolution will be handled by the ReceiveVideoController class.
Not upadting the permissions from the Permissions API call on init is
causing the permissions cache to be filled from GUM resolve/reject logic
only when there aren't any permissions updates. This may
lead to unknown permission status when we can report the correct
status from the initial permission API request.