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'.

...in setMediaTransferActive. The sender video constraints
are controlling the 'encoding.active' flag and this code
would interfere. It's right now not used anyway as P2P is
disabled in the unified mode. If this modification is
necessary we'll add it back when working on unified P2P
in such a way that will play nicely with the sender constraints code.

...and remove duplication.

...when starting without video.

The app would crash in setSenderVideoConstraint,
because the RTP encoding are not available on Safari
until sLD/sRD cycle is performed.

Handle the promise returned by RTCRtpSender.setParameters.

(cherry picked from commit a14b3c80ae)

When the client starts video muted and the track is later added, make sure we construct the simulcasr stream constraints then.

When the video sender constraint changes in the p2p case when the remote user switches between stage/tile view,
get a downsampled video of the original 720p stream instead of requesting the camera for a new stream with the lower resolution.
Fixes https://github.com/jitsi/jitsi-meet/issues/7267

* feat: Apply max bitrates on video sender
Add the ability to control the max bitrates on the video sender through a config.js videoQuality setting.

* ref: Use '_' prefix only for internal methods

The audio levels reported on the audio receivers are lower when compared to the value reported by getStats.
Values reported by getStats on chrome do not follow the the spec and since we have combination of clients using both getStats and getSynchronizationSources,
lets stick to one scale to make them look uniform.
Also, the receivers seem to be reporting audio level for a little bit after the remote user has muted. Make sure the track is unmuted
before setting the audio level on the track.

Remove redundant _channelOpen flag from RTC and rely on the channel's isOpen() getter instead.
This fixes an error throw when the _channelOpen flag was not updated while the channel's been
closed by the bridge.

Delays e2e encryption initialization until any encryption key is set.
Recreates peerconnections in order to enable insertable streams
only if the e2ee is used. This is to avoid bug around insertable streams
which may cause audio issue when the main JavaScript thread is loaded:

https://bugs.chromium.org/p/chromium/issues/detail?id=1103280

Moves the logics which deal with JitsiConference events to a separate module.

* feat: use getSynchronizationSources on the receiver for remote audio levels
Use getSynchronizationSources if it is supported, fallback to using getStats otherwise.
* feat/ref: Use the local audio levels from LocalStatsCollector
When using getSynchronizationSources, use the audio levels from LocalStatsCollector for NoAudioSignalDetection.js
Remove obsolete code - TalkMutedDetection feature using audio levels is not used anymore

* fix: Takes disabled encodings into account when calculating local resolution.
* feat: Adds a new event that's triggered when the max enabled resolution changes.
* feat: Broadcasts the max enabled resolution value along with other stats.

It's not yet supported, so assume success.

* fix(safari): override min/max video constraints on safari
Override the constraints on Safari because of the following webkit bug.
https://bugs.webkit.org/show_bug.cgi?id=210932
Camera doesn't start on older macOS versions if min/max constraints are specified.

This is useful for testing insertable streams related issues.

* feat: Set degradation preference on video senders
Use 'maintain-framerate' for camera tracks and 'maintain-resolution' for desktop tracks

* ref: apply cached video contraints and degradation preference on unmute
Since the sender encodings are available only after the renegotiation is complete (on chrome/safari), constraints/preferences have to be applied after renegotiation is complete.

- Use getDisplayMedia on browsers where it is supported.
- desktopSharingChromeDisabled and desktopSharingFirefoxDisabled will no longer be supported.

Refactors the way send/receive video constraints are managed and puts the high level
logic in a separate module. See QualityController.js for high level overview on how
the constraints are managed now.

Adds events to JitsiConference fired whenever it starts new jvb/p2p session.

Adds event to JingleSessionPC.js when remote party signals receive max frame height.
Also adds signaling of the local recv preference for the p2p mode(only existed for JVB).

We switched to using replaceTrack for Firefox and Safari in the unified-plan rewrite

When screensharing is stopped on FF from the sharing indicator (available in FF nightly), we are currently not detecting it.
Firefox fires a track 'ended' event as opposed to Chrome which fires a mediastream 'inactive' event as well.

Remove unused code, we always use replaceTrack in unified plan

This behavior got altered when we correctly update the reference we keep of MediaStreamTrack in JitsiLocalTrack when effects are applied

Add RFC 4588 to the list of advertised features on Firefox.
Use RtxModifier only for cases when simulcast is achieved through SDP munging
This will ensure that RTX is negotiated whenever it is offered by the browser.

In preparation for turning on RTX on Firefox: add only the primary ssrcs to the SIM group if FID groups are present

This will make sure we get 30 fps for screenshare on p2p connections

Make sure we inject the encoding function on RTCRtpsenders when tracks are replaced on the peerconnection.
Update the MediaStreamTrack on the JitsiLocalTrack when effects are applied or removed so that
we can find the RTCRtpSender using the MediaStreamTrack