* feat: Initial UI part for A/V moderation.
Based on https://github.com/jitsi/jitsi-meet/pull/7779
Co-authored-by: Gabriel Imre <gabriel.lucaci@8x8.com>
* feat: Hides context menu in p2p or only moderators in the meeting.
* feat: Show notifications on enable/disable.
* feat(moderation): Add buttons to participant list & notifications
* fix(moderation): Fix raised hand participant leaving
* feat(moderation): Add support for video moderation
* feat(moderation): Add mute all video to context menu
* feat(moderation): Redo participants list 'More menu'
* fix: Fixes clearing av_moderation table.
* fix: Start moderation context menu
* fix(moderation): Show notification if unapproved participant tries to start CS
Co-authored-by: Gabriel Imre <gabriel.lucaci@8x8.com>
Co-authored-by: Vlad Piersec <vlad.piersec@8x8.com>
The majority of the code is in the WASM file and models, this is just a few KB.
It's so little, in fact, that the performance hint for the main bundle didn't
have to be adjusted.
* feat: Exposes a method for checking is remote track received and played.
Used for some tests in torture.
* squash: Drop not matching string.
Duplicate translation key with not matching content.
* squash: Moves torture specific functions to features/base/testing.
Listens for media events from the video tag of the large video and stores them in redux.
* squash: Fix comments.
* feat: Listens for media events from the video tag of the remote videos and stores them in redux.
* squash: Fix undefined videoTrack if between switches.
When on prejoin screen, if the device list changes (devices are added or removed),
the newly created tracks do not properly replace the old ones, resulting in
errors after joining the meeting and trying to change the devices.
This change fixes the problem.
Up until now we relied on implicit loading of middlewares and reducers, through
having imports in each feature's index.js.
This leads to many complex import cycles which result in (sometimes) hard to fix
bugs in addition to (often) breaking mobile because a web-only feature gets
imported on mobile too, thanks to the implicit loading.
This PR changes that to make the process explicit. Both middlewares and reducers
are imported in a single place, the app entrypoint. They have been divided into
3 categories: any, web and native, which represent each of the platforms
respectively.
Ideally no feature should have an index.js exporting actions, action types and
components, but that's a larger ordeal, so this is just the first step in
getting there. In order to both set example and avoid large cycles the app
feature has been refactored to not have an idex.js itself.
- Adds the ability to share video as a "PiP" when screenshare is in progress.
- Add a method for creating a local presenter track.
- Make sure isLocalVideoTrackMuted returns the correct mute state when only screenshare is present.
- Make sure we get the updated window size of the window being shared before painting it on the canvas.
- Make sure we check if the shared window has been resized
React Native doesn't define __filename nor __dirname so do it artisanally. In
addition, this helps with centralizing the configuration passed to loggers.
* ref(user-interaction): remove storing of listener
* ref(user-interaction): move browser requirement check to lib-jitsi-meet
* ref(user-interaction): no inner function for listener, use module scope
The state about currently opened devices is filtered and not stored, where we only store when user selects a device preferences.
Also allow changing input devices for Firefox when we are not in a conference.
Using anything non-serializable for action types is discouraged:
https://redux.js.org/faq/actions#actions
In fact, this is the Flow definition for dispatching actions:
declare export type DispatchAPI<A> = (action: A) => A;
declare export type Dispatch<A: { type: $Subtype<string> }> = DispatchAPI<A>;
Note how the `type` field is defined as a subtype of string, which Symbol isn’t.
This feature is intended for spot. Spot can have an
HDMI -> usb adapter hooked up to it. In that case,
attempting to screenshare should use that adapter
as a screensharing source. Jitsi-Meet should pass
a configured screenshare source into lib-jitsi-meet
so it can be used as a source.
Zoltan Bettenbuk suggested the following:
const state = getState();
if (desiredTypes.length === 0) {
- const { audio, video } = state['features/base/media'];
-
- audio.muted || desiredTypes.push(MEDIA_TYPE.AUDIO);
- video.muted || desiredTypes.push(MEDIA_TYPE.VIDEO);
+ const startAudioOnly = getPropertyValue(state, 'startAudioOnly');
+ const startWithAudioMuted
+ = getPropertyValue(state, 'startWithAudioMuted');
+ const startWithVideoMuted
+ = getPropertyValue(state, 'startWithVideoMuted');
+
+ if (!startWithAudioMuted) {
+ desiredTypes.push(MEDIA_TYPE.AUDIO);
+ }
+ if (!startAudioOnly && !startWithVideoMuted) {
+ desiredTypes.push(MEDIA_TYPE.VIDEO);
+ }
}
const availableTypes
The final commit is really a different implementation of the same idea
but takes into account that the state of base/media already contains the
intent of the URL and notices the delay in the realization of the
background app state.
Additionally, unbreaks one more case where setAudioOnly is incorrectly
dispatched on CONFERENCE_LEFT or CONFERENCE_FAILED and, consequently,
overrides the intent of the URL.
* ref: Restructures the pinned/unpinned events.
* ref: Refactors the "audio only disabled" event.
* ref: Refactors the "stream switch delay" event.
* ref: Refactors the "select participant failed" event.
* ref: Refactors the "initially muted" events.
* ref: Refactors the screen sharing started/stopped events.
* ref: Restructures the "device list changed" events.
* ref: Restructures the "shared video" events.
* ref: Restructures the "start muted" events.
* ref: Restructures the "start audio only" event.
* ref: Restructures the "sync track state" event.
* ref: Restructures the "callkit" events.
* ref: Restructures the "replace track".
* ref: Restructures keyboard shortcuts events.
* ref: Restructures most of the toolbar events.
* ref: Refactors the API events.
* ref: Restructures the video quality, profile button and invite dialog events.
* ref: Refactors the "device changed" events.
* ref: Refactors the page reload event.
* ref: Removes an unused function.
* ref: Removes a method which is needlessly exposed under a different name.
* ref: Refactors the events from the remote video menu.
* ref: Refactors the events from the profile pane.
* ref: Restructures the recording-related events.
Removes events fired when recording with something other than jibri
(which isn't currently supported anyway).
* ref: Cleans up AnalyticsEvents.js.
* ref: Removes an unused function and adds documentation.
* feat: Adds events for all API calls.
* fix: Addresses feedback.
* fix: Brings back mistakenly removed code.
* fix: Simplifies code and fixes a bug in toggleFilmstrip
when the 'visible' parameter is defined.
* feat: Removes the resolution change application log.
* ref: Uses consistent naming for events' attributes.
Uses "_" as a separator instead of camel case or ".".
* ref: Don't add the user agent and conference name
as permanent properties. The library does this on its own now.
* ref: Adapts the GA handler to changes in lib-jitsi-meet.
* ref: Removes unused fields from the analytics handler initializaiton.
* ref: Renames the google analytics file and add docs.
* fix: Fixes the push-to-talk events and logs.
* npm: Updates lib-jitsi-meet to 515374c8d383cb17df8ed76427e6f0fb5ea6ff1e.
* fix: Fixes a recently introduced bug in the google analytics handler.
* ref: Uses "value" instead of "delay" since this is friendlier to GA.
While reviewing "[PREVIEW|RN]: Handle getUserMedia in progress" I
discovered JSDoc comments which could be improved. They are not
necessarily 100% related to the PR.
This commit adds extra actions/Redux state to be able to deal with
the GUM operation being in progress. There will be early local track
stub in the Redux state for any a local track for which GUM has been
called, but not completed yet.
Local track is considered valid only after TRACK_ADDED event when it
will have JitsiLocalTrack instance set.
* ref(notifications): convert some dialogs to error or warning notifications
- Expand the configurability of the Notification component so warnings
and errors can be displayed.
- Allow Notification to take in arbitrary text for the body.
- Rename defaultTitleKey to titleKey for consistency with descriptionKey.
* ref(notifications): remove openReportDialog method
openReportDialog is a wrapper around showError that adds
a logger statement. It is being called in one place only
so remove the method and have that one place call logger.
* ref(notifications): UI.showTrackNotWorkingDialog takes a boolean
Change UI.showTrackNotWorkingDialog so it takes a boolean
arguments instead of the entire track. A small refactor so
the method needs to know less.
* [squash] Fixes eslint errors
* WiP: Fixes desktop sharing error strings and adds support button
* [squash] Fix icons appearances
* [squash] Fix translate titles and messages
* [squash] fix(translation): Fixes incorrect password string
* [squash] fix(recording): Fixes recording message
* [squash] fix(warning): Turns some warnings to errors and makes support link optional.
* [squash] fix(translation): Addressing language comments
* [squash] Fixes jsdoc and formatting
* [squash] fix(noopener): Fixes window.open noopener
* [squash] fix(constants): Extract constants and refactor NotificationWithToggle
* [squash] fix(lang): Fixes camera and mic error titles
* [squash] fix(supportLink): Renames addSupportLink to hideErrorSupportLink
The lib will accept new style constraints and use those
to capture audio/video. By defining the constraints in
config, there is greater flexibility for defining
and changing constraints.
* Javadoc introduced @code as a replacement of <code> and <tt> which is
better aligned with other javadoc tags such as @link. Use it in the
Java source code. If we switch to Kotlin, then we'll definitely use
Markdown.
* There are more uses of @code in the JavaScript source code than <tt>
so use @code for the sake of consistency. Eventually, I'd rather we
switch to Markdown because it's easier on my eyes.
* Xcode is plain confused by @code and @link. The Internet says that
Xcode supports the backquote character to denote the beginning and end
of a string of characters which should be formatted for display as
code but it doesn't work for me. <tt> is not rendered at all. So use
the backquote which is rendered itself. Hopefully, if we switch to
Markdown, then it'll be common between JavaScript and Objective-C
source code.
When do we need tracks?
- Welcome page (only the video track)
- Conference (depends if starting with audio / video muted is requested)
When do we need to destroy the tracks?
- When we are not in a conference and there is no welcome page
In order to accommodate all the above use cases, a new component is introduced:
BlankWelcomePage. Its purpose is to take the place of the welcome page when it
is disabled. When this component is mounted local tracks are destroyed.
Analogously, a video track is created when the (real) welcome page is created,
and all the desired tracks are created then the Conference component is created.
What are desired tracks? These are the tracks we'd like to use for the
conference that is about to happen. By default both audio and video are desired.
It's possible, however, the user requested to start the call with no
video/audio, in which case it's muted in base/media and a track is not created.
The first time the app starts (with the welcome page) it will request permission
for video only, since there is no need for audio in the welcome page. Later,
when a conference is joined permission for audio will be requested when an audio
track is to be created. The audio track is not destroyed when the conference
ends. Yours truly thinks this is not needed since it's a stopped track which is
not using system resources.
* ref: video muted state
Get rid of 'videoMuted' flag in conference.js
* ref: audio muted state
Get rid of 'audioMuted' flag in conference.js
* fix(conference.js|API): early audio/video muted updates
* ref(conference.js): rename isVideoMuted
Rename isVideoMuted to isLocalVideoMuted to be consistent with
isLocalAudioMuted.
* doc|style(conference.js): comments and space after if
* ref: move 'setTrackMuted' to functions
* fix(tracks/middleware): no-lonely-if
* ref(features/toolbox): get rid of last argument
* ref(defaultToolbarButtons): rename var
Simplify the code by using a bitfied instead of a couple of boolean flags. This
allows us to mute the video from multiple places and only make the unmute
effective once they have all unmuted.
Alas, this cannot be applied to the web without a massive refactor, because it
uses the track muted state as the source of truth instead of the media state.
Because on web video track is stored both in redux and in 'localVideo'
field, video is attempted to be unmuted twice when turning off the audio
only mode. This will crash the app with 'unmute operation is already in
progress'. This commit will prevent from taking action from the web
world if the video track already exists and will make the redux side
rollback unmuted status in case unmute fails.
The end goal of this patch was to avoid opening the camera when there is no
welcome page.
In order to achieve this, the logic for creating the local tracks was
refactored:
Before this patch local tracks were created when lib-jitsi-meet was initialized,
and destroyed when it was deinitialized. As a side note, this meant that when a
conference in a non-default domain was joined, local tracks were destroyed and
recreated in quick succession.
Now, local trans are created and destroyed based on what the next route will be,
and this happens when the target room has been decided. This allows us to create
local tracks the moment we need to render any route, and destroy them when there
is no route to be rendered. As an interesting byproduct, this refactor also
avoids the destruction + recreation of local tracks when a conference in a
non-default domain was left.
Listeners were set for when a track muted or changed its video
type, but the listeners were never removed. This would could
cause events to keep firing on the removed tracks, which would
cause redux to fire and error because the tracks were no longer
known. That the tracks still fire events after removal is
another issue...
- Add tracks to the redux store by intercepting where the
tracks actually get used via conference.replaceTrack
- While the replace call is unique to web, the _dispose and
_addTracks calls use existing native code implementations
- Between _dispose and addTracks is a call to update mute state.
Without it, when changing devices or videoType while muted,
the user will stay muted (whereas existing web behavior
causes unmute). This is due to middelware calling
_syncTrackMutedState to make the track mute if the user is
currently muted.
- Move the rest of ConferenceEvents.TRACK_MUTE_CHANGED into
middleware so the event is no longer used
- Note: This change does not guarantee the track state in the
redux store will be 100% accurate, specifically the attribute
videoStarted. Muted and videoType should be accurate.
- Use actions trackAdded and trackRemoved to add and remove remote
tracks from the redux store
- Emit out to non-react components on track added and removed in
the track middleware
- Emit out to existing non-react components on track mute and
video type changes
The functionality to use the react-native-webrtc custom API for fast switching
cameras was moved to JitsiLocalTrack in lib-jitsi-meet. Use that.
Ref: https://github.com/jitsi/lib-jitsi-meet/pull/444
Use the curstom _switchCamera API provided by react-native-webrtc to toggle the
camera instead of destroying the current track and creating a new one.
_switchCamera is implemented at a low level, so the track perceives no changes,
thus being a lot faster and less involved since the capturer doesn't need to be
destroyed and re-created.
In addition, don't mirror the video for the back camera.
Ref: https://github.com/oney/react-native-webrtc/pull/235
When a new local video track is created an associated video capturer is created
for it. The cause for the freezes seems to be creating mutliple tracks (which
come with a video capturer each). Fix this by first disposing of the previous
video track before creating the new one.
Ref:
https://github.com/oney/react-native-webrtc/issues/209#issuecomment-281482869
Дамян Минков
hmuresan
Alex Bumbu
Gabriel Imre
Andrei Gavrilescu
Mihai-Andrei Uscat
Hristo Terezov
Saúl Ibarra Corretgé
tudordan7
Tudor-Ovidiu Avram
Pawel Domas
Titus-Andrei Moldovan
Jaya Allamsetty
Vlad Piersec
Bettenbuk Zoltan
Mihai Uscat
Andrei Gavrilescu
Jaya Allamsetty
virtuacoplenny
Cristian Florin Ghita
Leonard Kim
Saúl Ibarra Corretgé
virtuacoplenny
paweldomas
bgrozev
Lyubo Marinov
Saúl Ibarra Corretgé