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

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

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.

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

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

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

MediaStreamTrack.getSettings is not implemented.

* feat(video-quality): control the sender resolution based on video quality settings

* fix(video-quality): Apply the settings on newly created p2p/jvb jingle sessions
If a p2p/jvb session is not present when setSenderVideoConstraint is called,
make sure the settings are applied when they are created

Make sure we don't have a=simulcast lines on the sendonly m-lines in the remote description

Get rid of the experimental flag for simulcast support, update js-utils for detecting Edge on Android

Trigger renegotiation only for plan-b when tracks are muted or unmuted

Enabled desktop sharing and discontinue support for Safari versions prior to 12.1, i.e., the ones with no VP8 support

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

Switch to using ontrack for remote tracks, re-use mids/transceivers when remote sources are removed and added.

Trigger renegotation only when negotiationneeded event is fired on the browser.
Do not disable simulcast for screensharing in unified plan.
Fix the order of the simulcast streams for Firefox

Calls to insertDTMF will stop any tone
playing in progress. Prevent such by
checking the tonebuffer for any tones
in play and queue tone playing if
any tones are in play.

Enable/disable this feature using 'capScreenshareBitrate' testing flag in config.js and send analytics
events to Amplitude to indicate which type of screensharing is enabled.

Moves sendTones implementation to TraceablePeerConnection. It will be
responsible for creating/storing a DTMFSender. JitsiConference will
use the currently active TraceablePeerConnection to send the tones.

This fixes a bug where DTMF tones can not be sent after
JingleSessionPC/TraceablePeerConnection instance changes.
The JitsiDTMFManager instance was referencing invalid PeerConnection.