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.

This error happens in getCurrentlyAvailableMediaDevices

We're pretty sure it's no longer necessary with JVB2; and it costs
half an RTT in setup, and stops us being able to choose which
DTLS/SRTP protection profile to use.

The constraints are applied again after renegotiation is done. This should mitigate a fail case on Safari when the RTCRtpSendParameters are not available until the simulcast streams are added via SDP munging before sLD is called.

 Only add/remove the tracks from the peerconnection so that the camera led turns off on mute.

Configure the encodings on FF after the track is added.

Calculate the bitrate based on the sender video constraint applied on the track and the bitrates specified for different resolutions.

Make 'preferH264' and 'disableH264' as deprecated.

Use 'preferredCodec' and 'disabledCodec' under videoQuality config.js settings for setting codec preferences.
Do not prefer VP9 on Firefox because of https://bugzilla.mozilla.org/show_bug.cgi?id=1633876.

Make sdp munging logic for changing codec preferences more generic
Do not negotiate High profile H264 codecs on when RN clients are in the call

When adjusting transceiver direction only the first one
which corresponds to the local track can be set to 'sendrecv'.