In the older versions, the SSRCs in the SDP were in reversed order, i.e., the resolution order was 1:2:4 as opposed to Chromium and other browsers. Therefore, the client was confuguring the reverse order. However, the commit https://hg.mozilla.org/mozilla-central/rev/b0348f1f8d7197fb87158ba74542d28d46133997 which was seems to have landed in Firefox 117 has reverted the reversing of the RID order. Therefore, this hack is no longer needed on the newer Firefox versions.
This fixes an issue where the bridge suspends all video from Firefox to other endpoints in the call because of the reversed order of the encodings.

Recommit 17ade96a70 with the jvb leak fix.

This is much faster than changing direction on the transceiver and doesn't need a renegotiation for the suspending/resuming media. Also fixes an issue with audio-only mode in p2p where media doesn't resume when audio-only mode is disabled if it was enabled while the jvb connection was active.

This reverts commit 17ade96a70.

It causes setParameters failures which can cause media being leaved to
JVB when in a P2P connection.

Fixes blurry screenshare in some cases. There is a higher probability of the higher layers getting suspended when all the stream encodings are enabled for low fps SS. Make sure only the highest spatial layer is sent for low fps SS after p2p->jvb switch. Make sure all the stream encodings are enabled for high fps SS after p2p->jvb switch.

* fix(TPC) Avoid applying constraints on desktop tracks if not needed.
Ignore sender constraints if the client is already sending video of the requested resolution. For desktop tracks, max resolution will be the height of the window being captured irrespective of the height being requested by the peer. Therfore, check if the configured resolution is equal to the track height for all requested heights > 0.
Fixes an issue where the track addition fails because of setParameters failing on the video track. This is only seen the torture tests because this is very timing specific.

* squash: check correct scaleResolutionDownBy value for p2p conn.

* fix(TPC) Disable media instead of changing dir for p2p->jvb switch.
Resume or suspend the media on the jvb peerconnection by changing the RTCRtpEncodingParamters.active state instead of changing the direction on the transceiver. This avoids the needs to start a O/A renegotiation cycle for these operations. The media direction will be changed only for p2p lastn=0 case since video needs to be disabled on both the sender and the peer for p2p lastn=0 case.

* Address review comments

* Disable media after adding source while media is suspended on the jvb connection. Default 'active' state for stream encodings after the source is added is 'true'.

* Wait for all the promises to be settled before returning

* fix(TPC): make screen share bitrate configurable

* fix(TPC): make local stream encodings configurable

* fix(TPC): fix lint error

* fix(TPC): alpha sort methods and update check for VP8

* Remove support for legacy endpoint based signaling and make source-name signaling as the only signaling mode. The legacy screensharing mode will no longer be supported. The client will still be able to process remote presence sent in the old format to support interop with very old mobile clients and jigasi that do not support source-name signaling.
* remove code related to presenter mode.

Adds a helper function getSourceIndexFromSourceName to
have track index parsing in one place.

In _processLocalSSRCsMap there was an assumption that a track
index can be a single digit only.

Use "last index of" or search from the end of the collection to
make parsing a bit more universal (does not matter as much for
Jitsi endpoint IDs, but if fixes issues if someone has
a customization there).

Firefox lists stopped transceivers when getTranceivers is called, ignore these when picking a trancceiver for a screenshare track. Fixes an issue when starting screenshare fails if there are stopped tranceivers in the peerconnection (i.e., if some remote users with sources have left the call).

Fixes cases where SS fails in multi-stream mode with p2p->jvb->p2p switching.

Fixes cases where SS stream is not being sent when p2p->jvb switch happens.

Set the bitrates on the video m-lines based on the associated track type. In multi-stream mode, there will be two separate m-lines for camera and desktop tracks. Also fallback to SDP munging for setting codec preferences on Chromium.

* fix(multi-stream) add new m-line when remote adds a second video source in p2p.
A new m-line needs to be added in the remote description when a new secondary video source is signaled by the peer.

* fix(TPC) Suppress lower layers only for screenshare tracks.
With multi-stream support enabled, an extra check for videoType for local track is needed to dtermine if the lower layers need to be suppressed.

* fix(TPC) Mark the direction inactive on inactive media connection.
If a new secondary video source is added on the jvb connection while p2p is active, make sure the direction is set to inactive on the jvb connection, so that no media is being sent out on the jvb connection.

* squash: Address review comments.

* fix(multi-stream-support) Support muting of desktop track.

* fix(multi-stream) Always initiate responder renegotiation even for p2p.
This is needed since the new m-line is always added to the remote description.

* fix(multi-stream) Support multi-stream only on Unfied plan endpoints.

* fix(multi-stream) Advertise source-name signaling to Jicofo when supported.

* fix(JitsiLocalTrack): Remove unnecessary reject.

* fix: add the correct source name attribute for the second video track.

* squash: Address review comments.

This fixes an issue where replaceTrack fails when a muted track is being replaced with another track in Unified plan.

* feat(multi-stream-support) Add the support for multiple local video streams.
This feature is behind 'sendMultipleVideoStreams' config.js flag and is currently supported only on clients running in Unified plan mode.

* squash: Use the track index from source name to find the matching transceiver on unmute.

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

* ref(TPC) Configure encodings in one go.
Configure the active state, maxBitrate and degradation preference in one go instead of configuring them separately.

* squash: Address review comments.

* squash: fix a comment.

* fix: Missed SSRCs in Unified Plan with several "ssrc-group:FID" groups.

`TpcUtils.ensureCorrectOrderOfSsrcs()` takes into account only the first `ssrs-group`, and it causes missed `ssrs` attributes. It results in an error during `peerconnection.setRemoteDescription()`.

For fixing `ensureCorrectOrderOfSsrcs()`, all `ssrs-group` are traversed and all distinct `ssrs` are preserved with keeping their order.

* test: Added extra tests for `TpcUtils.ensureCorrectOrderOfSsrcs()`

Avoid configuring the encodings on Chromium/Safari until simulcast is configured for the newly added track using SDP munging which happens during the renegotiation.

Avoid configuring the encodings on chromium immediately after replace track since the encoding params are read-only until the renegotation is done.

This fixes the issue where TRACK_REMOVED event is not fired when a remote track is removed from the peerconnection.
Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1612 and https://github.com/jitsi/jitsi-meet/issues/8482.

Do not try to configure encodings on the sender until they are available. This fixes an issue on Chrome (running in unified-plan mode) where unmuting the local source throws a 'Read-only field modified in setParameters()' error.

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.

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

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.

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.

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.

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.

 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.