RTX in combination with simulcast on Firefox results in bad video quality
therefore we only enable it for version >= 96.

We do not want Firefox sending video when its video muted. https://bugzilla.mozilla.org/show_bug.cgi?id=1735951

* feat(CodecSelection) Disable VP9 on Safari.
Safari does not decode VP9 properly- https://bugs.webkit.org/show_bug.cgi?id=231071 and https://bugs.webkit.org/show_bug.cgi?id=231074.

* squash move VP9 support check to browser capabilities.

There was an error in the pattern match, everything was included in it. In
addition return a boolean in case we succeed in the UA pattern match, since it's
more correct than returning an array with the match.

On mobile Safari, if a user joins audio and video muted, the browser doesn't decode the incoming audio. Workaround is to always add the audio track to pc and mute it if needed.

An alternative to Insertable Streams, currently implemented in Safarii / WebKit.

https://w3c.github.io/webrtc-encoded-transform/

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

remove legacy APIs which are not even supported anymore

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.

This causes the audio to not work.

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.

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

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.

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.

All browsers on iOS use WebKit engine so they use the Unified Plan.

It has been `true` for a very long time.

Cleanup some unused code after the bump.

Since we use transferable streams to transfer the streams to the worker
we need to feature detect them as Chrome 86 will launch Insertable Streams
by default without shipping transferable streams yet (status still unclear,
it might still ship too)

See here for the feature detection used:
  https://groups.google.com/a/chromium.org/g/blink-dev/c/1LStSgBt6AM/m/hj0odB8pCAAJ

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

Add a performance stat around long tasks. Chrome supports PerformanceObserver API that lets us
register for long tasks event. Any task that takes longer than 50ms is considered a long task.

* 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

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

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.

which landed in
  https://bugs.chromium.org/p/chromium/issues/detail?id=1069295#c4

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.

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

Use unique session id per TPC.
Translate a=rid to Jingle only when simulcast through RIDs, i.e., ssrc-less simulcast is supported

* Add Edge beta (Chredge) to the list of chromium based browsers.

React Native also supports it now.

* Removes Edge support.

* Removes unused dependency.

jitsi-meet-spot currently supports mobile browsers. A
line should be drawn somewhere but maybe not here.
Chrome iOS does not have navigator.mediaDevices so add
a truthy check before checking for getDisplayMedia.

Chrome 71 does not support inline installs, but has navigator.getDisplayMedia
behind a flag. Support this case.

It's supported in Chrome >= 65.