RTCUtils.enumerateDevices was being called earlier than the RTCUtils.init which assigned that function

By looking at the replaceTrack usages it's possible for it to be called with both new and old tracks null/undefined.

When a second remote track of the same mediatype is received for an endpoint, remove the existing track before creating the new remote track.

* 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

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

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.

"Pinned" endpoints are deprecated, use "selected" instead.

Make sure screenshare w/ presenter gets the full 2500 Kbps bitrate.

The max bitrate for VP9 is enforced by adding the b=AS:<limit> line in the SDP since there is no way to configure the max. bitrates for the individual SVC streams using RTCRtpSender.setParameters.

Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1466

Determine the preferred codec for a given endpoint based on the config.js settings and the codecs supported by the endpoint.
The preferred codec is published in presence and then used by the other endpoints in the call during join/leave to determine
if the codec needs to be changed on the fly. Different codecs can be configuered for p2p/jvb connections.
The preferredCodec/disabledCodec settings under videoQuality will have precedence over the older settins like preferH264/disableH264.

in order to not match a=msid-somethingelse, a=ridiculous and similar

Explicitly check if all the encodings report the same scaleResolutionDownBy value before trying to ensure they match the expected values. This makes Chrome VP9 work again.

Fixes https://github.com/jitsi/jitsi-meet/issues/8094.

It has been `true` for a very long time.

Cleanup some unused code after the bump.

On every call to RTCRtpSender.setParameters(), ensure that the resolution configured for the encoding matches that of the value configured on the RTCRtpSender when the source was added to the peerconnection. This should prevent us from overriding the default values if the browser returns erroneous values when RTCRtpSender.getParameters is used for getting the encodings info. This fixes the issue on recent versions of Safari where the 'scaleResolutionDownBy' value comes back as 1 for all encodings even though the encoding resolution is different from the stream capture resolution.

In p2p mode, 'scaleResolutionDownBy' is used for downscaling a stream when needed, i.e. when the user receives a receive constraint of 360p because the other participant is in tile view. When desktop share is started, the encoding config has to be scaled back up so that the other participant starts receiving HD resolution for the share as desktop shares are autopinned. Therefore, encodings have to enabled/disabled for desktop shares as well. Earlier it was done only for camera tracks.

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

The old stream needs to be released while keeping the tracks intact

Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1333 in applications that use lib-jitsi-meet and do not have layer suspension enabled.

Add the conference flag back since the bridge is able to handle the case where more than 1 temporal layers are received even when only 1 ssrc is signaled.

* ref: Do not include the full JSON when firing event (unused).

* ref: Logging and formatting fixes.

seen in #1364 but it is older

In Chrome, if 'maxBitratesVideo' options are specified
and 'capScreenshareBitrate' is disabled, then simulcast is enabled
for screenshare. Chrome in plan B, does not send screen stream if
'maxBitrate' are set and simulcast is enabled.

Device IDs can change without triggering any event. In order to sync the
device IDs that  we store with the actual device IDs, we need to update
them every time when we call enumerate devices.

When using getSynchornizationSources on the audio receiver to gather audio levels for remote tracks, browser reports last known audio levels even when the remote user is audio muted, we need to reset the value to zero here so that the audio levels are cleared.

On Safari, MediaStream.onremovetrack is not fired when a remote desciption with a removed MSID is applied. As a result, new remote tracks for the same endpoint are not created causing issues where the video is not updated on Safari. Also, make sure local tracks on pc are updated when devices are changed while the user is in muted state.

Both of the cases where user clicks cancel and when screen recording
permissions were not granted at the OS level are almost the same,
except for a small difference in the error.message.

This was only tested on Chrome 85.0.4183.121/Mac OS 10.15.6

* add p2p meta info to pc

* fix typos

This should fix the case when camera is started with 1080p and LD simulcast stream's resolution is 270p but the requested resolution is 180p.