With this commit JS console logs can optionally be sent to the RTCstats server
for storage and processing.
The functionality is off by default and can be enabled by setting to `true` the
config.js option
config.analytics.rtcstatsStoreLogs: false // off by default
Obviously, if rtcstats is disabled/not configured nothing will be sent to the
rtcstats backend, even if this setting is set to `true`.
This commit also adds a config.js option that can be used to disable sending the
logs back to callstats:
config.callstatsStoreLogs: true // on by default
Obviously, if callstats is disabled nothing would be sent in the first place,
but if callstats is enabled and this new configuration parameter is set to
`false`, then callstats will be kept active but no logs will be sent to
callstats.
The new behavior is as follows:
IF a user has a token and `features` is not set, we treat it as if the
feature was enabled.
IF a user has a token and `features` is set, we check if the feature
name has a value of "true".
`isJwtFeatureEnabled` also provides a way to specify the default value
in case there is no token.
* fix(face-landmarks): work only when one face is detected
* fix: remove redundant check for detection
* fix(face-landmarks): re-center and stop when more faces detected
* fix: remove faceCount checking when sending message from worker
* fix: add again the faceCount
* fix: add comment
* code review
* fix(face-landmarks): set max detected faces up to 4
* add(face-landmarks): config for max faces detected
* fix(config.js): default value for capture interval face-landmarks
* add missing coma
Due to local storage limitations we might end up making the URL huge
when we save the state there. Avoid the issue at the root by never
storing URLs in that case.
Closes: https://github.com/jitsi/jitsi-meet/issues/11567
AV moderation does not work on brerakout rooms.
Since some of the options in the "breakoutRooms" config section no
longer apply, I moved the relevant ones to a new "participantsPane"
section.
This works together with the broader "notifications" config option. One
might choose to leave the existing option unespecified *thus allowing
all notifications) and then use this new one to be explicit about which
ones to disable.
It's about to become very confusing, since we are going to add actual
local recordings with video.
This feature was never fully finalizeed since it required manual
processing of the files, as they were not uploaded anywhere.
In addition, unless one opens the local audio device without any audio
processing first, any tracks opened later will have audio proceessing
turned on, something not desirable for the scenario this feature was
designed for in the first place: podcasts.
This feature will likely come back as a JaaS demo / MVP where the local
recording is made outside of the Jitsi Meet iframe.