Use a fixed set of remote tracks for a call based on the ssrc-limit set in jvb config. When this feature is enabled, JVB will signal the audio and video SSRCs and their owner/endpoint info using a bridge channel message. For audio, the mappings are determined based on the energy rankings on the audio sources present in the call and for video, the mappings are calculated based on the video sources the client requests through the video receiver constraints.
Remote tracks are then created/remapped by the client based on these mappings.
* Added track_owner_changed action
* Skip track-based large-video selection in rewriting mode.
* Register OWNER_CHANGED handler at track level.
* feat(participants) Add source info to participants in redux.
With ssrc-rewriting, the receiver constraints need to be generated using the source info received in presence. Currently they are generated from the track info in redux but with ssrc-rewriting, remote sources are not signaled and therefore created until they are being requested through receiver constraints.
Co-authored-by: James A <jqdrqgnq@users.noreply.github.com>
* fix(connection-status): remove unused participant connectionStatus.
Always use trackStreamingStatus now that legacy endpoint based signaling has been removed.
* remove the check for source-name signaling.
Default to source-name signaling always.
* Remove the check for multi-stream mode.
Make that the default mode and remove the support for legacy SS mode.
* Remove presenter mode.
* update latest@lib-jitsi-meet
Fixes an issue where 'contentSharingParticipantsChanged' event and 'getContentSharingParticipants' API continue to list IDs of the participants that have already stopped their screenshares.
* fix(multi-stream) update selector to find ss track by videoType or mediaType
* ref(multi-stream) move fake ss creation logic and support video type changed
* refactor(multi-stream) decouple sending and receiving multiple screenshare streams
* fix(multi-stream) fix receiver constraints with signaling and without multi-stream
* fix(mutli-stream) ensure plan b original SS thumbnail displays avatar
* fix(multi-stream) show fake SS for plan b sender
* refactor(multi-stream) poc for moving SS creation to state listener
* remove reference to fake SS creation
* fix lint errors
* rename to virtual screenshare participants
* fix minor bugs
* rename participant subscriber to specify web support only
In case of conference failed as max number of occupants reached, we should skip clearing the local tracks to keep state of pre-join screen. Otherwise, on join we will join muted even though on prejoin screen it was unmuted on the initial attempt.
prioritize participants with screen shares
support local screen share track
auto pin screen share
support screen share for large video
ensure fake screen share participants are sorted
fix local screen share in vertical filmstrip
fix local screen share in tile mode
use FakeScreenShareParticipant component for screen share thumbnails
ensure changes are behind feature flag and update jsdocs
fix bug where local screen share was not rendering
update receiver constraints to include SS source names
remove fake ss participant creation on track update
fix: handle screenshare muted change and track removal
refactor: update key values for sortedFakeScreenShareParticipants
address PR comments
refactor getter for screenshare tracks
rename state to sortedRemoteFakeScreenShareParticipants
* feat(multi-stream-support) Add screenshare as a second video track to the call.
This feature is behind a sendMultipleVideoStreams config.js flag. sourceNameSignaling flag also needs to enabled. Sending multiple tracks is currently supported only on endpoints running in unified plan mode. However, clients with source-name signaling enabled and running in plan-b can still receive multiple streams .
* squash: check if there is an existing track before adding camera/desktop
* squash: enable multi-stream only on unified plan endpoints.