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.

Add a preifx to logs for idenitifying the type of TPC/jingleSessionPC.

This can be controlled through the config.js  option 'enableUnifiedOnChrome'.

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.

Get the correct media type when generating the source identifier.

When a msid attribute is missing in the 'a=ssrc' line, use the local endpoint id as an indentifier. Move this generation logic to LocalSdpMunger. Also suppress notifying Jicfo of a ssrc change on Firefox when the change is a result of the media being suspended on the jvb connection.

Get rid of noisy logs related to SDP transformations which are redundant. Fix formatting and add missing information.

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.

SDP utility classes are spread across RTC and XMPP directories now, moving these class files to a 'sdp' directory.

Switch to returning a Promise for getStats. Reset frame rate stat to 0 when video is suspended as a result of endpoint falling out of last-n.

Get rid of the browser specific keys and use the standard spec-compliant fields for stats.
Get the resolution/fps for remote streams from 'inbound-rtp' stats. Use the 'track' stats for the local resolution/fps since these take the active simulcast streams into account.

Calculate the target bps based on the video quality settings and the codec configured on the peerconnection.
Hardcode target video bitrates for RN since it doesn't support setting max bitrates.

Make sure the codec order is munged on all the m-lines for unified plan clients. Implement the logic for setting the preferences through RTCRtpTransceiver#setCodecPreferences.

Capture the audio levels only for the top 5 speakers as RTCRtpReceiver#getSynchronizationSources can be expensive when we have too many audio receivers in the call.
Also, capture the audio levels for track that are unmuted if RTCRtpReceiver#getSynchronizationSources is not supported.
Switch Safari to using getStats since its reporting errorneous values, i.e., 0.000001 as audio level for all remote audio tracks.

* fix(TPC): Configure degradation preference in RTCRtpSendParameters.
Properly configure degradation preference on RTCRtpSendParameters instead of RTCRtpEncodingParameters. Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1510.

* feat(JingleSessionPC): Remove ssrcs from remote desc when a user leaves.
Remove the ssrcs (associated with remote sources) from the remote desc along with the removal of the remote tracks when an endpoint leaves the call. The source-remove signaling message from Jicofo will no longer be needed in this case and can be dropped.

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.

When a second remote track of the same mediatype is received for an endpoint, remove the existing track before creating the new remote track.

All the send video constraints for the client, i.e., what simulcast streams will be enabled based on constraints received on the bridge channel, will be handled by the SendVideoController class.
The receive video constraints like lastN, selectEndpoints and receive video resolution will be handled by the ReceiveVideoController class.

Make sure screenshare w/ presenter gets the full 2500 Kbps bitrate.

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.

Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1466

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

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.

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.

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.