Chrome doesn't render media when the SSRC is added back to the m-line after removing it because of source-remove->source-add from peer. Avoid renegotiations so that these source removes and adds are not sent to the peer after the track is replaced.

The encodings for local video tracks are confiugured based on the SenderVideoConstraintsV2 constraints received from the bridge. The constraints are sourceName based. Also ignore enableLayerSuspension flag since it has been deprecated and layer suspension has been enabled by default. Also having it off makes screensharing on Chrome in unified plan not work as expected.

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

* feat(multi-stream-support) Handle SDP munging for multiple local/remote streams/ep.
A new SDPSimulcast class is added for handling SDP munging for local and remote descriptions to handle multiple streams for both local and remote endpoints. This new class will be used only for unified plan implentation. The sdp-simucast npm package will be used for plan-b and deprecated later when all the clients switch to unified plan.

* fix(build) fix building with TS code

Use the Babel preset for the webpack bundle since Babel 7 already
understands TS and ts-loader uses tsc instead, which we configure
differently.

* squash: Add unit test and address review comments.

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

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

This fixes a regression introduced by the previous commit.

sLD is called immediately after createOffer/createAnswer, therefore the desc provided by createOffer/createAnswer can be directly passed to sLD without the need for converting it to unified plan format. This also fixes a warning seen on the browser console that says 'The description does not look like plan-b'.

The issue currently affects browsers based on Chromium 96.0.4664.110
including Brave, Chrome, Edge & Opera and Google Chrome 97.0.4692.56

* fix(tpc) disable ulpfec on chrome 96

* ref(tpc) add comment

This fixes an issue where a user is not able to unmute their video if the MediaStreamTrack associated with the camera stream returns a null value for the track height.

* Save track source name to JitsiRemoteTrack

* add feature flag checks. code review adjustments.

* eslint cleanup1

* eslint cleanup2

* fix: move sourceName declaration outside of if block.

Co-authored-by: Dennis Dowhy <ddowhy@gmail.com>
Co-authored-by: William Liang <wliang67@bloomberg.net>

This ensures that the source signaling is sent before the mute state is sent in presence. Jicofo relies on mute state from presence to check if the sender limit has been reached.

This fixes occasional failures of MuteTest.MuteAfterJoinCanShareAndUnmute torture test and also the case on Safari where user stopping the screenshare doesn't stop showing the screensharing indication on the thumbnail.

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

Instead rely on the 'negotiationneeded' event fired by the browser for JVB connection. This makes local source changes faster even if the modification queue is backed up.

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

It makes more sense to call it pcConfig since it is the RTCConfiguration object passed to the WebRTC peerconnection.

This fixes an issue where the bridge doesn't forward the HD stream from Firefox to other users in the call. The order of the ssrcs produced by the browser is from Highest resolution to lowest whereas the bridge assumes it to be from lowest to highest as is the case in Chrome and Safari.

If Jicofo doesn't offer VP9 but the client expresses a preference for VP9, VP9 bitrates were being imposed before.

* fix: re-enable that ICE connection failures in Chrome are detected
* fixed linting errors

In unified plan we'll take the ssrcs off the first audio / video stream, but we
were assuming both would be present.

This commit fixes that, since the Spot wireless screen sharing feature uses a
dedicated TPC just with a video stream.

Munge 3 ssrcs in the SDP for chrome in unified plan always for the simulcast case.

Do not enable unified plan for p2p chrome by default until StartMutedTest is fixed.
Fix media direction for case when there are no local and remote sources, should be set to 'inactive' in that case.

Munge only the m-line that corresponds to the source that the browser will be sending.
Do not select VP9 on Firefox.
Detect support for RTCRtpTransceiver#setCodecPreferences correctly.

In unified plan impl, it is not possible to enable/disable simulcast during the call since the same sender is re-used for all local video tracks. Therefore, disable the low resolution simulcast streams for low fps screensharing so that the bridge forwards only the highest resolution stream which is important for low fps screensharing.

In unified plan, re-use of m-line (i.e., adding an SSRC, removing it and then adding it back) causes the browser to not render the media on Chrome and Safari. The WebRTC spec is not clear as to how browsers have to behave, this doesn't cause any issues on Firefox. As a workaround, only change the media direction and leave the ssrc in the remote desc. This automatically triggers a 'removetrack' event on the associated MediaStream and the track can be removed from the UI.

Provide a method for changing the capture fps for desktop tracks during the call. These changes to the lib are needed for making it configurable from the UI.

Use 'msid' for plan-b clients and 'cname' for unified-plan clients.

Browsers do not generate a 'msid' attribute for ssrcs in unified plan mode, use mediaType as a key for the TrackSSRCInfo map.

For p2p connections, the media direction needs to be adjusted after every source-add/source-remove is processed based on the availability of local sources.

Call RTCRtpTransceiver#setCodecPreferences with the preferrred codec order before every createOffer/createAnswer. This ensures that the codec preference is enforced even when there is no local description available yet while the preferred codec is being set immediately after media session creation.