This was needed in older versions since the browser didn't apply maxBitrates from RTCRtpEncoderParameters on the encoder. In the newer versions this seems to be no longer the case. Also, when the codec selection API is used, we no longer renegotiate locally so if we switched codec from AV1->VP9-VP9, the AV1 bitrate setting in the SDP will still be effective resulting in a lower send resolution because of b/w limitation.

Checking for send resolution vs expected resolution was unnecessarily limiting lastN and receive resolution when local camera has issues and stops sending video. Also, do not send redundant receiver constraints on the bridge channel

* ref(QualityController) Add recovery mechanism and adjust the resolution check.
Impl a recovery mechanism for the lastN to be increased if the cpu limitation goes away and doesn't return after increasing lastN. Also, additionally improve the calculation of the expected resolution taking simulcast stream resolutions into account.

* squash: Address review comments and add more unit tests

* squash: Address review comments

* feat(quality) Add a QualityController class for runtime adjustments.
Make run time adjustments to the client when adaptive mode is enabled.

* feat: Update lastN and receive resolution to improve quality.

* squash: Address review comments

* squash: Add more logging and address review comments.

This prevents the browser from starting the camera at 60 fps wherever supported as this could drastically affect the cpu and result in poor experience.

* feat(codec-selection): Use the new codec selection API
https://github.com/w3ctag/design-reviews/issues/836. This allows the client to seamlessly switch between the codecs without having to trigger a renegotiation.
This feature is behind the flag testing.enableCodecSelectionAPI in config.js

* fix(stats): Fix local resolution stats.
The video codec for the local video sources needs to identified differently now, from the codecs field in the RTCRtpSendParameters returned by the browser. We no longer munge the remote SDP to switch to a different codec.

* feat(stats): Feed encodeTime stats for all local SSRCs to the codec selection mechanism.

* fix(codec-selection) Continue to mumge SDP for selecting H.264.

* feat(codec-selection) Make screenshare codec configurable.
If no 'screenshareCodec' is set under videoQuality or p2p settings, AV1 will be selected as default.

* squash: Address review comments

* Update modules/RTC/CodecSelection.js

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

* fix(codec-selection) Add codec to existing stats

---------

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

Fixes poor low resolution video from Spot running older electron versions when the codec changes from VP9->VP8->VP9.

This helps us in identifying the video codec associated with a local video track for codec selection torture tests.

We are already handling Safari, which provides an empty constraints
object. Handle any type of broken constraints object which doesn't have
at least a `width` and `height` properties. This is the case of Firefox
when "fingerprint resistence" is enabled.

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

Claiming there is no support for it is misleading, the user might have
called the function before the channel was initialized.

It will now happen for both local and remote tracks.

The browser is downsampling the resolution since the current default bitrates for H.264 are very conservative.

Fixes an issues where microphone change for Safari fails.

When an existing SSRC for a remote track gets re-mapped from one source to another, fire a TRACK_REMOVED event followed by TRACK_ADDED event instead of TRACK_OWNER_CHANGED event. This should simplify the application logic for track handling.

webrtc-adapter transforms "deviceId": "foo" to "deviceId": { ideal:
"foo"}.

This makes the camera non-selectable if the resolution constraints are
not met.

Setting the constraint to exact will sidestep that adapter behavior, and
express stronger intent.

This is needed when p2p conn establishes before jvb and no sender constraints have been received before media on jvb conn is suspended.

Also fixes the issue with video freezing after video mute and unmute when the user joins the call with startSilent=true.

Check if all the relevant fields are correctly configured instead of checking for just the encode resolution on the local video sender.

Include visitor codecs published by Jicofo while calculating the intersection set for the conference.

Chrome on macOS recently started offering encoder for higher level (5.2) but decoder only for level 3.1. See https://issues.chromium.org/issues/324930413
Therefore, filter out all H.264 payload types with main and high profiles. Also, sort all H.264 payload types so that same pt is picked for both H.264 encoder and decoder. Fixes random black tile issues across different browsers when H.264 is the preferred codec for p2p.

Firefox 123 started throwing an error when the transction ids for getParamters and setParameters don't match. This can result in Firefox not establishing a p2p connection with a remote peer when it is the offerer.

We do not want non Chromium browsers to negotiate DD ext headers when VP8/VP9 is the selected codec. Fixes poor video quality issue for Safari when Av1 is offered by Jicofo.

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

Require cycle: lib/lib-jitsi-meet/modules/RTC/RTC.js -> lib/lib-jitsi-meet/modules/RTC/TraceablePeerConnection.js -> lib/lib-jitsi-meet/modules/RTC/RTC.js

Set the scalabilityMode to undefined for VP8 after a VP9->VP8 switch even though the browser returns L1T2 in the RTCRtpSender.getParameters() call. Fixes an issue where the bridge stops forwarding video for some participants after vp8->vp9 switch.

The browser returns height as 0 at track creation time. Fixes an issue where Safari's screenshare shows as black.

When both the camera and screenshare tracks are present. Add unit tests.

Check the first payload type of the m-line in remote description to get the codec used for encoding the local video source.

Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1877675.

If MediaStreamTrack.getSettings() doesn't return the height of the track, use the constraints passed to gUM for calculating the height. Fixes an issue for Firefox/Linux which could result in media not displayed.

Set the min. required version for Firefox to 91 so that the last 3 ESR versions are supported.

When a local video track is muted, getSettings() on MediaStreamTrack doesn't return capture height. Fixes random torture test failures on beta.

* fix(video-quality): Adjust encodings bitrates/scalefactor for high capture resolutions.
When the client is configured to capture camera sources at 1080p or higher, adjust the bitrates and the encodings scale factor accordingly.

* squash: Address review comments
Fix the bitrates set on the remote description and also bump up the bitrates for 1080p, 4k and screenshare.

* squash: Address some more review comments.

This check is not needed anymore since we now set the correct scaleResolutionDownBy value everytime the encodings are configured. Fixes a regression on Safari where it can end up sending low resolution to a p2p peer in some cases. Also, add more unit tests for p2p desktop share cases.

* fix(RTC): Remove support for plan-b SDP.
Since unified plan mode becomes the default mode, so does multi-stream mode.

* squash: Remove plan-b unit tests and fix comments

* squash: address review comments